From: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
To: Andy Lutomirski <luto@kernel.org>
Cc: Kees Cook <keescook@chromium.org>,
Kristen Carlson Accardi <kristen@linux.intel.com>,
Kernel Hardening <kernel-hardening@lists.openwall.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
"H. Peter Anvin" <hpa@zytor.com>, X86 ML <x86@kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] x86: entry: flush the cache if syscall error
Date: Fri, 12 Oct 2018 15:25:15 +0100 [thread overview]
Message-ID: <20181012152515.1d816906@alans-desktop> (raw)
In-Reply-To: <CALCETrVG5=iqfohYxKSvAQx3DhzD95MhmDU3mU8+kCegps2cbw@mail.gmail.com>
> But this really needs to be clarified. Alan said that a bunch of the
> "yet another Spectre variant" attacks would have been mitigated by
> this patch. An explanation of *how* would be in order.
Today you have the situation where something creates a speculative
disclosure gadget. So we run around and we try and guess where to fix
them all with lfence. If you miss one then it leaves a trace in the L1D
cache, which is what you measure.
In almost every case we have looked at when you leave a footprint in the
L1D you resolve to an error path so the syscall errors.
In other words every time we fail to find a
if (foo < limit) {
gadget(array[foo]);
} else
return -EINVAL;
we turn that from being an easy to use gadget into something really
tricky because by the time the code flow has gotten back to the caller
the breadcrumbs have been eaten by the L1D flush.
The current process of trying to find them all with smatch and the like
is a game of whack-a-mole that will go on for a long long time. In the
meantime (and until the tools get better) it's nice to have an option
that takes a totally non-hot path (the fast path change is a single test
for >= 0) and provides additional defence in depth.
They are not hot paths: when I started playing with this idea I did
indeed strace my entire desktop for a day. There are couple of other
cases I would add to the pass list (EAGAIN, EWOULDBLOCK)). Tracing
other stuff you see the same - real world workloads simply don't generate
vast spews of erroring syscalls.
Look just how many examples we are still committing like
de916736aaaadddbd6061472969f667b14204aa9
7b6924d94a60c6b8c1279ca003e8744e6cd9e8b1
46feb6b495f7628a6dbf36c4e6d80faf378372d4
55690c07b44a82cc3359ce0c233f4ba7d80ba145
This approach turns the ones we miss into
if (type > =
[speculatively create breadcrumb]
condition resolves, return -EINVAL
L1D flush
No breadcrumbs
At best you have a microscopic window to attack it on the SMT pair.
Alan
next prev parent reply other threads:[~2018-10-12 14:27 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-11 18:54 [PATCH] x86: entry: flush the cache if syscall error Kristen Carlson Accardi
2018-10-11 19:25 ` Andy Lutomirski
2018-10-11 20:15 ` Kristen C Accardi
2018-10-11 20:25 ` Alan Cox
2018-10-11 20:47 ` Andy Lutomirski
2018-10-12 9:20 ` Samuel Neves
2018-10-12 13:25 ` Jann Horn
2018-10-12 14:28 ` Samuel Neves
2018-10-11 20:48 ` Andy Lutomirski
2018-10-11 20:55 ` Kees Cook
2018-10-11 21:17 ` Andy Lutomirski
2018-10-11 22:11 ` Jann Horn
2018-10-12 14:25 ` Alan Cox [this message]
2018-10-12 14:43 ` Andy Lutomirski
2018-10-12 15:02 ` Alan Cox
2018-10-12 15:41 ` Jann Horn
2018-10-12 16:07 ` Andy Lutomirski
2018-10-11 21:23 ` Kristen C Accardi
2018-10-11 23:43 ` Thomas Gleixner
2018-10-11 21:42 ` Jann Horn
2018-10-11 23:15 ` Thomas Gleixner
2018-10-11 22:33 ` Thomas Gleixner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181012152515.1d816906@alans-desktop \
--to=gnomes@lxorguk.ukuu.org.uk \
--cc=bp@alien8.de \
--cc=hpa@zytor.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=kristen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox