Add support for handling MHI_RESET in MHI endpoint stack. MHI_RESET will
be issued by the host during shutdown and during error scenario so that
it can recover the endpoint device without restarting the whole device.

MHI_RESET handling involves resetting the internal MHI registers, data
structures, state machines, resetting all channels/rings and setting
MHICTRL.RESET bit to 0. Additionally the device will also move to READY
state if the reset was due to SYS_ERR.
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/20220405135754.6622-12-manivannan.sadhasivam@linaro.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Add support for MHI endpoint power_down that includes stopping all
available channels, destroying the channels, resetting the event and
transfer rings and freeing the host cache.

The stack will be powered down whenever the physical bus link goes down.
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/20220405135754.6622-11-manivannan.sadhasivam@linaro.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Add support for MHI endpoint power_up that includes initializing the MMIO
and rings, caching the host MHI registers, and setting the MHI state to M0.
After registering the MHI EP controller, the stack has to be powered up
for usage.
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/20220405135754.6622-10-manivannan.sadhasivam@linaro.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Add support for processing MHI endpoint interrupts such as control
interrupt, command interrupt and channel interrupt from the host.

The interrupts will be generated in the endpoint device whenever host
writes to the corresponding doorbell registers. The doorbell logic
is handled inside the hardware internally.
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/20220405135754.6622-9-manivannan.sadhasivam@linaro.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Add support for managing the MHI state machine by controlling the state
transitions. Only the following MHI state transitions are supported:

1. Ready state
2. M0 state
3. M3 state
4. SYS_ERR state
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/20220405135754.6622-8-manivannan.sadhasivam@linaro.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Add support for sending the events to the host over MHI bus from the
endpoint. Following events are supported:

1. Transfer completion event
2. Command completion event
3. State change event
4. Execution Environment (EE) change event

An event is sent whenever an operation has been completed in the MHI EP
device. Event is sent using the MHI event ring and additionally the host
is notified using an IRQ if required.
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/20220405135754.6622-7-manivannan.sadhasivam@linaro.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Add support for managing the MHI ring. The MHI ring is a circular queue
of data structures used to pass the information between host and the
endpoint.

MHI support 3 types of rings:

1. Transfer ring
2. Event ring
3. Command ring

All rings reside inside the host memory and the MHI EP device maps it to
the device memory using blocks like PCIe iATU. The mapping is handled in
the MHI EP controller driver itself.
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/20220405135754.6622-6-manivannan.sadhasivam@linaro.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Add support for managing the Memory Mapped Input Output (MMIO) registers
of the MHI bus. All MHI operations are carried out using the MMIO registers
by both host and the endpoint device.

The MMIO registers reside inside the endpoint device memory (fixed
location based on the platform) and the address is passed by the MHI EP
controller driver during its registration.
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/20220405135754.6622-5-manivannan.sadhasivam@linaro.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

This commit adds support for creating and destroying MHI endpoint devices.
The MHI endpoint devices binds to the MHI endpoint channels and are used
to transfer data between MHI host and endpoint device.

There is a single MHI EP device for each channel pair. The devices will be
created when the corresponding channels has been started by the host and
will be destroyed during MHI EP power down and reset.
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/20220405135754.6622-4-manivannan.sadhasivam@linaro.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

This commit adds support for registering MHI endpoint client drivers
with the MHI endpoint stack. MHI endpoint client drivers bind to one
or more MHI endpoint devices inorder to send and receive the upper-layer
protocol packets like IP packets, modem control messages, and
diagnostics messages over MHI bus.
Reviewed-by: Hemant Kumar <hemantk@codeaurora.org>
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/20220405135754.6622-3-manivannan.sadhasivam@linaro.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

This commit adds support for registering MHI endpoint controller drivers
with the MHI endpoint stack. MHI endpoint controller drivers manage
the interaction with the host machines (such as x86). They are also the
MHI endpoint bus master in charge of managing the physical link between
the host and endpoint device. Eventhough the MHI spec is bus agnostic,
the current implementation is entirely based on PCIe bus.

The endpoint controller driver encloses all information about the
underlying physical bus like PCIe. The registration process involves
parsing the channel configuration and allocating an MHI EP device.

Channels used in the endpoint stack follows the perspective of the MHI
host stack. i.e.,

