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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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: [kernel-hardening] [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