[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAG48ez0r7UL675rxW-EypnfR+tF4LWT_GQkCevg7bTj9TkBM0Q@mail.gmail.com>
Date: Fri, 12 Oct 2018 17:41:49 +0200
From: Jann Horn <jannh@...gle.com>
To: Alan Cox <gnomes@...rguk.ukuu.org.uk>
Cc: Andy Lutomirski <luto@...capital.net>, Andy Lutomirski <luto@...nel.org>,
Kees Cook <keescook@...omium.org>, kristen@...ux.intel.com,
Kernel Hardening <kernel-hardening@...ts.openwall.com>, Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, "H . Peter Anvin" <hpa@...or.com>,
"the arch/x86 maintainers" <x86@...nel.org>, kernel list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86: entry: flush the cache if syscall error
On Fri, Oct 12, 2018 at 5:03 PM Alan Cox <gnomes@...rguk.ukuu.org.uk> wrote:
>
> > My understanding is that the standard “breadcrumb” is that a cache line is fetched into L1D, and that the cacheline in question will go into L1D even if it was previously not cached at all. So flushing L1D will cause the timing from a probe to be different, but the breadcrumb is still there, and the attack will still work.
>
> Flush not write back. The L1D is empty (or full of other stuff the way
> the prototype I tested did it as x86 lacked a true L1 flushing primitive)
What about the TLB? Once KPTI is unnecessary, are you going to need an
extra TLB flush here to prevent PRIME+PROBE on the TLB?
Also: Are you assuming that the attacker would only be able to do
PRIME+PROBE, not FLUSH+RELOAD or other attacks that rely on shared
memory (like FLUSH+FLUSH, or the MESI-based stuff that detects when a
line stops being in modified state on another core)?
> > > At best you have a microscopic window to attack it on the SMT pair.
> >
> > So only the extra clever attackers will pull it off. This isn’t all that reassuring.
>
> It's going to be very hard for them to do that. You don't really have the
> timing control in userspace to do that sort of thing easily.
>
> At the end of the day it's an additional hardenening not a fix. It's
> designed to provide extra protection for the cases we don't know about
> until we find them and lfence them. All of this (and all sidechannel of
> any kind) is merely about reducing the bandwidth an attacker can achieve.
>
> The idea is that it's cheap enough that it's worth doing.
>
> > Or I would get a fancy new CPU and use UMONITOR and, unless UMONITOR is much cleverer than I suspect it is, the gig is up. The time window for the attack could be as small as you want, and UMONITOR will catch it.
>
> That would be an interesting line of attack. You would still have to
> navigate a fair bit of noise.
>
> Alan
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.
