linux-kernel - Re: [syzbot] [ext4?] kernel panic: EXT4-fs (device loop0): panic forced after error (3)

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: <20230818142544.GA3513305@mit.edu>
Date:   Fri, 18 Aug 2023 10:25:44 -0400
From:   "Theodore Ts'o" <tytso@....edu>
To:     Eric Biggers <ebiggers@...nel.org>
Cc:     sandeen@...hat.com,
        syzbot <syzbot+27eece6916b914a49ce7@...kaller.appspotmail.com>,
        adilger.kernel@...ger.ca, linux-ext4@...r.kernel.org,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        llvm@...ts.linux.dev, nathan@...nel.org, ndesaulniers@...gle.com,
        syzkaller-bugs@...glegroups.com, trix@...hat.com
Subject: Re: [syzbot] [ext4?] kernel panic: EXT4-fs (device loop0): panic
 forced after error (3)

On Thu, Aug 17, 2023 at 07:52:55PM -0700, Eric Biggers wrote:
> Obviously it's up to the system administrator; that should have been clear since
> I suggested a sysctl.  Sorry if I wasn't clear.  The point is that there are
> certain conventions for what is allowed to break the safety guarantees that the
> kernel provides to userspace, which includes causing a kernel panic.  Panics on
> various problems are configured by /proc/sys/kernel/panic_*.  So having to
> opt-in to panic-on-error, or at least being able to opt-out, by setting a sysctl
> seems natural.  Whereas having mount() being able to automatically panic the
> kernel with no way to opt-out seems like a violation of broader kernel
> conventions, even if it happens to be "working as intended" in the ext4 context.

The reason why a sysctl isn't really great is because the system
administrator might want to configure the behavior on a per-file
system basis.  And you *can* configure it as a mount option, via
"mount -o errors=continue" or "mount -o "errors=panic".  The
superblock setting is just the default if something isn't explicitly
specified as a mount option (either on the command line or in
/etc/fstab).

So mount does not "automatically" panic the kernel, and there are
*plenty* of ways to opt-out.  You can use the mount option; you can
run "tune2fs -e continue"; you can just !@...! run fsck.ext4 before
mounting the file system.  There are all ways of "opting out."  Some
of them, such as the last, is even considered best practice --- just
as picking up a USB stick, or worse, a firewire drive, in a parking
lot, and *not* plugging it into your laptop is considered best practice.

	     	  	    	      	       - Ted