[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 30 Jan 2017 12:02:27 -0800
From: Kees Cook <keescook@...omium.org>
To: Jessica Frazelle <me@...sfraz.com>
Cc: "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>
Subject: Re: Introduction
On Fri, Jan 27, 2017 at 11:14 AM, Jessica Frazelle <me@...sfraz.com> wrote:
> Cool! Have already started looking into it! Super excited :D
>
> On Thu, Jan 26, 2017 at 1:42 PM Kees Cook <keescook@...omium.org> wrote:
>>
>> On Wed, Jan 25, 2017 at 8:12 PM, Jessica Frazelle <me@...sfraz.com> wrote:
>> > Honestly I'm open to working on whatever no one else wants too :)
>>
>> You said the magic words! ;) Looking at the TODO, I'll pick this
>> semi-randomly:
>>
>> - expand use of __ro_after_init, especially in arch/arm64
>>
>> It'd be nice to look through arch/arm64 to find anything that is close
>> to be able to be declared as const, but can't due to some post-boot
>> but pre-init changes. This is needs some manual examination currently,
>> but you can look at other uses of __ro_after_init in arch/x86 and
>> arch/arm. Of course, there's no reason to limit yourself to arch/arm64
>> if you find similar things in the core kernel code too.
I had someone point out that the IRQ subsystem has a lot of ops-type
structures that could be either const or __ro_after_init, for example
msi_domain_ops. That might be another area to look at.
-Kees
--
Kees Cook
Pixel Security
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
