Re: How trustworthy is that I/O device?

[Warner Losh <imp%bsdimp.com@localhost>]

On Nov 6, 2013, at 2:32 PM, Matt Thomas wrote:

> 
> On Nov 6, 2013, at 2:24 PM, Warner Losh <imp%bsdimp.com@localhost> wrote:
> 
>> 
>> On Nov 6, 2013, at 2:21 PM, Matt Thomas wrote:
>> 
>>> 
>>> On Nov 4, 2013, at 2:34 PM, Erik Fair <fair%netbsd.org@localhost> wrote:
>>> 
>>>> All OSes have a problem with USB and potentially all other hot-plug I/O 
>>>> busses: can you trust the device that was just plugged into the bus? How 
>>>> much I/O do you permit to it before explicit authorization of some kind?
>>> 
>>> I've always wondered why we "trust" file systems and panic they aren't
>>> what we expect.  We don't do that for networking.  If seems if we encounter
>>> an inconsistency, we mark the f/s as read-only and either return an error
>>> or complete the action if possible.
>> 
>> Panic now to prevent crazy later. If the structures are inconsistent, then 
>> relying on underlying assumptions in the code is so unsafe we simply can't 
>> do it at all.  How do we know that going to read-only doesn't create some 
>> kind of excess data disclosure path?
> 
> What I am saying is that you shouldn't trust it.  We shouldn't have underlying
> assumptions in the code.  We don't in the networking code.  Treat it as if 
> it's
> probably trying to cause a denial of service.  I'm saying don't panic, either
> forcibly unmount or treat it as uncacheable and read-only.

I agree we shouldn't have these assumptions in the code, but when you are 
freeing a free inode, how much access to the data do you really want to give? 
You might find certain conditions where you want EIO for all future I/os, 
rather than simple read-only.

Warner