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] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 25 Aug 2022 16:19:56 +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 Wed, Aug 24, 2022, Chang S. Bae wrote:
> On 8/24/2022 2:42 PM, Sean Christopherson wrote:
> Maybe this is a policy decision. I don't think that
> ARCH_REQ_XCOMP_GUEST_PERM goes away with this. Userspace may still use the
> arch_prctl() set. But then it makes more sense and consistent to use
> ARCH_GET_XCOMP_SUPP in first place, instead of KVM_X86_XCOMP_GUEST_SUPP, no?

KVM_X86_XCOMP_GUEST_SUPP is needed so that userspace understands what _KVM_
supports.

> > If QEMU wants to assert that it didn't misconfigure itself, it can assert on the
> > config in any number of ways, e.g. assert that ARCH_GET_XCOMP_GUEST_PERM is a
> > subset of KVM_X86_XCOMP_GUEST_SUPP at the end of kvm_request_xsave_components().
> 
> Yes, but I guess the new attribute can make it simple.

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.