UL - From host to endpoint
DL - From endpoint to host
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/20220405135754.6622-2-manivannan.sadhasivam@linaro.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The use of kmap_atomic() is being deprecated in favor of kmap_local_page()
where it is feasible. Each call of kmap_atomic() in the kernel creates
a non-preemptible section and disable pagefaults. This could be a source
of unwanted latency, so kmap_local_page() should be preferred.

With kmap_local_page(), the mapping is per thread, CPU local and not
globally visible. Furthermore, the mapping can be acquired from any context
(including interrupts). binder_alloc_do_buffer_copy() is a function where
the use of kmap_local_page() in place of kmap_atomic() is correctly suited.

Use kmap_local_page() / kunmap_local() in place of kmap_atomic() /
kunmap_atomic() but, instead of open coding the mappings and call memcpy()
to and from the virtual addresses of the mapped pages, prefer the use of
the memcpy_{to,from}_page() wrappers (as suggested by Christophe
Jaillet).

Cc: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Acked-by: Todd Kjos <tkjos@google.com>
Signed-off-by: Fabio M. De Francesco <fmdefrancesco@gmail.com>
Link: https://lore.kernel.org/r/20220425175754.8180-4-fmdefrancesco@gmail.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The use of kmap() is being deprecated in favor of kmap_local_page()
where it is feasible. With kmap_local_page(), the mapping is per
thread, CPU local and not globally visible.

binder_alloc_copy_user_to_buffer() is a function where the use of
kmap_local_page() in place of kmap() is correctly suited because
the mapping is local to the thread.

Therefore, use kmap_local_page() / kunmap_local().

Cc: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Acked-by: Todd Kjos <tkjos@google.com>
Signed-off-by: Fabio M. De Francesco <fmdefrancesco@gmail.com>
Link: https://lore.kernel.org/r/20220425175754.8180-3-fmdefrancesco@gmail.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The use of kmap() is being deprecated in favor of kmap_local_page()
where it is feasible. With kmap_local_page(), the mapping is per
thread, CPU local and not globally visible.

binder_alloc_clear_buf() is a function where the use of kmap_local_page()
in place of kmap() is correctly suited because the mapping is local to the
thread.

Therefore, use kmap_local_page() / kunmap_local() but, instead of open
coding these two functions and adding a memset() of the virtual address
of the mapping, prefer memset_page().

Cc: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Acked-by: Todd Kjos <tkjos@google.com>
Signed-off-by: Fabio M. De Francesco <fmdefrancesco@gmail.com>
Link: https://lore.kernel.org/r/20220425175754.8180-2-fmdefrancesco@gmail.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Fix the following coccicheck warning:

drivers/virt/fsl_hypervisor.c:662:5-8: Unneeded variable: "ret".
Return "0" on line 679.
Signed-off-by: Guo Zhengkui <guozhengkui@vivo.com>
Link: https://lore.kernel.org/r/20220426083315.9551-1-guozhengkui@vivo.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Add support for ARM64 architecture so that the driver can now be built
and VMCI device can be used.

Update Kconfig file to allow the driver to be built on ARM64 as well.
Fail vmci_guest_probe_device() on ARM64 if the device does not support
MMIO register access.  Lastly, add virtualization specific barriers
which map to actual memory barrier instructions on ARM64, because it
is required in case of ARM64 for queuepair (de)queuing.
Reviewed-by: Bryan Tan <bryantan@vmware.com>
Reviewed-by: Cyprien Laplace <claplace@vmware.com>
Signed-off-by: Vishnu Dasa <vdasa@vmware.com>
Link: https://lore.kernel.org/r/20220414193316.14356-1-vdasa@vmware.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The bug is here:
	pmem->vaddr = NULL;

The list iterator 'pmem' will point to a bogus position containing
HEAD if the list is empty or no element is found. This case must
be checked before any use of the iterator, otherwise it will
lead to a invalid memory access.

To fix this bug, just gen_pool_free/set NULL/list_del() and return
when found, otherwise list_del HEAD and return;

Fixes: 7ca5ce89 ("firmware: add Intel Stratix10 service layer driver")
Signed-off-by: Xiaomeng Tong <xiam0nd.tong@gmail.com>
Link: https://lore.kernel.org/r/20220414035609.2239-1-xiam0nd.tong@gmail.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

In 8619e5bd ("/dev/mem: Bail out upon SIGKILL."), /dev/mem became
killable, and that commit noted:

  Theoretically, reading/writing /dev/mem and /dev/kmem can become
  "interruptible". But this patch chose "killable". Future patch will
  make them "interruptible" so that we can revert to "killable" if
  some program regressed.

