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]
Date:   Wed, 26 Jan 2022 01:23:55 +0000
From:   "Tian, Kevin" <kevin.tian@...el.com>
To:     Paolo Bonzini <pbonzini@...hat.com>,
        "Christopherson,, Sean" <seanjc@...gle.com>,
        Like Xu <like.xu.linux@...il.com>
CC:     "Liu, Jing2" <jing2.liu@...el.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Jim Mattson <jmattson@...gle.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        Joerg Roedel <joro@...tes.org>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Zhong, Yang" <yang.zhong@...el.com>
Subject: RE: [PATCH] KVM: x86/cpuid: Exclude unpermitted xfeatures for
 vcpu->arch.guest_supported_xcr0

> From: Paolo Bonzini <pbonzini@...hat.com>
> Sent: Tuesday, January 25, 2022 4:28 PM
> 
> On 1/25/22 02:54, Tian, Kevin wrote:
> >> The extra complication is that
> arch_prctl(ARCH_REQ_XCOMP_GUEST_PERM)
> >> changes what host userspace can/can't do.  It would be easier if we
> >> could just say that KVM_GET_SUPPORTED_CPUID returns "the most" that
> >> userspace can do, but we already have the contract that userspace can
> >> take KVM_GET_SUPPORTED_CPUID and pass it straight to
> KVM_SET_CPUID2.
> >>
> >> Therefore,  KVM_GET_SUPPORTED_CPUID must limit its returned values
> to
> >> what has already been enabled.
> >>
> >> While reviewing the QEMU part of AMX support (this morning), I also
> >> noticed that there is no equivalent for guest permissions of
> >> ARCH_GET_XCOMP_SUPP.  This needs to know KVM's supported_xcr0, so
> it's
> >> probably best realized as a new KVM_CHECK_EXTENSION rather than as
> an
> >> arch_prctl.
> >>
> > Would that lead to a weird situation where although KVM says no support
> > of guest permissions while the user can still request them via prctl()?
> 
> This is already the case for the current implementation of
> KVM_GET_SUPPORTED_CPUID.
> 

fair enough.

Powered by blists - more mailing lists