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: <ZLm3LLrsSPYkLYr4@casper.infradead.org>
Date:   Thu, 20 Jul 2023 23:37:32 +0100
From:   Matthew Wilcox <willy@...radead.org>
To:     Jeffrey Walton <noloader@...il.com>
Cc:     John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        Viacheslav Dubeyko <slava@...eyko.com>,
        Arnd Bergmann <arnd@...db.de>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        syzbot <syzbot+7bb7cd3595533513a9e7@...kaller.appspotmail.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        christian.brauner@...ntu.com,
        Damien Le Moal <damien.lemoal@...nsource.wdc.com>,
        Jeff Layton <jlayton@...nel.org>,
        Linux FS Devel <linux-fsdevel@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        syzkaller-bugs@...glegroups.com,
        ZhangPeng <zhangpeng362@...wei.com>,
        linux-m68k@...ts.linux-m68k.org,
        debian-ports <debian-ports@...ts.debian.org>
Subject: Re: [syzbot] [hfs?] WARNING in hfs_write_inode

On Thu, Jul 20, 2023 at 05:38:52PM -0400, Jeffrey Walton wrote:
> On Thu, Jul 20, 2023 at 2:39 PM Matthew Wilcox <willy@...radead.org> wrote:
> >
> > On Thu, Jul 20, 2023 at 07:50:47PM +0200, John Paul Adrian Glaubitz wrote:
> > > > Then we should delete the HFS/HFS+ filesystems.  They're orphaned in
> > > > MAINTAINERS and if distros are going to do such a damnfool thing,
> > > > then we must stop them.
> > >
> > > Both HFS and HFS+ work perfectly fine. And if distributions or users are so
> > > sensitive about security, it's up to them to blacklist individual features
> > > in the kernel.
> > >
> > > Both HFS and HFS+ have been the default filesystem on MacOS for 30 years
> > > and I don't think it's justified to introduce such a hard compatibility
> > > breakage just because some people are worried about theoretical evil
> > > maid attacks.
> > >
> > > HFS/HFS+ mandatory if you want to boot Linux on a classic Mac or PowerMac
> > > and I don't think it's okay to break all these systems running Linux.
> >
> > If they're so popular, then it should be no trouble to find somebody
> > to volunteer to maintain those filesystems.  Except they've been
> > marked as orphaned since 2011 and effectively were orphaned several
> > years before that (the last contribution I see from Roman Zippel is
> > in 2008, and his last contribution to hfs was in 2006).
> 
> One data point may help.. I've been running Linux on an old PowerMac
> and an old Intel MacBook since about 2014 or 2015 or so. I have needed
> the HFS/HFS+ filesystem support for about 9 years now (including that
> "blessed" support for the Apple Boot partition).
> 
> There's never been a problem with Linux and the Apple filesystems.
> Maybe it speaks to the maturity/stability of the code that already
> exists. The code does not need a lot of attention nowadays.
> 
> Maybe the orphaned status is the wrong metric to use to determine
> removal. Maybe a better metric would be installation base. I.e., how
> many users use the filesystem.

I think you're missing the context.  There are bugs in how this filesystem
handles intentionally-corrupted filesystems.  That's being reported as
a critical bug because apparently some distributions automount HFS/HFS+
filesystems presented to them on a USB key.  Nobody is being paid to fix
these bugs.  Nobody is volunteering to fix these bugs out of the kindness
of their heart.  What choice do we have but to remove the filesystem,
regardless of how many happy users it has?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