[Top][All Lists]

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

Re: libusb+librump patch

From: Olaf Buddenhagen
Subject: Re: libusb+librump patch
Date: Mon, 26 Oct 2015 02:05:52 +0100
User-agent: Mutt/1.5.23 (2014-03-12)


On Tue, Oct 20, 2015 at 02:22:21AM +0000, Antti Kantee wrote:
> On 19/10/15 10:26, Olaf Buddenhagen wrote:

> >Fault isolation is also a concern -- though not the primary goal of
> >the Hurd architecture.
> 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.

For most microkernel systems, this is actually *the* single major
selling point. For the Hurd, it's not a primary goal -- but still a nice

> >>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?

> 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?...


reply via email to

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