On Thu, Sep 30, 2021 at 12:23:36PM -0700, Andi Kleen wrote:

quoted

I don't think the current mitigations under discussion here are about
keeping the system working. In fact most encrypted VM configs tend to
stop booting as a preferred way to handle security issues.

Maybe we should avoid the "trusted" term here. We're only really using it
because USB is using it and we're now using a common framework like Greg
requested. But I don't think it's the right way to think about it.

We usually call the drivers "hardened". The requirement for a hardened
driver is that all interactions through MMIO/port/config space IO/MSRs are
sanitized and do not cause memory safety issues or other information leaks.
Other than that there is no requirement on the functionality. In particular
DOS is ok since a malicious hypervisor can decide to not run the guest at
any time anyways.

Someone loading an malicious driver inside the guest would be out of scope.
If an attacker can do that inside the guest you already violated the
security mechanisms and there are likely easier ways to take over the guest
or leak data.

The goal of the device filter mechanism is to prevent loading unhardened
drivers that could be exploited without them being themselves malicious.

If all you want to do is prevent someone from loading a bunch of 
drivers that you have identified as unhardened, why not just use a 
modprobe blacklist?  Am I missing something?

Alan Stern
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization