All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Micay <danielmicay@gmail.com>
To: kernel-hardening@lists.openwall.com
Subject: Re: [kernel-hardening]
Date: Mon, 16 Nov 2015 00:33:36 -0500	[thread overview]
Message-ID: <56496AB0.5070905@gmail.com> (raw)
In-Reply-To: <CAFLxGvxukmvg9jHWXO=-Bbn3eoNrqwFvWsS-v_R99McPU4n_sg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2172 bytes --]

On 15/11/15 03:59 PM, Richard Weinberger wrote:
> On Fri, Nov 13, 2015 at 4:43 PM, west suhanic <west.suhanic@gmail.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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2015-11-16  5:33 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-13 15:43 [kernel-hardening] west suhanic
2015-11-13 22:23 ` [kernel-hardening] Valdis.Kletnieks
2015-11-13 23:21   ` [kernel-hardening] David Windsor
2015-11-15 20:59 ` [kernel-hardening] Richard Weinberger
2015-11-16  5:33   ` Daniel Micay [this message]
2015-11-16  5:45     ` [kernel-hardening] Daniel Micay
2015-11-16  6:38       ` [kernel-hardening] David Windsor
2015-11-16 22:03         ` [kernel-hardening] Daniel Micay
2015-11-16 23:20           ` [kernel-hardening] Kees Cook
2015-11-16 23:17         ` [kernel-hardening] Kees Cook
2015-11-16 12:13     ` [kernel-hardening] Richard Weinberger
2015-11-17  7:41       ` [kernel-hardening] Daniel Micay
2015-11-17 10:32         ` [kernel-hardening] Richard Weinberger
2015-11-16 23:14     ` [kernel-hardening] Kees Cook
2015-11-17  8:09       ` [kernel-hardening] Daniel Micay
2015-11-17 17:30         ` [kernel-hardening] Kees Cook

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56496AB0.5070905@gmail.com \
    --to=danielmicay@gmail.com \
    --cc=kernel-hardening@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.