linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Matthias Schniedermeyer <ms@citd.de>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>,
	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: Fri, 23 Feb 2018 10:57:58 +1100	[thread overview]
Message-ID: <20180222235758.GI7000@dastard> (raw)
In-Reply-To: <20180222211024.GA26034@citd.de>

On Thu, Feb 22, 2018 at 10:10:24PM +0100, Matthias Schniedermeyer wrote:
> On 22.02.2018 09:15, Darrick J. Wong wrote:
> > 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.

Yup, that's enough to leak private information. e.g. encryption keys
stored in extended attributes...

> 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.

Oh, yeah, we've got this whopping great big buffer cache that can
cache all the metadata it reads from disk in memory while repair
does it's validation work. It's a pretty big target from that
perspective. That's made even worse if you consider a large
filesystem that takes days for xfs_repair to completely check....

> 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.

Scrubbing is done in the kernel, with metadata cached in kernel
memory, so it's already protected by whatever kernel mitigations are
in place.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

      reply	other threads:[~2018-02-22 23:58 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
2018-02-22 23:57         ` Dave Chinner [this message]

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=20180222235758.GI7000@dastard \
    --to=david@fromorbit.com \
    --cc=darrick.wong@oracle.com \
    --cc=hch@infradead.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=ms@citd.de \
    --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 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 NNTP newsgroup(s).