On Thu, Sep 30, 2021 at 12:23:36PM -0700, Andi Kleen wrote: > > > 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
