Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151108092717.GH18245@li141-249.members.linode.com>
Date: Sun, 8 Nov 2015 09:27:17 +0000
From: Alyssa Milburn <amilburn@...l.org>
To: kernel-hardening@...ts.openwall.com
Cc: Kees Cook <keescook@...omium.org>, Greg KH <gregkh@...uxfoundation.org>,
	Emese Revfy <re.emese@...il.com>, PaX Team <pageexec@...email.hu>,
	Brad Spengler <spender@...ecurity.net>,
	Theodore Tso <tytso@...gle.com>
Subject: Re: Re: Proposal for kernel self protection
 features

On Fri, Nov 06, 2015 at 09:42:17PM -0800, Josh Triplett wrote:
> (For that matter, as the LLVM Linux project progresses, it might
> actually prove easier to provide a clang-based plugin.)

If anyone is interested in LLVM-based plugins (I've been assuming nobody
is, especially since LLVMLinux seems to have been pretty quiet recently),
I've been investigating security improvements via compiler plugins as part
of my MSc project, and I'd love to write LLVM/clang passes/analyses if
anyone has any particular wishes for them. (But trying to replicate this in
gcc plugins is not something I can justify at present, especially since
Emese already has many covered.)

I already partially reimplemented a couple of the plugins from the
grsecurity patchset, but right now they're a mess bound up in all of my
other code (and I have no nice infrastructure, just hacks resting on top of
the last version of LLVMLinux + patches + LTO + LTO-on-LLVM + ...). On the
kernel side I just wanted to see how *this* vulnerability could have been
mitigated with *that* technique for *this* performance penalty, so as long
as I can compile+boot a kernel for benchmarking, I've been happy.

- Alyssa

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.