Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 29 Nov 2015 16:39:18 +0100
From: Ingo Molnar <>
To: PaX Team <>
Cc: Linus Torvalds <>,,
	Mathias Krause <>,
	"" <>,
	Kees Cook <>,
	Andy Lutomirski <>,
	Ingo Molnar <>,
	Thomas Gleixner <>,
	"H. Peter Anvin" <>, x86-ml <>,
	Arnd Bergmann <>,
	Michael Ellerman <>,,
	Emese Revfy <>
Subject: Re: [PATCH 0/2] introduce post-init read-only

* PaX Team <> wrote:

> On 29 Nov 2015 at 9:08, Ingo Molnar wrote:
> > 
> > * PaX Team <> wrote:
> > 
> > > i don't see the compile time vs. runtime detection as 'competing' approaches, 
> > > both have their own role. [...]
> > 
> > That's true - but only as long as 'this can be solved in tooling!' is not used as 
> > an excuse to oppose the runtime solution and we end up doing neither.
> actually, i already voiced my opinion elsewhere in the constify thread on the 
> kernel hardening list that adding/using __read_only is somewhat premature 
> without also adding the compile time verification part (as part of the constify 
> plugin for example). right now its use on the embedded vdso image is simple and 
> easy to verify but once people begin to add it to variables that the compiler 
> knows and cares about (say, the ops structures) then things can become fragile 
> without compile checking. so yes, i'd also advise to get such tooling in 
> *before* more __read_only usage is added.

I think you are mistaken there: if we add the page fault fixup to make sure we 
don't crash if a read-only variable is accessed, then we'll have most of the 
benefits of read-only mappings and no fragility - without having to wait for 



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.