On Wed, Feb 28, 2018 at 11:26:27AM -0800, Darrick J. Wong wrote:
> On Wed, Feb 28, 2018 at 03:03:09AM -0500, Theodore Ts'o wrote:
> > Since e2fsprogs 1.44.0 will have a lot of new features over the 1.43.x
> > releases, I've released e2fsprogs 1.44.0-rc1 on kernel.org and
>
> Uhoh, I wasn't expecting this out so soon. I was going to send you a
> second round of e2scrub patches, and a few others to enable fancy debug
> tools like {ub,addr}san, LTO, and retpolines. Is it too late for that?
I wasn't planning on having e2scrub land in 1.44 anyway. I'd much
rather try to get us onto a faster release candence for features,
rather than to let 1.44 stretch on any further....
> TBH I've been meaning to ask about whether it makes sense to build
> e2fsprogs (or at least e2fsck) with retpolines but haven't had a chance
> to converse about it for a couple of weeks.
My immediate reaction is that it's not as all clear how an attacker
might be able to use Spectre and a maliciously crafted file system to
achieve some goal while e2fsck is running. It might be more likely to
be an issue with fuse2fs if someone can access the FUSE mounted file
system in a less trusted security domain than the one in which fuse2fs
is running. So if we do it we'll probably want to do this at all,
we'll want to do this for all of e2fsprogs, not just e2fsck.
This is also something we can probably add in the 1.44.x maintenance
release, since it shouldn't require any code changes in e2fsprogs; the
question is how much the compiler with the retoptline patches is
trusted to be stable.
Cheers,
- Ted
