On Thu, Aug 05, 2021 at 11:44:47AM -0700, Andi Kleen wrote:

On 8/5/2021 11:09 AM, Greg Kroah-Hartman wrote:

quoted

On Thu, Aug 05, 2021 at 10:58:46AM -0700, Andi Kleen wrote:

quoted

On 8/5/2021 10:51 AM, Greg Kroah-Hartman wrote:

quoted

It's controlled by whatever you want to use in userspace.  usbguard has
been handling this logic in userspace for over a decade now just fine.

So how does that work with builtin USB drivers? Do you delay the USB binding
until usbguard starts up?

Yes.

That won't work for confidential guests, e.g. we need a virtio driver for
the console and some other things.

quoted

quoted

quoted

quoted

This doesn't help us handle builtin drivers that initialize before user
space is up.

Then have the default setting for your bus be "unauthorized" like we
allow for some busses today.

We need some early boot drivers, just not all of them. For example in your
scheme we would need to reject all early platform drivers, which would break
booting. Or allow all early platform drivers, but then we exactly get into
the problem that there are far too many of them to properly harden.

Define "harden" please.  Why not just allow all platform drivers, they
should all be trusted.  If not, well, you have bigger problems...

Trusted here means someone audited them and also fuzzed them. That's all a
lot of work and also needs to be maintained forever so we're trying to do
only a minimum set. There are actually quite a few platform drivers, it's
difficult to audit them all.

Note, this model is wrong and backwards and will not work out at all in
the end.

But given that this is coming from a hardware company, it makes sense.
You are coming from the model of "the hardware is trusted, but the code
is untrusted".  That is the exact opposite of what we have been working
with for the past 5+ years now.

Look at all of the work that has happened in just USB drivers over the
recent years thanks to fuzzing efforts.  None of this was done because
we did not trust the kernel code, it was because we had to now not trust
the hardware to actually do the right thing.  So we have had to "harden"
the kernel side to deal with untrusted hardware.

People are now looking at doing the same for PCI devices, but that's a
huge effort that no one has started to take seriously.

Same thing for any other hardware "bug", that is software having to fix
hardware errors as it is the thing that is incorrect, not the software.
Spectre/meltdown is a huge example of that, but there are many more.

The model the kernel has right now for "authorized" devices is that it
is up to some entity to determine if the _device_ is trusted, not if the
_driver_ is trusted.

By virtue of you all saying that you want to use a generic kernel image
from a vendor, you are implying that you have to trust that software as
you have no control over that kernel image.  What you need to validate
is "can I trust this device to be controlled by the kernel".

So work on providing "trusted" hardware/device signals to the kernel
please.  That is the only way this is going to work.

And yes, auditing drivers is wonderful and grand please do that and set
up automated testing for it along with good static analysis and all of
that.  But that is NOT going to provide you with what you want here, as
the most "perfictly audited" body of code will fall apart when
confronted with "hardware" that does not work as documented/planned.

That's the fatal flaw in the formal methods camp, they have to trust the
model of the running system in order to be able to then validate the
software.  But when the model turns out to be wrong (again, spectre is
an example of this), it turns out that the software ends up not working
"correctly".

So go work on providing some sort of authentication of hardware to
attest that it really is what it says it is, in order to allow a kernel
to be able to determine if it should start talking to it or not.

good luck!

greg k-h