linux-kernel - RE: [RFC PATCH] x86/entry/64: randomize kernel stack offset upon syscall

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 26 Mar 2019 10:35:51 +0000
From:   "Reshetova, Elena" <elena.reshetova@...el.com>
To:     Kees Cook <keescook@...omium.org>,
        Andy Lutomirski <luto@...nel.org>
CC:     Josh Poimboeuf <jpoimboe@...hat.com>, Jann Horn <jannh@...gle.com>,
        "Perla, Enrico" <enrico.perla@...el.com>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Thomas Gleixner <tglx@...utronix.de>,
        LKML <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        "Greg KH" <gregkh@...uxfoundation.org>
Subject: RE: [RFC PATCH] x86/entry/64: randomize kernel stack offset upon
 syscall

> On Mon, Mar 18, 2019 at 1:16 PM Andy Lutomirski <luto@...nel.org> wrote:
> > On Mon, Mar 18, 2019 at 2:41 AM Elena Reshetova
> > <elena.reshetova@...el.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.