Re: [RFC 4/4] firewire: add mem1394

[Kyle Moffett <mrmacman_g4@mac.com>]

On Feb 05, 2006, at 03:43, Andrew Morton wrote:
> Johannes Berg <johannes@sipsolutions.net> wrote:
> > +config IEEE1394_MEMDEV
> > +	tristate "IEEE1394 memory device support"
> > +	depends on IEEE1394 && EXPERIMENTAL
> > +	help
> > +	  Say Y here if you want support for the ieee1394 memory device.
> > +	  This is useful for debugging systems attached via firewire
> > +	  since it usually allows you to read from and write to their  
> > memory,
> > +	  depending on the controller and machine setup.
>
> 1394 is evil.  Does this mean that if a machine is completely dead- 
> and-crashed, we can still suck all its memory out over 1394 with no  
> cooperation from the dead machine's kernel?  If not, what  
> limitations are there?

I think you snipped too much of the description.  This was after the  
part you quoted:

> It differs from raw access (which allows the same usage) in that it  
> provides devices nodes (usually called /dev/fwmem-<guid>) that can  
> be read and written with any tool, as opposed to specialised tools  
> required for raw1394.

This seems to indicate that this is a _client_ for a IEEE1394 memory  
device, as opposed to a server.  Perhaps the description should be  
clarified, but I don't see any security issues (the kernel does not  
expose its own memory, it accesses the memory that another device is  
exposing).

Cheers,
Kyle Moffett

--
There is no way to make Linux robust with unreliable memory  
subsystems, sorry.  It would be like trying to make a human more  
robust with an unreliable O2 supply. Memory just has to work.
  -- Andi Kleen


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/