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]
Message-ID: <2023102731-wobbly-glimpse-97f5@gregkh>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