![]() | ||||||||||
Messages in this thread |
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/ | |||||||||
| Last update: 2006-02-05 09:13 [from the cache] ©2003-2008 | ||||||||||