On Tue, Dec 3, 2013 at 1:47 PM, Andrew Morton <[email protected]> wrote: > On Tue, 3 Dec 2013 13:27:34 -0800 Kees Cook <[email protected]> wrote: > >> To help avoid an architecture failing to correctly check kernel/user >> boundaries when handling copy_to_user, copy_from_user, put_user, or >> get_user, perform some simple tests and fail to load if any of them >> behave unexpectedly. >> >> Specifically, this is to make sure there is a way to notice if things >> like what was fixed in 8404663f81d212918ff85f493649a7991209fa04 ("ARM: >> 7527/1: uaccess: explicitly check __user pointer when !CPU_USE_DOMAINS") >> ever regresses again, for any architecture. > > I guess the challenge will be to get anyone to remember to run this.
FWIW, I'll be running it. :) I'm sure Fengguang Wu could add it too. > Really, this could be viewed as a candidate for > tools/testing/selftests. The tests in there are userspace tests, and > your userspace test would consist of "modprobe test_user_copy". The > advantage of this is that your test will get included whenever someone > runs the selftest suite. This is better than having it stranded over > in ./kernel/. Sure, I'd be happy to add logic to that area too. >> --- >> kernel/Makefile | 1 + >> kernel/test_user_copy.c | 103 >> +++++++++++++++++++++++++++++++++++++++++++++++ >> lib/Kconfig.debug | 13 ++++++ > > We already have a whole pile of test modules - seven of them reside in > lib/ and I think there's an RCU one somewhere. Can we bring order to > all of this? Some form of integration under tools/testing would be one > approach. I expect to be adding more of these, and I'd like to see these collected in a single place as well. There are things like test_nx.c in the x86 tree (which actually doesn't work any more, but that's a separate issue). > If you're disinclined to undertake such a project at this time, I'd > suggest these two go into lib/ so they are known about if/when someone > goes for the big cleanup. lib/ sounds good. I'll move them there. Thanks! -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
