[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXu5jL2KpsWjkh0G9UbPpT5yFEL_8aiC64ZJUyJUtZnZiGtRg@mail.gmail.com>
Date: Fri, 3 Jun 2016 15:01:04 -0700
From: Kees Cook <keescook@...omium.org>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>,
linux-arch <linux-arch@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>, "x86@...nel.org" <x86@...nel.org>,
Ard Biesheuvel <ard.biesheuvel@...aro.org>, Mathias Krause <minipli@...glemail.com>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 2/2] arm: apply more __ro_after_init
On Fri, Jun 3, 2016 at 2:54 PM, Greg KH <gregkh@...uxfoundation.org> wrote:
> On Fri, Jun 03, 2016 at 02:26:54PM -0700, Kees Cook wrote:
>> On Fri, Jun 3, 2016 at 11:51 AM, Greg KH <gregkh@...uxfoundation.org> wrote:
>> > On Fri, Jun 03, 2016 at 11:40:24AM -0700, Kees Cook wrote:
>> >> Guided by grsecurity's analogous __read_only markings in arch/arm,
>> >> this applies several uses of __ro_after_init to structures that are
>> >> only updated during __init.
>> >>
>> >> Signed-off-by: Kees Cook <keescook@...omium.org>
>> >> ---
>> >> arch/arm/kernel/cpuidle.c | 2 +-
>> >> arch/arm/kernel/setup.c | 10 +++++-----
>> >> arch/arm/kernel/smp.c | 2 +-
>> >> arch/arm/lib/delay.c | 2 +-
>> >> arch/arm/mm/mmu.c | 9 ++-------
>> >> arch/x86/mm/ioremap.c | 3 +--
>> >
>> > I don't think this x86 file is an arm-specific one :)
>>
>> Hah, whooops. :)
>>
>> > That minor nit aside, these patches are a great step forward, are you
>> > going to take them and work to push them upstream, or do you want/need
>> > others to do this?
>>
>> I'll collect more like these and carry a tree for -next and push them for v4.8.
>
> Sounds good!
>
> Is there any "problem" with applying these markings to code that could
> be built as a module? I'm thinking of lots of buses and drivers that
> have structures like this, but can be a module or not, depending on the
> configuration selected. It would be nice to get the "benefit" of
> protection if the code is built into the kernel image.
There's no operational problem, it will just currently offer no
protections, and once the module side of things HAS been fixed, if any
got marked incorrectly, it'll be discovered then instead of when they
were added.
-Kees
--
Kees Cook
Chrome OS & Brillo 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.
