Date: Mon, 9 Nov 2015 11:33:15 +0100 From: Quentin Casasnovas <quentin.casasnovas@...cle.com> To: kernel-hardening@...ts.openwall.com Subject: Re: Re: Kernel Self Protection Project On Mon, Nov 09, 2015 at 11:02:47AM +0100, Rasmus Villemoes wrote: > On Sat, Nov 07 2015, Quentin Casasnovas <quentin.casasnovas@...cle.com> wrote: > > > On 2015-11-06, Kees Cook <keescook@...omium.org> wrote: > >> On Fri, Nov 6, 2015 at 8:00 AM, Quentin Casasnovas > >><quentin.casasnovas@...cle.com> wrote: > >>>> > >>>> For now, I'm going to focus on taking a look at the PAX_SIZE_OVERFLOW > >>>> gcc plugin, which will also get us the gcc plugin infrastructure. > >>>> Other people, please speak up on what you'd like to tackle. > >>>> > >>> > >>> Not that it's complex but I already have a branch with the gcc plugin > >>> infrastructure split up if you're interested and you reckon that can save > >>> you some time. > >> > >> Sure, what's the URL? > >> > > > > I've pushed the three of them onto: > > > > https://github.com/casasnovas/linux/commits/quentin-spk-gcc-plugin > > > > It lacks Documentation for now, but you can have a look at the branch > > quentin-fuzz-gccplugin which adds an instrumentation plugin (converted from > > the gcc patch Dmitry Vyukov wrote for syzkaller). > > > > Adding a plugin should be simple, add its name to $(HOSTLIBS)-y, and use > > the regular kbuild system way to specify from which source files it is > > built, CFLAGS, etc. > > > > $(HOSTLIBS)-y = foo.so > > foo-objs = foo.c bar.c > > > > And then to have some compilations units be compiled using foo.so, they > > just need the following in their CFLAGS: > > > > -fplugin=$(objtree)/path/to/foo.so > > Nice, thanks. But wouldn't it be even more userfriendly to have these > things driven by Kconfig? So let (use of) each plugin depend on a > CONFIG_GCCPLUGIN_XYZ variable, which will automatically turn itself off > (with a warning) if that plugin can't be used for whatever > reason. That'll also give a natural place to say a little about the > plugin (though I also think Documentation/gccplugins/* should be > created). We could hide these behind CONFIG_USE_GCCPLUGINS to make it > easy for people to turn off. > Ah agreed, this was just so people could get started quickly. The way to do this is to include your plugin flags inside the Makefile variable GCC_PLUGIN_CFLAGS, which is exported and stuffed to the KBUILD_CFLAGS. So if you have plugin foo.so that you want to be used for all of the compilation units (and which depends on CONFIG_FOO), then it should be as simple as doing this in the top-level Makefile: ifeq ($(CONFIG_FOO),y) GCC_PLUGIN_CFLAGS += -fplugin=$(objtree)/path/to/foo.so endif The grsecurity/PaX patchset already deals with gcc version and GCC_PLUGIN_CFLAGS will only be exported if your gcc version supports plugins, otherwise it'll dump a warning and carry on compiling your kernel. Hope that clarifies things :) > > I suppose some plugins are really all-or-nothing (e.g. when randomizing > structs, the various TUs better agree on what shuffling has been done), > so for them it doesn't make sense to apply to individual C files. It was probably a bad example on my side, you'll probably indeed compile your plugins for the whole kernel as opposed to per-file (it's just that I'm using the instrumentation plugin from syzkaller on just a few files at the moment.. so it's the first example that came to my mind). > Is something done to ensure that, and if not, can it be done with some > linker magic? (Something like putting a hash of the used random seed in > each object file and make the linker complain if there are distinct > definitions of that magic symbol.) > I believe/hope the kernel would have trouble booting if there was such a disreptancy here, though this check sounds like a sensible thing to add to be notified early of such unexpected cases! Quentin
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.