So now we take the next step in making it "interruptible", by changing
fatal_signal_pending() into signal_pending().

Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Link: https://lore.kernel.org/r/20220407122638.490660-1-Jason@zx2c4.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb_get_dev is called in xillyusb_probe. So it is better to call
usb_put_dev before xdev is released.
Acked-by: Eli Billauer <eli.billauer@gmail.com>
Signed-off-by: Hangyu Hua <hbh25y@gmail.com>
Link: https://lore.kernel.org/r/20220406075703.23464-1-hbh25y@gmail.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

To move the list iterator variable into the list_for_each_entry_*()
macro in the future it should be avoided to use the list iterator
variable after the loop body.

To *never* use the list iterator variable after the loop it was
concluded to use a separate iterator variable instead of a
found boolean [1].

This removes the need to use a found variable and simply checking if
the variable was set, can determine if the break/goto was hit.

Link: https://lore.kernel.org/all/CAHk-=wgRr_D8CB-D9Kg-c=EHreAsk5SqXPwr9Y7k9sA6cWXJ6w@mail.gmail.com/Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com>
Link: https://lore.kernel.org/r/20220327214551.2188544-1-jakobkoschel@gmail.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Changed all remaining pr_XXX calls that write out debugging info into
dev_XXX calls, changed the needlessly verbose decoding of status bits
into dev_dbg(), so that it's supressed by the logging levels by default.

