[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) |
Hi,
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
bonus...
> >>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?...
-antrik-
- libusb+librump patch, Bruno Félix Rezende Ribeiro, 2015/10/08
- Re: libusb+librump patch, Robert Millan, 2015/10/08
- Re: libusb+librump patch, Antti Kantee, 2015/10/08
- Re: libusb+librump patch, Bruno Félix Rezende Ribeiro, 2015/10/14
- Re: libusb+librump patch, Antti Kantee, 2015/10/14
- Re: libusb+librump patch, Olaf Buddenhagen, 2015/10/16
- Re: libusb+librump patch, Antti Kantee, 2015/10/17
- Re: libusb+librump patch, Olaf Buddenhagen, 2015/10/19
- Re: libusb+librump patch, Antti Kantee, 2015/10/19
- Re: libusb+librump patch,
Olaf Buddenhagen <=
- Re: libusb+librump patch, Antti Kantee, 2015/10/26
Re: libusb+librump patch, Bruno Félix Rezende Ribeiro, 2015/10/14