lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 21 Sep 2020 18:48:38 -0700 From: Sean Christopherson <sean.j.christopherson@...el.com> To: Vipin Sharma <vipinsh@...gle.com> Cc: thomas.lendacky@....com, pbonzini@...hat.com, tj@...nel.org, lizefan@...wei.com, joro@...tes.org, corbet@....net, brijesh.singh@....com, jon.grimm@....com, eric.vantassell@....com, gingell@...gle.com, rientjes@...gle.com, kvm@...r.kernel.org, x86@...nel.org, cgroups@...r.kernel.org, linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: [RFC Patch 0/2] KVM: SVM: Cgroup support for SVM SEV ASIDs On Mon, Sep 21, 2020 at 05:40:22PM -0700, Vipin Sharma wrote: > Hello, > > This patch series adds a new SEV controller for tracking and limiting > the usage of SEV ASIDs on the AMD SVM platform. > > SEV ASIDs are used in creating encrypted VM and lightweight sandboxes > but this resource is in very limited quantity on a host. > > This limited quantity creates issues like SEV ASID starvation and > unoptimized scheduling in the cloud infrastructure. > > SEV controller provides SEV ASID tracking and resource control > mechanisms. This should be genericized to not be SEV specific. TDX has a similar scarcity issue in the form of key IDs, which IIUC are analogous to SEV ASIDs (gave myself a quick crash course on SEV ASIDs). Functionally, I doubt it would change anything, I think it'd just be a bunch of renaming. The hardest part would probably be figuring out a name :-). Another idea would be to go even more generic and implement a KVM cgroup that accounts the number of VMs of a particular type, e.g. legacy, SEV, SEV-ES?, and TDX. That has potential future problems though as it falls apart if hardware every supports 1:MANY VMs:KEYS, or if there is a need to account keys outside of KVM, e.g. if MKTME for non-KVM cases ever sees the light of day.
Powered by blists - more mailing lists