All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.