On Wed, Jun 12, 2024 at 09:21:52PM +0200, Geert Uytterhoeven wrote:
Hi Kees,
On Wed, Jun 12, 2024 at 6:51 PM Kees Cook <kees@xxxxxxxxxx> wrote:
On Wed, Jun 12, 2024 at 05:13:39PM +0800, David Gow wrote:
On Tue, 11 Jun 2024 at 05:33, Kees Cook <kees@xxxxxxxxxx> wrote:
Convert the runtime tests of hardened usercopy to standard KUnit tests.
Co-developed-by: Vitor Massaru Iha <vitor@xxxxxxxxxxx>
Signed-off-by: Vitor Massaru Iha <vitor@xxxxxxxxxxx>
Link: https://lore.kernel.org/r/20200721174654.72132-1-vitor@xxxxxxxxxxx
Tested-by: Ivan Orlov <ivan.orlov0322@xxxxxxxxx>
Signed-off-by: Kees Cook <kees@xxxxxxxxxx>
---
This looks good, particularly with the x86 fix applied.
It's still hanging on m68k -- I think at the 'illegal reversed
copy_to_user passed' test -- but I'll admit to not having tried to
debug it further.
One other (set of) notes below about using KUNIT_EXPECT_MEMEQ_MSG(),
otherwise (assuming the m68k stuff isn't actually a regression, which
I haven't tested but I imagine is unlikely),
I'm trying to debug a hang on m68k in the usercopy behavioral testing
routines. It's testing for the pathological case of having inverted
arguments to copy_to_user():
user_addr = kunit_vm_mmap(test, NULL, 0, priv->size,
PROT_READ | PROT_WRITE | PROT_EXEC,
MAP_ANONYMOUS | MAP_PRIVATE, 0);
...
bad_usermem = (char *)user_addr;
...
KUNIT_EXPECT_NE_MSG(test, copy_to_user((char __user *)kmem, bad_usermem,
PAGE_SIZE), 0,
"illegal reversed copy_to_user passed");
On other architectures, this immediate fails because the access_ok()
check rejects it. On m68k with CONFIG_ALTERNATE_USER_ADDRESS_SPACE,
access_ok() short-circuits to "true". I've tried reading
arch/m68k/include/asm/uaccess.h but I'm not sure what's happening under
CONFIG_CPU_HAS_ADDRESS_SPACES.
On m68k CPUs that support CPU_HAS_ADDRESS_SPACES (i.e. all traditional
680x0 that can run real Linux), the CPU has separate address spaces
for kernel and user addresses. Accessing userspace addresses is done
using the special "moves" instruction, so we can just use the MMU to
catch invalid accesses.
Okay, that's what I suspected. I think I'll need to just not test this
particular case for archs with separate address spaces, since it would
be meaningless.
For now I've excluded that test for m68k, but I'm not sure what's
expected to happen here on m68k for this set of bad arguments. Can you
advise?
Perhaps the kernel address is actually a valid user address, or
vice versa?
Right -- I think that's what's happened.
Does the test work on systems that use 4G/4G for kernel/userspace
instead of the usual 1G/3G split?
/me runs the old test_user_copy.ko on ARAnyM
Seems to take a while? Or it hangs, too?
Sounds like the same behavior.
Related reading material
https://lore.kernel.org/all/CAMuHMdUzHwm5_TL7TNAOF+uqheJnKgsqF+_vzqGRzB_3eufKug@xxxxxxxxxxxxxx/
https://lore.kernel.org/all/CAMuHMdVQ93ihgcxUbjptTaHdPjxXLyVAsAr-m3tWBJV0krS2vw@xxxxxxxxxxxxxx/
Thanks!
-Kees
--
Kees Cook
