Re: How trustworthy is that I/O device?

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

> 
> On Nov 6, 2013, at 2:24 PM, Warner Losh <[email protected]> wrote:
> 
>> 
>> On Nov 6, 2013, at 2:21 PM, Matt Thomas wrote:
>> 
>>> 
>>> On Nov 4, 2013, at 2:34 PM, Erik Fair <[email protected]> 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