Re: [kernel-hardening] Introduction

[Daniel Micay <danielmicay@gmail.com>]

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

On Thu, 2015-12-17 at 16:36 -0800, Kees Cook wrote:
> On Thu, Dec 17, 2015 at 3:34 PM, Leibowitz, Michael
> <michael.leibowitz@intel.com> wrote:
> > I work in Intel's Open Source Technology center, along with my
> > colleague, Elena Reshetova.  I'm reasonably new real-life kernel
> > development, having previously just mucked about.  Otherwise, I'm a
> > long-time open source/security trouble maker.
> 
> Hi! Welcome! :)
> 
> > I'm Interested in working on struct randomization ala RANDSTRUCT.
> > Does this seem like a suitable task?
> 
> I certainly wouldn't turn it down, but I would observe that it has
> some limited utility to users of the kernel that produce binary
> builds. e.g. all the given builds of Ubuntu with RANDSTRUCT would be
> the same (though the next released version would see a different
> randomization, etc). It also complicates externally built modules. I
> see it depends on HIDESYM, though, which in turn depends on
> PAX_USERCOPY, so it would be much weaker without these two finished
> first.
> 
> All that said, it might still be an interesting piece to extract. It
> would make automated cross-distro or cross-version attacks much more
> difficult to mount and has in the past exposed some bugs. (e.g.
> missing container_of() uses, etc.)

AFAIK spender was planning on implementing stack frame layout
randomization too (not sure if it's done yet) and that wouldn't have the
same ABI implications. They could be offered separately.

LLVM also has some code diversity stuff in progress like randomizing instruction scheduling to an extent (can at least determine any of the arbitrary decisions with random choices), and it would make sense for GCC too.

It can be more useful for builds distributions as binaries than it
seems. Making 256 or more builds with the tarballs padded out to the
same size and distributing them via encryption connections wouldn't be
difficult. It would be more difficult to implement for Android and
ChromeOS since they use delta updates but it could be done by having a
bunch of different release channels for each device. It might really
screw up delta updates if it's used across the system though, but the
kernel alone wouldn't be that bad.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]