lkml.org 
[lkml]   [2019]   [Mar]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [RFC PATCH] x86/entry/64: randomize kernel stack offset upon syscall
Date
> On Mon, Mar 18, 2019 at 1:16 PM Andy Lutomirski <luto@kernel.org> wrote:
> > On Mon, Mar 18, 2019 at 2:41 AM Elena Reshetova
> > <elena.reshetova@intel.com> wrote:
> > > Performance:
> > >
> > > 1) lmbench: ./lat_syscall -N 1000000 null
> > > base: Simple syscall: 0.1774 microseconds
> > > random_offset (rdtsc): Simple syscall: 0.1803 microseconds
> > > random_offset (rdrand): Simple syscall: 0.3702 microseconds
> > >
> > > 2) Andy's tests, misc-tests: ./timing_test_64 10M sys_enosys
> > > base: 10000000 loops in 1.62224s = 162.22 nsec / loop
> > > random_offset (rdtsc): 10000000 loops in 1.64660s = 164.66 nsec / loop
> > > random_offset (rdrand): 10000000 loops in 3.51315s = 351.32 nsec / loop
> > >
> >
> > Egads! RDTSC is nice and fast but probably fairly easy to defeat.
> > RDRAND is awful. I had hoped for better.
>
> RDRAND can also fail.
>
> > So perhaps we need a little percpu buffer that collects 64 bits of
> > randomness at a time, shifts out the needed bits, and refills the
> > buffer when we run out.
>
> I'd like to avoid saving the _exact_ details of where the next offset
> will be, but if nothing else works, this should be okay. We can use 8
> bits at a time and call prandom_u32() every 4th call. Something like
> prandom_bytes(), but where it doesn't throw away the unused bytes.

Actually I think this would make the end result even worse security-wise
than simply using rdtsc() on every syscall. Saving the randomness in percpu
buffer, which is probably easily accessible and can be probed if needed,
would supply attacker with much more knowledge about the next 3-4
random offsets that what he would get if we use "weak" rdtsc. Given
that for a successful exploit, an attacker would need to have stack aligned
once only, having a knowledge of 3-4 next offsets sounds like a present to an
exploit writer... Additionally it creates complexity around the code that I
have issues justifying with "security" argument because of above...

I have the patch now with alloca() and rdtsc() working, I can post it
(albeit it is very simple), but I am really hesitating on adding the percpu
buffer randomness storage to it...

Best Regards,
Elena.
\
 
 \ /
  Last update: 2019-03-26 11:36    [W:0.126 / U:0.256 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site