On Sat, Oct 2, 2021 at 7:20 AM Andi Kleen <ak@xxxxxxxxxxxxxxx> wrote: > > > On 10/2/2021 4:14 AM, Greg Kroah-Hartman wrote: > > On Sat, Oct 02, 2021 at 07:04:28AM -0400, Michael S. Tsirkin wrote: > >> On Fri, Oct 01, 2021 at 08:49:28AM -0700, Andi Kleen wrote: > >>>> Do you have a list of specific drivers and kernel options that you > >>>> feel you now "trust"? > >>> For TDX it's currently only virtio net/block/console > >>> > >>> But we expect this list to grow slightly over time, but not at a high rate > >>> (so hopefully <10) > >> Well there are already >10 virtio drivers and I think it's reasonable > >> that all of these will be used with encrypted guests. The list will > >> grow. > > What is keeping "all" drivers from being on this list? > > It would be too much work to harden them all, and it would be pointless > because all these drivers are never legitimately needed in a virtualized > environment which only virtualize a very small number of devices. > > > How exactly are > > you determining what should, and should not, be allowed? > > Everything that has had reasonable effort at hardening can be added. But > if someone proposes to add a driver that should trigger additional > scrutiny in code review. We should also request them to do some fuzzing. > > It's a bit similar to someone trying to add a new syscall interface. > That also triggers much additional scrutiny for good reasons and people > start fuzzing it. > > > > How can > > drivers move on, or off, of it over time? > > Adding something is submitting a patch to the allow list. > > I'm not sure the "off" case would happen, unless the driver is > completely removed, or maybe it has some unfixable security problem. But > that is all rather unlikely. > > > > > > And why not just put all of that into userspace and have it pick and > > choose? That should be the end-goal here, you don't want to encode > > policy like this in the kernel, right? > > How would user space know what drivers have been hardened? This is > really something that the kernel needs to determine. I don't think we > can outsource it to anyone else. How it is outsourcing by moving that same allow list over the kernel / user boundary. It can be maintained by the same engineers and get deployed by something like: dracut --authorize-device-list=confidential-computing-default $kernel-version With that distributions can deploy kernel-specific authorizations and admins can deploy site-specific authorizations. Then the kernel implementation is minimized to authorize just enough drivers by default to let userspace take over the policy. > Also BTW of course user space can still override it, but really the > defaults should be a kernel policy. The default is secure, trust nothing but bootstrap devices. > There's also the additional problem that one of the goals of > confidential guest is to just move existing guest virtual images into > them without much changes. So it's better for such a case if as much as > possible of the policy is in the kernel. But that's more a secondary > consideration, the first point is really the important part. The same image can be used on host and guest in this "do it in userspace" proposal.
