Secure coding conventions in Linux Kernel

Question

While reviewing kernel code, I have encountered the following situation.

Suppose we have two kernel components A and B (say, kernel modules), with A invoking an EXPORT_SYMBOL 'ed some_func() from B . Suppose that some_func() has input arguments, which should be assigned only "legitimate" or "valid" values. For example, suppose that we have

some_func(void * p);

where void * p should be non- NULL , perhaps also pointing to a chunk of properly allocated memory.

My question is: who is responsible that some_func() 's arguments are indeed legitimate? Is it the caller A or the callee B ? I wasn't able to find an authoritative source decreeing what convention should be followed within the kernel.

When considering the pointer input argument example, from a security perspective, it's clear that we might run into a NULL -pointer dereference issue, which should be avoided. So, to specialize my question , is A responsible for the security of the arguments it passes to B , or should B have validations placed at the entry to each symbol it exports?

Please note that this question is about calling conventions within the kernel, and not related to calling conventions from userspace.

Answer 1

All kernel code works at the same privilege level. Thus it is a programming error to pass an invalid argument of the sort.

For kicks let's say that B attempts to somehow validate. Clearly, NULL check is trivial. But how do you verify the pointer points to something which you can access? Here is a bonus kicker: what if B validated, concluded its fine, and then code from the A module running on another cpu freed the target area. If B accesses now, all the work was rendered useless.

But why play like this if you have the same permissions as B. If you want, you can straight up overwrite its code.

As you can see, the question is definitely moot.

On the other hand let's contrast this with userspace. kernel<->user interface is a security boundary, passed data/pointers are inherently untrusted and only accessed through dedicated primitives guaranteeing safety. Note the fundamental difference in the ability to provide a guarantee: you access, it may trigger a page fault and if that happened and there is nothing to map there, you know userspace is screwing around and you can nicely return an error. If the same thing happens for kernel code, you have a bug.