Re: [Ksummit-discuss] [TECH TOPIC] Kernel Hardening

[Andy Lutomirski <luto@amacapital.net>]

On Tue, Sep 22, 2015 at 5:59 AM, Julia Lawall <julia.lawall@lip6.fr> wrote:
>
>
> On Tue, 22 Sep 2015, Dan Carpenter wrote:
>
>> On Mon, Aug 24, 2015 at 09:35:50AM -0700, Kees Cook wrote:
>> > As an example, making the kernel code memory read-only means an
>> > attacker cannot just directly change the kernel's execution path when
>> > they use an arbitrary memory-writing flaw.
>>
>> Part of the problem is that C defaults to writable and you have to
>> explicitly add a const if you want it read only.  Then when you are
>> reading the code and you see:
>>
>> static struct uvc_format_desc uvc_fmts[] = {
>>
>> You can't immediately tell if it is writeable because it needs to be or
>> because that's just the default.  We should make a new keyword that
>> means non constant then we could grep for structs which have a function
>> pointer and complain if they weren't specified as const or __writable.
>>
>> Maybe there is a way to do this with GCC attributes but I have never
>> used them before and I couldn't immediately see how to do it.
>
> But the bigger problem is that some of these kinds of structs have a
> single writeable field lurking inside fo them.  For example,
> platform_driver contains struct device_driver driver; that is initialized
> in the platform driver library, and not in the device driver itself.
> Would it be beneficial to put const on the individual function-typed
> fields, if that is indeed possible?  For example, I don't find any
> assignments to a platform_driver remove field.
>

PaX gets around this with special tricks to write to fields in
otherwise const structures in appropriately annotated code.  We could
clean that up and do it upstream.

--Andy