From: Matthias Schniedermeyer <ms@citd.de>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: Eric Sandeen <sandeen@redhat.com>,
Christoph Hellwig <hch@infradead.org>,
xfs <linux-xfs@vger.kernel.org>
Subject: Re: [PATCH] misc: enable retpolines across all xfsprogs utilities
Date: Thu, 22 Feb 2018 22:10:24 +0100 [thread overview]
Message-ID: <20180222211024.GA26034@citd.de> (raw)
In-Reply-To: <20180222171529.GC9827@magnolia>
On 22.02.2018 09:15, Darrick J. Wong wrote:
> On Thu, Feb 22, 2018 at 09:31:41AM -0600, Eric Sandeen wrote:
> > On 2/22/18 9:09 AM, Christoph Hellwig wrote:
> > > On Wed, Feb 21, 2018 at 06:16:25PM -0800, Darrick J. Wong wrote:
> > >> From: Darrick J. Wong <darrick.wong@oracle.com>
> > >>
> > >> Detect and enable retpolines for all code, to mitigate Spectre v2
> > >> (branch target injection) on x86.
> > >
> > > The mechanics look ok, but why do we really care for xfsprogs?
> > > fs utilities seem like a lesser target and should just be covered
>
> They're a smaller target than the kernel, for sure, but the scary part
> about spectre is that unprivileged programs running on the same core as
> a privileged xfs_repair can then use branch predictor poisoning to cause
> problems with the xfs_repair.
Spectre & Meltdown are information disclosure vulnerabilities IOW "Read
Only".
The other process CAN NOT interfere with xfs_repair.
I would speculate that the most it can get, is information about parts
of the filesystem that are inaccsessible to an unprivileged process by
spying on xfs_repair.
I don't know how xfs_repair works, especially how xfs_repair handles
storing data in memory. But for xfs_repair to be a good target, it
would have to store relevant data in a deterministic fashion and for
some length of time. At least enough to justify writing an extraction
program for it.
I would say the 'good old' xfs_repair case isn't really a good target,
but the online-scrubbing-case sure sounds to be a different beast.
In the past you couldn't, for a given point in time, really expect a
xfs_repair process to be running, but with online-scrubbing that game
changes.
--
Matthias
next prev parent reply other threads:[~2018-02-22 21:17 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-22 2:16 [PATCH] misc: enable retpolines across all xfsprogs utilities Darrick J. Wong
2018-02-22 15:09 ` Christoph Hellwig
2018-02-22 15:31 ` Eric Sandeen
2018-02-22 17:15 ` Darrick J. Wong
2018-02-22 21:10 ` Matthias Schniedermeyer [this message]
2018-02-22 23:57 ` Dave Chinner
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=20180222211024.GA26034@citd.de \
--to=ms@citd.de \
--cc=darrick.wong@oracle.com \
--cc=hch@infradead.org \
--cc=linux-xfs@vger.kernel.org \
--cc=sandeen@redhat.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.