lkml.org 
[lkml]   [2006]   [Feb]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [RFC 4/4] firewire: add mem1394
Date
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 10:13    [W:0.076 / U:0.368 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site