[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libusb+librump patch

From: Antti Kantee
Subject: Re: libusb+librump patch
Date: Mon, 26 Oct 2015 12:59:06 +0000

On 26/10/15 01:05, Olaf Buddenhagen wrote:
What exactly are you trying to isolate faults from?  If the bottom or
top layer of the USB stack fails, applications will still fail.  Ok,
if the top layer has no PCI access, then maybe it can't misprogram the
DMA controller. But that would be a malicious attack, as the chances
of the top layer accidentally misprogramming DMA are astronomical.
And then you're better off trusting an IOMMU.  So I'm not sure I'd put
indirection along the normal path for that case.

No, it's not really about that -- I agree that accidental misprogramming
of unrelated hardware is a fairly unlikely scenario.

However, as we are working with an unsafe programming language here, all
kinds of basic programming bugs in *any* component can bring down the
entire stack. (And ofter open security exploits too.) Address space
(process) boundries tend to help a lot with isolating such problems.

Sure, but my assumption was that the USB stack will already be isolated into its own server, and chopping the existing, working USB stack up will only isolate bits of the USB stack from other bits in the USB stack. So if you're trying to protect USB from itself, I can see the value, otherwise not so much.

For the USB protocol splitting, you could run one rump kernel
instance so that it exports ugen, and another one which uses ugenhc
and provides the high-level drivers.

I suppose that's what you mentioned in an earlier discussion,
regarding use of libusb?...

No, libusb would run on top of the /dev/ugen provided by a rump
kernel. That different from running two rump kernel instances on top
of each other.

Yeah, but you mentioned at some point adding support for the
higher-level parts of the stack to use libusb as backend, so they could
run on top of another instance providing the lower-level functionality
via ugen? Or was that a misunderstanding?

No, you weren't misunderstanding, but it's a separate scenario.

So it's:
user -> syscall (e.g. read() on umass) -> all of USB
user -> something built on top of libusb -> libusb -> syscall -> ugen -> lower level USB

Well, for one, the ugen interface loses information over what is
available for the USB stack running on top of a "native" host
controller, so some of the bits in the ugenhc implementation are
creative protocol-handling-by-heuristics.

Ouch. Is that a problem with the specific ugen protocol, or a
fundamental limitation of any generic HC driver interface?...

It's been years since I've looked the USB standard, but as far as I recall, they're pretty much specified in the standard.

Let's continue this discussion when there's some nascent implementation to evaluate.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]