[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 10 Sep 2018 09:03:48 -0700
From: Kees Cook <keescook@...omium.org>
To: Yves-Alexis Perez <corsac@...ian.org>
Cc: Konstantin Ryabitsev <konstantin@...uxfoundation.org>,
Kernel Hardening <kernel-hardening@...ts.openwall.com>, Daniel Micay <danielmicay@...il.com>
Subject: Re: "Hardened" tree on kernel.org?
On Mon, Sep 10, 2018 at 5:24 AM, Yves-Alexis Perez <corsac@...ian.org> wrote:
> On Fri, 2018-08-31 at 13:44 -0400, Konstantin Ryabitsev wrote:
>> Do you think this would be a worthwhile thing, or would that distract
>> from overall mainlining goals?
>
> I think it would be a nice addition. There are already bits here and there,
> the most prominent one being https://github.com/thestinger/linux-hardened /
> https://github.com/AndroidHardeningArchive/linux-hardened from Daniel Micay
> (added to CC although I guess he's subscribed)
>
> Maybe Kees maintains KSSP-related stuff somewhere.
>
> I think having a central repository of “vouched” stuff would be nice, even it
> includes things not ready for mainline.
KSPP is just a "focus group" of the upstream kernel, not a separate
project, so we're part of the regular development cycle and practices.
Therefore linux-next is where things live before getting merged. For
work that has an obvious upstream maintainer (e.g. arch-specific
hardening) live in their respective trees (e.g. refcount_t went in via
tip/atomic). For less-obvious stuff, or for when I'm the maintainer it
goes via my for-next/kspp tree. An example would be that the stackleak
gcc plugin has been kept up to date there (by Alexander) for several
upstream releases while it continues to get buffeted by review.
Some things aren't ready for merging (e.g. XPFO, SARA, Landlock) due
to needed dependencies or improvements. While each of these have
versions of their patches that work against specific kernel versions,
keeping them forward-ported is a non-trivial bit of work. The
individual authors have been doing that work when they have time and
are doing their next revision, for example. But as such, there isn't
really a "single repository" of hardening work. The effort to
stabilize patches has been focused on getting them into upstream.
So, yes, tl;dr would be: there isn't a separate collection because
I've been trying to get people to focus on upstreaming. Having another
fork doesn't really help the general public. (That said, there _are_
people with distro-like forks of the kernel that HAVE been collecting
things, but I haven't been tracking them: please speak up if you want
to let people know about the work!)
-Kees
--
Kees Cook
Pixel Security
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.
