Page MenuHomeFreeBSD

stand: check for short reads in ufs
AcceptedPublic

Authored by rlibby on Thu, Sep 3, 11:32 PM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Sep 23, 12:04 AM
Unknown Object (File)
Tue, Sep 22, 8:10 PM
Unknown Object (File)
Mon, Sep 21, 3:03 PM
Unknown Object (File)
Sun, Sep 20, 9:14 AM
Unknown Object (File)
Sun, Sep 20, 3:31 AM
Unknown Object (File)
Tue, Sep 15, 2:40 AM
Unknown Object (File)
Mon, Sep 14, 1:21 AM
Unknown Object (File)
Sat, Sep 12, 12:04 PM
Subscribers

Details

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 76476
Build 73359: arc lint + arc unit

Event Timeline

When would you get a short read? Maybe a truncated disk image?

This revision is now accepted and ready to land.Mon, Sep 28, 1:58 PM

Isn't this more of a theoretical issue than actual?
Still, these changes aren't wrong since we don't really support resid values in the loader.

Yes, I think a read that spanned the end of the device, either truncated image or via a corrupt disk address. And, yes, I think this one is more theoretical.

However, I was working a real problem that led me here. I was working with bhyve vm images and hitting hangs in the loader, which I could see via gdb were in the ufs stack. Eventually it turned out to be that ufs had become corrupt, and that led to an infinite loop in the directory parsing. But I really did want to rule out that the reason for the apparent corruption was that a short read was being ignored. And elsewhere we do have short read checks like these.

Anyway, I also posted D59378 as a more direct solution to hardening the stand ufs directory parsing against corruption.