LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: Bernhard Kaindl <bk@suse.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>, John Stoffel <john@stoffel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Maxim Levitsky <maximlevitsky@gmail.com>,
	Ingo Molnar <mingo@elte.hu>,
	linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: remote DMA via FireWire (was Re: [git pull] x86 arch updates for v2.6.25)
Date: Fri, 08 Feb 2008 20:38:04 +0100	[thread overview]
Message-ID: <47ACAF9C.6030003@s5r6.in-berlin.de> (raw)
In-Reply-To: <alpine.LNX.1.00.0802081900360.321@jbgna.fhfr.qr>

Bernhard Kaindl wrote:
> Regarding security:
> 
> On the software side: The new fw-ohci driver seems to allow physical DMA only
> to devices which pretend to be FireWire disks (it is the specified way to
> transfer the data)
...

To be precise, firewire-sbp2 tells firewire-ohci to open up the physical
response unit (which implements the remote DMA feature) for the target
node from when it tries the SBP-2 login until when it completes the
SBP-2 logout or the target is plugged out.  Let's call it filtered
physical DMA.

A mode which doesn't require the physical response unit could be
implemented in firewire-sbp2, but this would come with a considerable
overhead regarding code, runtime CPU usage due to huge interrupt
handling load, and additional runtime memory footprint.

The older sbp2 driver relies on unfiltered physical DMA, hence is less
secure.  There can be a mode selected at compile time to run without
physical DMA, but that's buggy and implemented in a way which is not
portable.

The only reason why we don't have an SBP-2 initiator which works without
remote DMA is that nobody is bothered enough to either debug that mode
in the old driver or implement it in the new driver.  Besides, we could
rather trivially add filtered physical DMA to the old
sbp2/ieee1394/ohci1394 stack but nobody took the time to do this yet either.

> With FireWire enabled by the BIOS, a hacker could (in theory) load his
> own operating system into the system RAM and boot it
...

x86 BIOSes don't initialize OHCI-1394 controllers up to the point that
its physical response unit were working remote nodes were granted access
to it.

Apple's OpenFirmware implements SBP-2 initiator but I don't know if it
uses the physical response unit.  But this point is moot --- you can
boot from SBP-2 targets.
-- 
Stefan Richter
-=====-==--- --=- -=---
http://arcgraph.de/sr/

  reply	other threads:[~2008-02-08 19:38 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-30  1:15 [git pull] x86 arch updates for v2.6.25 Ingo Molnar
2008-01-31  0:33 ` x86 arch updates also broke s390 Adrian Bunk
2008-01-31  9:34   ` Martin Schwidefsky
2008-01-31 10:24     ` Ingo Molnar
2008-01-31 12:37       ` Nick Piggin
2008-02-01  9:48     ` Ingo Molnar
2008-02-01  9:52       ` Ingo Molnar
2008-02-01  9:54       ` Martin Schwidefsky
2008-02-01 10:02         ` Ingo Molnar
2008-01-31 15:57 ` [git pull] x86 arch updates for v2.6.25 Adrian Bunk
2008-01-31 16:00   ` Ingo Molnar
2008-01-31 16:04     ` Ingo Molnar
2008-01-31 16:12     ` Adrian Bunk
2008-01-31 16:15       ` Ingo Molnar
2008-01-31 16:21         ` WANG Cong
2008-01-31 16:24         ` Adrian Bunk
2008-01-31 16:46           ` Ingo Molnar
2008-01-31 16:52             ` Jeremy Fitzhardinge
2008-01-31 16:29         ` sparc compile error caused by x86 arch updates Adrian Bunk
2008-01-31 16:50           ` Jeremy Fitzhardinge
2008-01-31 17:43             ` Ingo Molnar
2008-01-31 17:55               ` Jeremy Fitzhardinge
2008-01-31 18:21               ` Adrian Bunk
2008-01-31 18:38                 ` Ingo Molnar
2008-02-05  2:36 ` [git pull] x86 arch updates for v2.6.25 Maxim Levitsky
2008-02-05  3:27   ` Linus Torvalds
2008-02-05  4:11     ` Phil Oester
2008-02-05  4:54       ` Andrew Morton
2008-02-06 12:08         ` Jan Kiszka
2008-02-07 20:00           ` Daniel Phillips
2008-02-08  4:48       ` Christoph Hellwig
2008-02-08  9:51         ` Jan Kiszka
2008-02-05 17:45     ` John Stoffel
2008-02-05 17:52       ` H. Peter Anvin
2008-02-08 18:24         ` Bernhard Kaindl
2008-02-08 19:38           ` Stefan Richter [this message]
2008-02-07 19:20     ` Daniel Phillips
2008-02-08 17:00     ` Andi Kleen
2008-02-08 17:48       ` Jan Kiszka
2008-02-08 18:57         ` Andi Kleen
2008-02-08 21:28           ` [RFC][PATCH] KGDB: remove kgdb-own fault handling (was: Re: [git pull] x86 arch updates for v2.6.25) Jan Kiszka
2008-02-08 21:58             ` Linus Torvalds
2008-02-08 22:16               ` [RFC][PATCH] KGDB: remove kgdb-own fault handling Jason Wessel
2008-02-09 14:11 ` [git pull] x86 arch updates for v2.6.25 Amit Shah
2008-02-10 12:30   ` Jiri Kosina
2008-02-12  7:16     ` Amit Shah
2008-02-13  8:56       ` Ingo Molnar
2008-02-13 10:19         ` Amit Shah

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47ACAF9C.6030003@s5r6.in-berlin.de \
    --to=stefanr@s5r6.in-berlin.de \
    --cc=akpm@linux-foundation.org \
    --cc=bk@suse.de \
    --cc=hpa@zytor.com \
    --cc=john@stoffel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maximlevitsky@gmail.com \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --subject='remote DMA via FireWire (was Re: [git pull] x86 arch updates for v2.6.25)' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).