Messages in this thread | | | From | Kyle Moffett <> | Subject | Re: [RFC 4/4] firewire: add mem1394 | Date | Sun, 5 Feb 2006 04:09:44 -0500 |
| |
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/
| |