Re: [PATCH] arm: Use kernel mm when updating section permissions

[Kevin Hilman]

Kees Cook <keescook@xxxxxxxxxxxx> writes:

> On Fri, Nov 6, 2015 at 12:11 PM, Kevin Hilman <khilman@xxxxxxxxxx> wrote:
>> On Fri, Nov 6, 2015 at 11:12 AM, Kees Cook <keescook@xxxxxxxxxxxx> wrote:
>>
>> [...]
>>
>>> Hi Kevin and Kernel CI folks,
>>>
>>> Could lkdtm get added to the kernel-CI workflows? Extracting and
>>> validating Oops details when poking lkdtm would be extremely valuable
>>> for these cases. :)
>>
>> Yeah, we can add that.
>>
>> What arches should we expect this to be working on?  For starters
>
> This is a great question. ;) They're a mix of CONFIG and hardware
> feature specific, so probably they should be run on all architectures
> and we can figure out what's missing in each case.
>
> Everything built with CONFIG_DEBUG_RODATA should pass these:
>
> WRITE_RO
> WRITE_KERN
> EXEC_DATA
> EXEC_STACK
> EXEC_KMALLOC
> EXEC_VMALLOC
>
> But architectures without CONFIG_DEBUG_RODATA should be shamed. ;)
>
> Passing EXEC_USERSPACE requires SMEP on x86, and PXN on arm64.
> Passing ACCESS_USERSPACE rquires SMAP on x86, and PAN on arm64.
>
> The recent PAN emulation CONFIG_CPU_SW_DOMAIN_PAN on non-LPAE arm
> should cover ACCESS_USERSPACE too, and maybe EXEC_USERSPACE, but I
> haven't taken a close look.

A quick test on arm32 and both ACCESS_ and EXEC_USERSPACE tests pass
(meaning they trigger the WARNs).

> It might be useful, frankly, to test everything in lkdtm.

So I gave this a quick spin on an ARM board (qcom-apq8064-ifc6410)
using a dumb script[1] (for now avoiding the tests that cause a lockup
so I can test multiple features without a reboot.)  Seems like most of
them are producing a failure.  

However, this got me to thinking that one should probably write a
kselftest for this feature, and catch quite a few issues with the ones
that don't cause a hard lockup.  One would just need to be a bit smarter
than my script and do something to trap SIG* (or the parent catching
SIGCHLD) in order to be able to help determine failure, then grab the
dmesg and log it.

Having these test integrated into kselftest, and maintained along with
the the kernel features would be *way* better than trying to maintain a
set of tests in kernel CI for this feature, since right now we're
working just building/running all the selftests automatically.

What do you think about coming up with a kselftest for this stuff?  At
least the non-lockup stuff?

I'm not volunteering to write up the kselftest, but I will guarantee
that it get run on a broad range of boards once it exists. :)

Kevin

[1]
#!/bin/sh

crash_test_dummy() {
  echo $1> /sys/kernel/debug/provoke-crash/DIRECT
}

# Find all the tests that don't lockup
TESTS=$(cat /sys/kernel/debug/provoke-crash/DIRECT |grep -v types| grep -v LOCK |grep -v PANIC)

for test in $TESTS; do
  echo "Performing test: $test"
  crash_test_dummy $test &
  sleep 1
done
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/