Re: [PATCH v3] Add kernel config option for tweaking kernel behavior.

[Tetsuo Handa]

On 2020/04/14 3:13, Linus Torvalds wrote:
> On Sun, Apr 12, 2020 at 11:34 PM Tetsuo Handa
> <penguin-kernel@xxxxxxxxxxxxxxxxxxx> wrote:
>>
>> Existing kernel config options are defined based on "whether you want to
>> enable this module/feature or not". And such granularity is sometimes
>> too rough-grained for fuzzing tools which try to find bugs inside each
>> module/feature.
> 
> I still detest making this a hardcoded build-time config option.
> 
> A kernel parameter that sets a flag seems much simpler. More
> importantly, having it be something sanely named, and something you
> can set independently some other way, would allow a regular kernel to
> then run a fuzzer as root.

That approach involves declaration of user-visible behavioral ABI which
will become impossible to change or remove if we once published.

Also, syzkaller does not want to depend on userspace being rich. There are
userspace tools (e.g. SystemTap) that can tweak kernel's behavior. If we could
use SystemTap, we could do some of tweaks using SystemTap. Likewise, use of
runtime flags which can be set from userspace involves modification of userspace
programs, which is a sort of dependency syzkaller does not want to maintain.

The advantage of build-time tweaking is that we don't need to maintain behavioral
ABI. We can change what tweak is doing over time (e.g. narrowing down what the
build-time tweaking guards, improving how to get more useful information).

> 
> Some kind of "not even root" flag, which might be per-process and not
> possible to clear once set (so that your _normal_ system binaries
> could still do the root-only stuff, but then you could start a fuzzing
> process with that flag set, knowing that the fuzzing process - and
> it's children - are not able to do things).

I don't think per-process flags will work. Not every action is taken inside
process context who issued a syscall. Some action might be taken in interrupt
context or in kthread context. Since we have no means to propagate per-process
flags, we will need to give up more than we have to give up.

> 
> Honestly, in a perfect world, it has nothing at all to do with
> fuzzing, and people could even have some local rules like "anybody who
> came in through ssh from the network will also have this flag set".

I think that such restriction should be implemented as LSM modules.