tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: FFS: wrong superblock check ~> crash



Manuel Bouyer <bouyer%antioche.eu.org@localhost> wrote:
> On Mon, Oct 20, 2014 at 07:48:31PM +0100, Mindaugas Rasiukevicius wrote:
> > > definitively not. I want a panic. If the filesystsem is corrupted
> > > something has gone really wrong and you can't trust the running system
> > > any more. And there are cases where returning EROFS is worse than
> > > panicing (e.g. a NFS server).
> > 
> > Disagree.  The kernel should remount the file system in read-only mode.
> > 
> > Perhaps we can debate what to do with corrupted / when the system is
> > booting, but for other cases (especially hot-plug or external disks)
> > I certainly do not expect a crash.
> 
> I do, it's the only sane thing to do if the systen did write bogus
> data to the disk and notice it later. Remounting in read-only mode
> on a server with active services running doens't do anything good
> (I know because linux servers do this. A panic and reboot is a much
> better behavior).

Huh?  If your use case is a single / partition for everything then sure.
I can actually extend my statement: the system should not crash neither
in a case of corrupt file system nor a disk failure (which may or may not
lead to corrupt file system).

If I have a system with an array of disks and one of them fails, a crash
would take down the whole node.  When many terabytes of data suddenly
disappear people get unhappy; it usually costs quite a bit of money too.
So, how about making only the *failed* segment of data unavailable?  In
many cases this is suitable and desirable; consider distributed systems
(you have redundancy) or caches (where I can just discard the corrupted
data segment and refetch it from the origin).  Meanwhile, I can replace
the failed disk and/or rebuild the corrupt file system while experiencing
only a limited disruption.

> If the corrupted filesystem is from a corrupted USB key then not panicing
> is probably better; but 1) USB keys usually don't have ffs on them 2)
> In such case it would be better to run the filesystem code in userland
> anyway.

So now you make an assumption about file systems used on USB sticks?
That does not matter.  Somebody can create a USB stick with manually
handcrafted superblock to crash your machine or maybe even exploit it.
To me, that constitutes a security vulnerability.

-- 
Mindaugas


Home | Main Index | Thread Index | Old Index