[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <56496AB0.5070905@gmail.com>
Date: Mon, 16 Nov 2015 00:33:36 -0500
From: Daniel Micay <danielmicay@...il.com>
To: kernel-hardening@...ts.openwall.com
Subject: Re:
On 15/11/15 03:59 PM, Richard Weinberger wrote:
> On Fri, Nov 13, 2015 at 4:43 PM, west suhanic <west.suhanic@...il.com> wrote:
>> Hello All:
>>
>> I am a hardened gentoo user. How can we get the grsecurity code into the
>> kernel?
>
> As soon all downsides and drawbacks are identified/resolved.
> Which basically means that we have to redo a lot (it not all).
You might not be familiar with the grsecurity/PaX features and their
implementations but lots of people are. It's not unexplored territory
without known trade-offs. It has active developers who are happy to
answer questions about it (within reason).
I think there's little that would need to be redone. There are many
things that would need to be renamed and refactored in order to present
them in a different light to deal with political issues. One good way to
upstream stuff would be presenting it from the angle that it's useful
for finding kernel bugs for *everyone* and just accepting that some of
it is going to be misrepresented (i.e. CONFIG_DEBUG_*).
Approaching this as if it's a technical issue is only going to lead to
failure. I really can't see Linus and others being okay with any GCC
plugins with alterations to the semantics of C rather than just codegen
like the KERNEXEC plugin. Dropping time into extracting stuff like that
rather than realistic things seems wasteful. If someone puts in the
effort to do it, submits it and hits a wall then I wouldn't expect them
to be motivated to do more.
I think there's plenty that could be landed but going directly upstream
may not be the way to go. I was considering spending time on doing most
of the small features and submitting them to AOSP. No politics to deal
with there, only technical issues. If something lands there, it becomes
a lot easier to upstream it because it becomes part of trying to get
Android to use a vanilla kernel. Android wants security features and
Linux isn't delivering, so it might as well start diverging more. For
example, they recently started improving their ASLR implementation
towards matching PaX (not there yet). I'm sure they'd take features like
USERCOPY as-is.
Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)
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.
