On Feb 05, 2006, at 03:43, Andrew Morton wrote:
Johannes Berg <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
