linux-kernel - Re: [RFC PATCH 1/2] KVM: x86: Add a new system attribute for dynamic XSTATE component

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <YwfvgsNTz33dlwKP@google.com>
Date:   Thu, 25 Aug 2022 21:54:10 +0000
From:   Sean Christopherson <seanjc@...gle.com>
To:     "Chang S. Bae" <chang.seok.bae@...el.com>
Cc:     kvm@...r.kernel.org, pbonzini@...hat.com,
        linux-kernel@...r.kernel.org, yang.zhong@...el.com
Subject: Re: [RFC PATCH 1/2] KVM: x86: Add a new system attribute for dynamic
 XSTATE component

On Thu, Aug 25, 2022, Chang S. Bae wrote:
> On 8/25/2022 9:19 AM, Sean Christopherson wrote:
> > 
> > Adding new uAPI and new exports to eliminate one line of userspace code is not a
> > good tradeoff.  Am I missing something?  This really seems like solution looking
> > for a problem.
> 
> Well, then that's your call.
> 
> Yeah, that simplification is really minor. With this, I would rather think
> KVM wants enforcement before relaying the request to the host. That
> enforcement is unthinkable without supported_xcr0.

My point is that KVM needs supported_xcr0 (or similar behavior) regardless of
whether or not the kernel further restricts feature usage.

> But it looks like userspace is somehow trusted here for KVM.