From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: speck@linutronix.de
Subject: [MODERATED] Re: cBPF affectedness (was Re: [PATCH 0/5] SSB extra 0)
Date: Wed, 23 May 2018 06:56:00 -0700 [thread overview]
Message-ID: <20180523135558.qdetn46zevlkfil6@ast-mbp> (raw)
In-Reply-To: <nycvar.YFH.7.76.1805230913040.27054@cbobk.fhfr.pm>
On Wed, May 23, 2018 at 09:17:06AM +0200, speck for Jiri Kosina wrote:
> On Fri, 4 May 2018, speck for Kees Cook wrote:
>
> > > >> BPF is a potential source of gadgets that can be used for memory=20
> > > >> diambiguation-based attacks. To help mitigate these, we enable the
> > > >> bit in SPEC_CTRL which enables the reduced (memory) speculation
> > > >> mode on the processor when runing BPF code.
> > > >=20
> > > > Do you mean eBPF, or even cBPF?=20
> > >=20
> > > Right or wrong, my assumption is that you can build gadgets with any of
> > > the variants. I haven't looked into detail to whether the classic VM
> > > and enhanced VM have the building blocks.
> > > [...]
> > > Were we just not concerned before because seccomp didn't use arrays?
> >
> > My understanding from Jann Horn (who looked at the seccomp cases before)
> > was that eBPF maps were required for SpectreV1. I've asked him for
> > clarification on SSB, but I think the reasoning holds there too.
> >
> > Specifically, my memory of the details are that since seccomp uses a
> > subset of even cBPF and can only use absolute indexing (not dynamic), cBPF
> > programs cannot be constructed that do array access outside of the seccomp
> > data buffer (which consists entirely of userspace information: pid,
> > syscall number, syscall arguments), not even from the 16-byte "scratch"
> > space. i.e. the seccomp cBPF verifier, seccomp_check_filter(), results
> > in no seccomp cBPF programs having the "untrusted_offset_from_caller"
> > indexing (to borrow the variable name from the Project Zero write-up on
> > SpectreV1). It also has no maps (so there cannot be data sharing between
> > multiple seccomp cBPF programs nor to the outside world). And finally,
> > the only "visible" output from seccomp is via syscall behaviors, which
> > would create too much noise for that exfiltration path.
> >
> > Note, though, that I am not an expert in eBPF nor writing speculation
> > exploits. Which gets us to the next question...
>
> Now that Alexei is on this list, let me bring the question of
> (seccomp-)cBPF up again.
>
> Specifically I am of course asking to see whether we need any kind of
> mitigation in pre-eBPF (and also pre-1be7f75d1668 eBPF) kernels.
You mean whether SSB exploit can be made to work with cBPF ?
I don't think so. Classic BPF doesn't have a concept of pointers.
next prev parent reply other threads:[~2018-05-23 13:56 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-03 22:29 [MODERATED] [PATCH 0/5] SSB extra 0 Dave Hansen
2018-05-03 22:29 ` [MODERATED] [PATCH 1/5] SSB extra 2 Dave Hansen
2018-05-03 22:29 ` [MODERATED] [PATCH 2/5] SSB extra 3 Dave Hansen
2018-05-03 22:29 ` [MODERATED] [PATCH 3/5] SSB extra 1 Dave Hansen
2018-05-03 22:29 ` [MODERATED] [PATCH 4/5] SSB extra 5 Dave Hansen
2018-05-03 22:29 ` [MODERATED] [PATCH 5/5] SSB extra 4 Dave Hansen
2018-05-03 23:27 ` [MODERATED] Re: [PATCH 0/5] SSB extra 0 Kees Cook
2018-05-04 1:37 ` Dave Hansen
2018-05-04 22:26 ` Kees Cook
2018-05-23 7:17 ` [MODERATED] cBPF affectedness (was Re: [PATCH 0/5] SSB extra 0) Jiri Kosina
2018-05-23 13:56 ` Alexei Starovoitov [this message]
2018-05-04 9:20 ` [MODERATED] Re: [PATCH 1/5] SSB extra 2 Peter Zijlstra
2018-05-04 14:04 ` Dave Hansen
2018-05-04 15:50 ` Peter Zijlstra
2018-05-04 15:54 ` Linus Torvalds
2018-05-04 13:33 ` [PATCH 3/5] SSB extra 1 Thomas Gleixner
2018-05-04 14:22 ` [MODERATED] " Dave Hansen
2018-05-04 14:26 ` Thomas Gleixner
2018-05-04 16:04 ` [MODERATED] " Andi Kleen
2018-05-04 16:09 ` Thomas Gleixner
2018-05-04 16:28 ` [MODERATED] " Andi Kleen
2018-05-04 16:32 ` Thomas Gleixner
2018-05-04 16:43 ` [MODERATED] " Dave Hansen
2018-05-04 18:39 ` Thomas Gleixner
2018-05-06 8:32 ` Thomas Gleixner
2018-05-06 21:48 ` Thomas Gleixner
2018-05-06 22:40 ` [MODERATED] " Dave Hansen
2018-05-07 6:19 ` Thomas Gleixner
2018-05-04 17:01 ` [MODERATED] Re: [PATCH 4/5] SSB extra 5 Konrad Rzeszutek Wilk
2018-05-21 9:56 ` [MODERATED] Re: [PATCH 5/5] SSB extra 4 Jiri Kosina
2018-05-21 13:38 ` 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=20180523135558.qdetn46zevlkfil6@ast-mbp \
--to=alexei.starovoitov@gmail.com \
--cc=speck@linutronix.de \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).