user/sven/linux.git/scripts, branch v6.6.5

scripts/gdb/vmalloc: disable on no-MMU

2023-11-28T17:20:05Z

commit 6620999f0d41e4fd6f047727936a964c3399d249 upstream. vmap_area does not exist on no-MMU, therefore the GDB scripts fail to load: Traceback (most recent call last): File "<...>/vmlinux-gdb.py", line 51, in import linux.vmalloc File "<...>/scripts/gdb/linux/vmalloc.py", line 14, in vmap_area_ptr_type = vmap_area_type.get_type().pointer() ^^^^^^^^^^^^^^^^^^^^^^^^^ File "<...>/scripts/gdb/linux/utils.py", line 28, in get_type self._type = gdb.lookup_type(self._name) ^^^^^^^^^^^^^^^^^^^^^^^^^^^ gdb.error: No struct type named vmap_area. To fix this, disable the command and add an informative error message if CONFIG_MMU is not defined, following the example of lx-slabinfo. Link: https://lkml.kernel.org/r/20231031202235.2655333-2-ben.wolsieffer@hefring.com Fixes: 852622bf3616 ("scripts/gdb/vmalloc: add vmallocinfo support") Signed-off-by: Ben Wolsieffer Cc: Jan Kiszka Cc: Kieran Bingham Cc: Kuan-Ying Lee Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman

randstruct: Fix gcc-plugin performance mode to stay in group

2023-11-28T17:19:55Z

commit 381fdb73d1e2a48244de7260550e453d1003bb8e upstream. The performance mode of the gcc-plugin randstruct was shuffling struct members outside of the cache-line groups. Limit the range to the specified group indexes. Cc: linux-hardening@vger.kernel.org Cc: stable@vger.kernel.org Reported-by: Lukas Loidolt Closes: https://lore.kernel.org/all/f3ca77f0-e414-4065-83a5-ae4c4d25545d@student.tuwien.ac.at Fixes: 313dd1b62921 ("gcc-plugins: Add the randstruct plugin") Signed-off-by: Kees Cook Signed-off-by: Greg Kroah-Hartman

gcc-plugins: randstruct: Only warn about true flexible arrays

2023-11-28T17:19:49Z

[ Upstream commit 1ee60356c2dca938362528404af95b8ef3e49b6a ] The randstruct GCC plugin tried to discover "fake" flexible arrays to issue warnings about them in randomized structs. In the future LSM overhead reduction series, it would be legal to have a randomized struct with a 1-element array, and this should _not_ be treated as a flexible array, especially since commit df8fc4e934c1 ("kbuild: Enable -fstrict-flex-arrays=3"). Disable the 0-sized and 1-element array discovery logic in the plugin, but keep the "true" flexible array check. Cc: KP Singh Cc: linux-hardening@vger.kernel.org Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202311021532.iBwuZUZ0-lkp@intel.com/ Fixes: df8fc4e934c1 ("kbuild: Enable -fstrict-flex-arrays=3") Reviewed-by: Bill Wendling Acked-by: "Gustavo A. R. Silva" Link: https://lore.kernel.org/r/20231104204334.work.160-kees@kernel.org Signed-off-by: Kees Cook Signed-off-by: Sasha Levin

x86/retpoline: Make sure there are no unconverted return thunks due to KCSAN

2023-11-28T17:19:36Z

[ Upstream commit 2d7ce49f58dc95495b3e22e45d2be7de909b2c63 ] Enabling CONFIG_KCSAN leads to unconverted, default return thunks to remain after patching. As David Kaplan describes in his debugging of the issue, it is caused by a couple of KCSAN-generated constructors which aren't processed by objtool: "When KCSAN is enabled, GCC generates lots of constructor functions named _sub_I_00099_0 which call __tsan_init and then return. The returns in these are generally annotated normally by objtool and fixed up at runtime. But objtool runs on vmlinux.o and vmlinux.o does not include a couple of object files that are in vmlinux, like init/version-timestamp.o and .vmlinux.export.o, both of which contain _sub_I_00099_0 functions. As a result, the returns in these functions are not annotated, and the panic occurs when we call one of them in do_ctors and it uses the default return thunk. This difference can be seen by counting the number of these functions in the object files: $ objdump -d vmlinux.o|grep -c "<_sub_I_00099_0>:" 2601 $ objdump -d vmlinux|grep -c "<_sub_I_00099_0>:" 2603 If these functions are only run during kernel boot, there is no speculation concern." Fix it by disabling KCSAN on version-timestamp.o and .vmlinux.export.o so the extra functions don't get generated. KASAN and GCOV are already disabled for those files. [ bp: Massage commit message. ] Closes: https://lore.kernel.org/lkml/20231016214810.GA3942238@dev-arch.thelio-3990X/ Reported-by: Nathan Chancellor Signed-off-by: Josh Poimboeuf Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Nick Desaulniers Acked-by: Marco Elver Tested-by: Nathan Chancellor Link: https://lore.kernel.org/r/20231017165946.v4i2d4exyqwqq3bx@treble Signed-off-by: Sasha Levin

modpost: fix ishtp MODULE_DEVICE_TABLE built on big-endian host

2023-11-20T10:59:28Z

[ Upstream commit ac96a15a0f0c8812a3aaa587b871cd5527f6d736 ] When MODULE_DEVICE_TABLE(ishtp, ) is built on a host with a different endianness from the target architecture, it results in an incorrect MODULE_ALIAS(). For example, see a case where drivers/platform/x86/intel/ishtp_eclite.c is built as a module for x86. If you build it on a little-endian host, you will get the correct MODULE_ALIAS: $ grep MODULE_ALIAS drivers/platform/x86/intel/ishtp_eclite.mod.c MODULE_ALIAS("ishtp:{6A19CC4B-D760-4DE3-B14D-F25EBD0FBCD9}"); However, if you build it on a big-endian host, you will get a wrong MODULE_ALIAS: $ grep MODULE_ALIAS drivers/platform/x86/intel/ishtp_eclite.mod.c MODULE_ALIAS("ishtp:{BD0FBCD9-F25E-B14D-4DE3-D7606A19CC4B}"); This issue has been unnoticed because the x86 kernel is most likely built natively on an x86 host. The guid field must not be reversed because guid_t is an array of __u8. Fixes: fa443bc3c1e4 ("HID: intel-ish-hid: add support for MODULE_DEVICE_TABLE()") Signed-off-by: Masahiro Yamada Reviewed-by: Thomas Weißschuh Tested-by: Srinivas Pandruvada Acked-by: Srinivas Pandruvada Signed-off-by: Sasha Levin

modpost: fix tee MODULE_DEVICE_TABLE built on big-endian host

2023-11-20T10:59:28Z

[ Upstream commit 7f54e00e5842663c2cea501bbbdfa572c94348a3 ] When MODULE_DEVICE_TABLE(tee, ) is built on a host with a different endianness from the target architecture, it results in an incorrect MODULE_ALIAS(). For example, see a case where drivers/char/hw_random/optee-rng.c is built as a module for ARM little-endian. If you build it on a little-endian host, you will get the correct MODULE_ALIAS: $ grep MODULE_ALIAS drivers/char/hw_random/optee-rng.mod.c MODULE_ALIAS("tee:ab7a617c-b8e7-4d8f-8301-d09b61036b64*"); However, if you build it on a big-endian host, you will get a wrong MODULE_ALIAS: $ grep MODULE_ALIAS drivers/char/hw_random/optee-rng.mod.c MODULE_ALIAS("tee:646b0361-9bd0-0183-8f4d-e7b87c617aab*"); The same problem also occurs when you enable CONFIG_CPU_BIG_ENDIAN, and build it on a little-endian host. This issue has been unnoticed because the ARM kernel is configured for little-endian by default, and most likely built on a little-endian host (cross-build on x86 or native-build on ARM). The uuid field must not be reversed because uuid_t is an array of __u8. Fixes: 0fc1db9d1059 ("tee: add bus driver framework for TEE based devices") Signed-off-by: Masahiro Yamada Reviewed-by: Sumit Garg Signed-off-by: Sasha Levin

scripts/gdb: fix usage of MOD_TEXT not defined when CONFIG_MODULES=n

2023-11-20T10:59:24Z

[ Upstream commit 16501630bdeb107141a0139ddc33f92ab5582c6f ] MOD_TEXT is only defined if CONFIG_MODULES=y which lead to loading failure of the gdb scripts when kernel is built without CONFIG_MODULES=y: Reading symbols from vmlinux... Traceback (most recent call last): File "/foo/vmlinux-gdb.py", line 25, in import linux.constants File "/foo/scripts/gdb/linux/constants.py", line 14, in LX_MOD_TEXT = gdb.parse_and_eval("MOD_TEXT") ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ gdb.error: No symbol "MOD_TEXT" in current context. Add a conditional check on CONFIG_MODULES to fix this error. Link: https://lkml.kernel.org/r/20231031134848.119391-1-da.gomez@samsung.com Fixes: b4aff7513df3 ("scripts/gdb: use mem instead of core_layout to get the module address") Signed-off-by: Clément Léger Tested-by: Daniel Gomez Signed-off-by: Daniel Gomez Cc: Jan Kiszka Cc: Kieran Bingham Cc: Luis Chamberlain Cc: Pankaj Raghav Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin

x86/srso: Fix unret validation dependencies

2023-11-20T10:58:52Z

[ Upstream commit eeb9f34df065f42f0c9195b322ba6df420c9fc92 ] CONFIG_CPU_SRSO isn't dependent on CONFIG_CPU_UNRET_ENTRY (AMD Retbleed), so the two features are independently configurable. Fix several issues for the (presumably rare) case where CONFIG_CPU_SRSO is enabled but CONFIG_CPU_UNRET_ENTRY isn't. Fixes: fb3bd914b3ec ("x86/srso: Add a Speculative RAS Overflow mitigation") Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Signed-off-by: Borislav Petkov (AMD) Acked-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/r/299fb7740174d0f2335e91c58af0e9c242b4bac1.1693889988.git.jpoimboe@kernel.org Signed-off-by: Sasha Levin

kbuild: remove stale code for 'source' symlink in packaging scripts

2023-10-01T14:06:06Z

Since commit d8131c2965d5 ("kbuild: remove $(MODLIB)/source symlink"), modules_install does not create the 'source' symlink. Remove the stale code from builddeb and kernel.spec. Signed-off-by: Masahiro Yamada

modpost: Don't let "driver"s reference .exit.*

2023-10-01T05:55:30Z

Drivers must not reference functions marked with __exit as these likely are not available when the code is built-in. There are few creative offenders uncovered for example in ARCH=amd64 allmodconfig builds. So only trigger the section mismatch warning for W=1 builds. The dual rule that drivers must not reference .init.* is implemented since commit 0db252452378 ("modpost: don't allow *driver to reference .init.*") which however missed that .exit.* should be handled in the same way. Thanks to Masahiro Yamada and Arnd Bergmann who gave valuable hints to find this improvement. Signed-off-by: Uwe Kleine-König Signed-off-by: Masahiro Yamada