headers
Andrew Lutomirski | 4 Jan 2013 00:04
Picon
Favicon

Is physical dma going away?

Inception (http://www.breaknenter.org/projects/inception/) is scary.
Are there any plans to make SBP-2 work without physical DMA and to
then disable physical DMA completely?

(Unless, of course, the config option to force phys dma on is set.)

--Andy

------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122712
Permalink | Reply |
headers
Clemens Ladisch | 4 Jan 2013 09:53
Picon
Gravatar

Re: Is physical dma going away?

Andrew Lutomirski wrote:
>Are there any plans to make SBP-2 work without physical DMA

Yes (without any definite time frame).

> and to then disable physical DMA completely?

Not by default; it's too useful an optimization.

But we should think about in what circumstances physical DMA can be
enabled safely. It is ultimately impossible to differentiate between
real storage devices and attack devices (because a full SBP
implementation could be added), but if we assume that the user would not
choose to access the device, and that no automatic indexer tries the
same, and that the attacker has no
login (possibly left open) on the
machine, it might be possible to enable DMA only after some amount
of data has been transferred successfully.

Regards,
Clemens

------------------------------------------------------------------------------
Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
much more. Get web development skills now with LearnDevNow -
350+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122812
Permalink | Reply |
headers
Chris Boot | 4 Jan 2013 10:29
Favicon
Gravatar

Re: Is physical dma going away?

On 04/01/13 08:53, Clemens Ladisch wrote:
> Andrew Lutomirski wrote:
>> Are there any plans to make SBP-2 work without physical DMA
> Yes (without any definite time frame).
>
>> and to then disable physical DMA completely?
> Not by default; it's too useful an optimization.
>
> But we should think about in what circumstances physical DMA can be
> enabled safely. It is ultimately impossible to differentiate between
> real storage devices and attack devices (because a full SBP
> implementation could be added), but if we assume that the user would not
> choose to access the device, and that no automatic indexer tries the
> same, and that the attacker has no
> login (possibly left open) on the
> machine, it might be possible to enable DMA only after some amount
> of data has been transferred successfully.

Doesn't the presence (and use) of an IOMMU such as Intel's VT-d make 
physical DMA over Firewire much safer? Essentially you would only allow 
through the IOMMU those physical addresses that should be accessed by 
the firewire card, so an attacker would be unable to access anything else?

If so, perhaps some pressure should be put on distributions to enable 
IOMMU by default when it is present - I know Debian disables it by 
default, for example.

Cheers,
Chris
(Continue reading)

Permalink | Reply |
headers
Andrew Lutomirski | 4 Jan 2013 15:49
Picon
Favicon

Re: Is physical dma going away?

On Jan 4, 2013 12:53 AM, "Clemens Ladisch" <clemens <at> ladisch.de> wrote:
>
> Andrew Lutomirski wrote:
> >Are there any plans to make SBP-2 work without physical DMA
>
> Yes (without any definite time frame).
>
> > and to then disable physical DMA completely?
>
> Not by default; it's too useful an optimization.

I looked at the spec, and it's rather impenetrable to me.  If
PhysicalUpperBound is set to zero, then physical requests hit the AR DMA
engine, which looks at context programs, and I don't really understand what
happens next.  Can these context programs be used to emulate physical DNA
while restricting the allowable memory ranges to actual mapped DMA buffers?

--Andy

>
> But we should think about in what circumstances physical DMA can be
> enabled safely. It is ultimately impossible to differentiate between
> real storage devices and attack devices (because a full SBP
> implementation could be added), but if we assume that the user would not
> choose to access the device, and that no automatic indexer tries the
> same, and that the attacker has no
> login (possibly left open) on the
> machine, it might be possible to enable DMA only after some amount
> of data has been transferred successfully.
>
(Continue reading)

Permalink | Reply |
headers
Stefan Richter | 4 Jan 2013 20:20
Picon

Re: Is physical dma going away?

On Jan 04 Andrew Lutomirski wrote:
> On Jan 4, 2013 12:53 AM, "Clemens Ladisch" <clemens <at> ladisch.de> wrote:
> >
> > Andrew Lutomirski wrote:
> > >Are there any plans to make SBP-2 work without physical DMA
> >
> > Yes (without any definite time frame).

Anybody is welcome to submit a respective patch, anytime.

(I for one am not going to work on this particular feature myself anytime
soon because there is so much more other 1394 driver work to be done which
is more interesting to me.  Alas it's been a long time ago that I last
wrote more than a trivial one- or two-line patch.  The dayjobs are too
draining these days.)

> > > and to then disable physical DMA completely?
> >
> > Not by default; it's too useful an optimization.
> 
> I looked at the spec, and it's rather impenetrable to me.  If
> PhysicalUpperBound is set to zero, then physical requests hit the AR DMA
> engine, which looks at context programs, and I don't really understand what
> happens next.  Can these context programs be used to emulate physical DNA
> while restricting the allowable memory ranges to actual mapped DMA buffers?

PhysicalUpperBound is optional and is in fact not implemented by the vast
majority of OHCIs.  The practical way to "disable" physical DMA is simply
by leaving the PhysicalRequestFilter bits off.
(Continue reading)

Permalink | Reply |
headers
Andrew Lutomirski | 5 Jan 2013 01:25
Picon
Favicon

Re: Is physical dma going away?

On Fri, Jan 4, 2013 at 11:20 AM, Stefan Richter
<stefanr <at> s5r6.in-berlin.de> wrote:
> On Jan 04 Andrew Lutomirski wrote:
>> On Jan 4, 2013 12:53 AM, "Clemens Ladisch" <clemens <at> ladisch.de> wrote:
>> >
>> > Andrew Lutomirski wrote:
>> > >Are there any plans to make SBP-2 work without physical DMA
>> >
>> > Yes (without any definite time frame).
>
> Anybody is welcome to submit a respective patch, anytime.
>
> (I for one am not going to work on this particular feature myself anytime
> soon because there is so much more other 1394 driver work to be done which
> is more interesting to me.  Alas it's been a long time ago that I last
> wrote more than a trivial one- or two-line patch.  The dayjobs are too
> draining these days.)
>
>> > > and to then disable physical DMA completely?
>> >
>> > Not by default; it's too useful an optimization.
>>
>> I looked at the spec, and it's rather impenetrable to me.  If
>> PhysicalUpperBound is set to zero, then physical requests hit the AR DMA
>> engine, which looks at context programs, and I don't really understand what
>> happens next.  Can these context programs be used to emulate physical DNA
>> while restricting the allowable memory ranges to actual mapped DMA buffers?
>
> PhysicalUpperBound is optional and is in fact not implemented by the vast
> majority of OHCIs.  The practical way to "disable" physical DMA is simply
(Continue reading)

Permalink | Reply |
headers
Stefan Richter | 5 Jan 2013 17:25
Picon

Re: Is physical dma going away?

On Jan 04 Andrew Lutomirski wrote:
> Maybe this whole mess could be abstracted in the core
[...]

As long as a feature or abstraction is used only by a single driver, its
implementation should be placed into this driver rather than the core.
When another user gets added, the implementation can still be moved into
the core or a library.

> How important is it for dma mapping to never fail (in the context of sbp-2)?

Temporary failures are overcome by retries in SCSI core's error handler
thread.

> Sadly, I don't have an sbp-2 device handly.  I'll see if I can dig one
> up next time I'm bored and want to hack on the kernel.

A Linux node can be set up as SBP-2 target too, using the sbp-target
driver in Linux 3.5 and later, or using the Endpoint usermode driver.
(Endpoint requires changes though in order to use the
<linux/firewire-cdev.h> Configuration ROM modification API instead of
libraw1394's respective API which depends on the old raw1394 kernel
interface.)
--

-- 
Stefan Richter
-=====-===-= ---= --=-=
http://arcgraph.de/sr/

------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
(Continue reading)

Permalink | Reply |

Gmane