Re: [kernel-hardening] [PATCH 2/2] arm: apply more __ro_after_init

From	Kees Cook <keescook@chromium.org>
Newsgroups	linux.kernel
Subject	Re: [kernel-hardening] [PATCH 2/2] arm: apply more __ro_after_init
Date	2016-06-04 00:10 +0200
Message-ID	<rG5rX-uq-7@gated-at.bofh.it> (permalink)
References	<rG2kq-6QU-9@gated-at.bofh.it> <rG2kq-6QU-7@gated-at.bofh.it> <rG2u5-6TX-5@gated-at.bofh.it> <rG4Pf-8ss-3@gated-at.bofh.it> <rG5ih-c6-1@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

On Fri, Jun 3, 2016 at 2:54 PM, Greg KH <gregkh@linuxfoundation.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@linuxfoundation.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@chromium.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

Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

[PATCH 2/2] arm: apply more __ro_after_init Kees Cook <keescook@chromium.org> - 2016-06-03 20:50 +0200
  Re: [kernel-hardening] [PATCH 2/2] arm: apply more __ro_after_init Greg KH <gregkh@linuxfoundation.org> - 2016-06-03 21:00 +0200
    Re: [kernel-hardening] [PATCH 2/2] arm: apply more __ro_after_init Kees Cook <keescook@chromium.org> - 2016-06-03 23:30 +0200
      Re: [kernel-hardening] [PATCH 2/2] arm: apply more __ro_after_init Greg KH <gregkh@linuxfoundation.org> - 2016-06-04 00:00 +0200
        Re: [kernel-hardening] [PATCH 2/2] arm: apply more __ro_after_init Kees Cook <keescook@chromium.org> - 2016-06-04 00:10 +0200

csiph-web