Forthermore the ds_recv_status function has a "dump" parameter that
enables extremely verbose logging, and that's used only once.
This has been factored out, and called explicitly at that one place.
Signed-off-by: Christian Vogel <vogelchr@vogel.cx>
Link: https://lore.kernel.org/r/20220324193246.16814-2-vogelchr@vogel.cxSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The bug is here:
	if (!buf) {

The list iterator value 'buf' will *always* be set and non-NULL
by list_for_each_entry(), so it is incorrect to assume that the
iterator value will be NULL if the list is empty (in this case, the
check 'if (!buf) {' will always be false and never exit expectly).

To fix the bug, use a new variable 'iter' as the list iterator,
while use the original variable 'buf' as a dedicated pointer to
point to the found element.

Fixes: 2419e55e ("misc: fastrpc: add mmap/unmap support")
Signed-off-by: Xiaomeng Tong <xiam0nd.tong@gmail.com>
Link: https://lore.kernel.org/r/20220327062202.5720-1-xiam0nd.tong@gmail.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

To move the list iterator variable into the list_for_each_entry_*()
macro in the future it should be avoided to use the list iterator
variable after the loop body.

To *never* use the list iterator variable after the loop it was
concluded to use a separate iterator variable instead of a
found boolean [1].

This removes the need to use a found variable and simply checking if
the variable was set, can determine if the break/goto was hit.

Link: https://lore.kernel.org/all/CAHk-=wgRr_D8CB-D9Kg-c=EHreAsk5SqXPwr9Y7k9sA6cWXJ6w@mail.gmail.com/Acked-by: Eli Billauer <eli.billauer@gmail.com>
Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com>
Link: https://lore.kernel.org/r/20220324070939.59297-1-jakobkoschel@gmail.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

To move the list iterator variable into the list_for_each_entry_*()
macro in the future it should be avoided to use the list iterator
variable after the loop body.

To *never* use the list iterator variable after the loop it was
concluded to use a separate iterator variable instead of a
found boolean [1].

This removes the need to use a found variable and simply checking if
the variable was set, can determine if the break/goto was hit.

Link: https://lore.kernel.org/all/CAHk-=wgRr_D8CB-D9Kg-c=EHreAsk5SqXPwr9Y7k9sA6cWXJ6w@mail.gmail.com/Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com>
Link: https://lore.kernel.org/r/20220324073151.66305-1-jakobkoschel@gmail.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The VMware balloon might be reset multiple times during execution. Print
errors only once to avoid filling the log unnecessarily.
Signed-off-by: Nadav Amit <namit@vmware.com>
Link: https://lore.kernel.org/r/20220322170052.6351-1-namit@vmware.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Printing probe success is discouraged, because we can use tracing for
this purpose.  Remove useless print message after Sunplus OCOTP driver
probe.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20220321110326.44652-3-krzk@kernel.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

The "sp_otp_v0" file scope variable is not used outside, so make it
static to fix warning:

  drivers/nvmem/sunplus-ocotp.c:74:29: sparse:
    sparse: symbol 'sp_otp_v0' was not declared. Should it be static?
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20220321110326.44652-2-krzk@kernel.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

"bcm_otpc_acpi_ids" is used with ACPI_PTR, so a build with !CONFIG_ACPI
has a warning:

  drivers/nvmem/bcm-ocotp.c:247:36: error:
    ‘bcm_otpc_acpi_ids’ defined but not used [-Werror=unused-const-variable=]
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Link: https://lore.kernel.org/r/20220321110326.44652-1-krzk@kernel.orgSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

In preparation to limit the scope of the list iterator to the list
traversal loop, use a dedicated pointer pointing to the found element [1].

Link: https://lore.kernel.org/all/YhdfEIwI4EdtHdym@kroah.com/Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com>
Link: https://lore.kernel.org/r/20220319201454.2511733-1-jakobkoschel@gmail.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Al noted in [1] that fd_install can't be undone, so it must come last in
the fd translation sequence, only after we've successfully reserved all
descriptors and copied them into the transaction buffer.

This patch takes Al's proposed fix in [2] and makes a few tweaks to fold
the traversal of t->fd_fixups during release.

[1] https://lore.kernel.org/driverdev-devel/YHnJwRvUhaK3IM0l@zeniv-ca.linux.org.uk
[2] https://lore.kernel.org/driverdev-devel/YHo6Ln9VI1T7RmLK@zeniv-ca.linux.org.uk

Cc: Christian Brauner <christian.brauner@ubuntu.com>
Suggested-by: Al Viro <viro@zeniv.linux.org.uk>
Acked-by: Todd Kjos <tkjos@google.com>
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20220325232454.2210817-1-cmllamas@google.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Enable the feature check if the PM_FEATURE_CHECK API returns success
with the supported version for the ZynqMP. Currently, it is enabled
for Versal only.

Move get_set_conduit_method() at the beginning as the Linux is
requesting to TF-A for the PM_FEATURE_CHECK API version for which the
interface should be enabled with TF-A.
Signed-off-by: Ronak Jain <ronak.jain@xilinx.com>
Link: https://lore.kernel.org/r/1649242526-17493-5-git-send-email-ronak.jain@xilinx.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Currently, we are not checking feature check version for PM APIs as
the support may or may not there in the firmware. To check the whether
the feature check API is supported or not in the firmware, allow
checking for its own version.
Signed-off-by: Ronak Jain <ronak.jain@xilinx.com>
Link: https://lore.kernel.org/r/1649242526-17493-4-git-send-email-ronak.jain@xilinx.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Add new function for sending feature check request to firmware and
call it from zynqmp_pm_feature().
Signed-off-by: Ronak Jain <ronak.jain@xilinx.com>
Link: https://lore.kernel.org/r/1649242526-17493-3-git-send-email-ronak.jain@xilinx.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Add support to check if IOCTL ID or QUERY ID is supported in firmware
or not.
Signed-off-by: Ronak Jain <ronak.jain@xilinx.com>
Link: https://lore.kernel.org/r/1649242526-17493-2-git-send-email-ronak.jain@xilinx.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Merge tag 'lkdtm-next' of https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux into char-misc-next

Kees writes:

lkdtm updates for next

Christophe Leroy (1):
      lkdtm/bugs: Don't expect thread termination without CONFIG_UBSAN_TRAP

Jiasheng Jiang (1):
      lkdtm/bugs: Check for the NULL pointer after calling kmalloc

Kees Cook (4):
      lkdtm/heap: Note conditions for SLAB_LINEAR_OVERFLOW
      lkdtm/usercopy: Expand size of "out of frame" object
      lkdtm: Move crashtype definitions into each category
      lkdtm: Add CFI_BACKWARD to test ROP mitigations

* tag 'lkdtm-next' of https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux:
  lkdtm: Add CFI_BACKWARD to test ROP mitigations
  lkdtm: Move crashtype definitions into each category
  lkdtm/bugs: Don't expect thread termination without CONFIG_UBSAN_TRAP
  lkdtm/usercopy: Expand size of "out of frame" object
  lkdtm/heap: Note conditions for SLAB_LINEAR_OVERFLOW
  lkdtm/bugs: Check for the NULL pointer after calling kmalloc

This silences the following coccinelle warning:
drivers/s390/char/tape_34xx.c:360:38-39: WARNING: sum of probable bitmasks, consider |

we will try to make code cleaner
Reviewed-by: Jiri Slaby <jirislaby@kernel.org>
Signed-off-by: Haowen Bai <baihaowen@meizu.com>
Link: https://lore.kernel.org/r/1647846757-946-1-git-send-email-baihaowen@meizu.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Replace for spelling
keypresses to key presses
bytesize to byte size
specificly to specifically
Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Signed-off-by: Tom Rix <trix@redhat.com>
Link: https://lore.kernel.org/r/20220329195401.3220408-1-trix@redhat.comSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

In order to test various backward-edge control flow integrity methods,
add a test that manipulates the return address on the stack. Currently
only arm64 Pointer Authentication and Shadow Call Stack is supported.

 $ echo CFI_BACKWARD | cat >/sys/kernel/debug/provoke-crash/DIRECT

Under SCS, successful test of the mitigation is reported as:

 lkdtm: Performing direct entry CFI_BACKWARD
 lkdtm: Attempting unchecked stack return address redirection ...
 lkdtm: ok: redirected stack return address.
 lkdtm: Attempting checked stack return address redirection ...
 lkdtm: ok: control flow unchanged.

Under PAC, successful test of the mitigation is reported by the PAC
exception handler:

 lkdtm: Performing direct entry CFI_BACKWARD
 lkdtm: Attempting unchecked stack return address redirection ...
 lkdtm: ok: redirected stack return address.
 lkdtm: Attempting checked stack return address redirection ...
 Unable to handle kernel paging request at virtual address bfffffc0088d0514
 Mem abort info:
   ESR = 0x86000004
   EC = 0x21: IABT (current EL), IL = 32 bits
   SET = 0, FnV = 0
   EA = 0, S1PTW = 0
   FSC = 0x04: level 0 translation fault
 [bfffffc0088d0514] address between user and kernel address ranges
 ...

If the CONFIGs are missing (or the mitigation isn't working), failure
is reported as:

 lkdtm: Performing direct entry CFI_BACKWARD
 lkdtm: Attempting unchecked stack return address redirection ...
 lkdtm: ok: redirected stack return address.
 lkdtm: Attempting checked stack return address redirection ...
 lkdtm: FAIL: stack return address was redirected!
 lkdtm: This is probably expected, since this kernel was built *without* CONFIG_ARM64_PTR_AUTH_KERNEL=y nor CONFIG_SHADOW_CALL_STACK=y
Co-developed-by: Dan Li <ashimida@linux.alibaba.com>
Signed-off-by: Dan Li <ashimida@linux.alibaba.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/lkml/20220416001103.1524653-1-keescook@chromium.org

It's long been annoying that to add a new LKDTM test one had to update
lkdtm.h and core.c to get it "registered". Switch to a per-category
list and update the crashtype walking code in core.c to handle it.

This also means that all the lkdtm_* tests themselves can be static now.

Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Kees Cook <keescook@chromium.org>

When you don't select CONFIG_UBSAN_TRAP, you get:

  # echo ARRAY_BOUNDS > /sys/kernel/debug/provoke-crash/DIRECT
[  102.265827] ================================================================================
[  102.278433] UBSAN: array-index-out-of-bounds in drivers/misc/lkdtm/bugs.c:342:16
[  102.287207] index 8 is out of range for type 'char [8]'
[  102.298722] ================================================================================
[  102.313712] lkdtm: FAIL: survived array bounds overflow!
[  102.318770] lkdtm: Unexpected! This kernel (5.16.0-rc1-s3k-dev-01884-g720dcf79314a ppc) was built with CONFIG_UBSAN_BOUNDS=y

It is not correct because when CONFIG_UBSAN_TRAP is not selected
you can't expect array bounds overflow to kill the thread.

Modify the logic so that when the kernel is built with
CONFIG_UBSAN_BOUNDS but without CONFIG_UBSAN_TRAP, you get a warning
about CONFIG_UBSAN_TRAP not been selected instead.

This also require a fix of pr_expected_config(), otherwise the
following error is encountered.

  CC      drivers/misc/lkdtm/bugs.o
drivers/misc/lkdtm/bugs.c: In function 'lkdtm_ARRAY_BOUNDS':
drivers/misc/lkdtm/bugs.c:351:2: error: 'else' without a previous 'if'
  351 |  else
      |  ^~~~

Fixes: c75be56e ("lkdtm/bugs: Add ARRAY_BOUNDS to selftests")
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/363b58690e907c677252467a94fe49444c80ea76.1649704381.git.christophe.leroy@csgroup.eu