linux-kernel - Re: [PATCH v2] Revert "fuse: Apply flags2 only when userspace set the FUSE_INIT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 27 Oct 2023 12:40:47 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Miklos Szeredi <mszeredi@...hat.com>
Cc:     Linux regressions mailing list <regressions@...ts.linux.dev>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Paul Lawrence <paullawrence@...gle.com>,
        Daniel Rosenberg <drosen@...gle.com>,
        Alessio Balsini <balsini@...roid.com>,
        Amir Goldstein <amir73il@...il.com>,
        Bernd Schubert <bschubert@....com>,
        André Draszik <andre.draszik@...aro.org>
Subject: Re: [PATCH v2] Revert "fuse: Apply flags2 only when userspace set
 the FUSE_INIT_EXT"

On Wed, Oct 25, 2023 at 03:17:09PM +0200, Miklos Szeredi wrote:
> On Wed, Oct 25, 2023 at 1:30 PM Linux regression tracking (Thorsten
> Leemhuis) <regressions@...mhuis.info> wrote:
> 
> > Miklos, I'm wondering what the status here is. The description in the
> > reverts André sent[1] are maybe a bit vague[2], but it sounds a lot like
> > he ran into a big regression that should be addressed somehow -- maybe
> > with a revert. But it seems we haven't got any closer to that in all
> > those ~7 weeks since the first revert was posted. But I might be missing
> > something, hence a quick evaluation from your side would help me a lot
> > here to understand the situation.
> 
> I don't think the Android use case counts as a regression.

Why not?  In the changelog for this commit, it says:

    There is a risk with this change, though - it might break existing user
    space libraries, which are already using flags2 without setting
    FUSE_INIT_EXT.

And that's exactly what Android was doing.  Not all the world uses libfuse,
unfortunatly.

Yes, Android did have an out-of-tree change to support a fuse extension that is
not accepted upstream yet (but I think they submitted it already), and
they had to figure out the "safest" way to do so to keep compability
with everything else.

Now yes, that attempt failed, and now older Android userspace breaks
with newer kernels because of this commit, which you all even agreed
might happen here!

So either you have a policy of "we only care about libfuse use cases for
this api", or you don't, which is fine, just say so.  But that's not
what the changelog says.

> If they'd use an unmodified upstream kernel, it would be a different case.
> 
> But they modify the kernel heavily, and AFAICS this breakage is
> related to such a modification (as pointed out by Bernd upthread).

They add a new fuse extension, yes.  How do you suggest they do so in an
abi-safe way for the future when features are not accepted by upstream?

> André might want to clarify, but I've not seen any concrete real world
> examples of regressions caused by this change outside of Android.

Android is _only_ a few billion devices, it doesn't get much more "real
world" than that.  All other Linux instances are just a rounding error :)

thanks,

gre gk-h