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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CALCETrXnfk5zYWmpdLvYbcJ7hhFM13+LPq14MF7s99iqtS4-jg@mail.gmail.com>
Date:   Tue, 26 Mar 2019 21:31:01 -0700
From:   Andy Lutomirski <luto@...nel.org>
To:     "Reshetova, Elena" <elena.reshetova@...el.com>
Cc:     Kees Cook <keescook@...omium.org>,
        Andy Lutomirski <luto@...nel.org>,
        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 Tue, Mar 26, 2019 at 3:35 AM Reshetova, Elena
<elena.reshetova@...el.com> wrote:
>
> > 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...
>

Hmm.  I guess it depends on what types of attack you care about.  I
bet that, if you do a bunch of iterations of mfence;rdtsc;syscall,
you'll discover that the offset between the user rdtsc and the
syscall's rdtsc has several values that occur with high probability.

--Andy