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]
Message-ID: <87tuhj65y1.ffs@tglx>
Date:   Thu, 14 Oct 2021 16:23:34 +0200
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Paolo Bonzini <pbonzini@...hat.com>,
        "Liu, Jing2" <jing2.liu@...el.com>,
        LKML <linux-kernel@...r.kernel.org>
Cc:     "x86@...nel.org" <x86@...nel.org>,
        "Bae, Chang Seok" <chang.seok.bae@...el.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Arjan van de Ven <arjan@...ux.intel.com>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "Nakajima, Jun" <jun.nakajima@...el.com>,
        Jing Liu <jing2.liu@...ux.intel.com>,
        "seanjc@...gle.com" <seanjc@...gle.com>,
        Andrew Cooper <andrew.cooper3@...rix.com>
Subject: Re: [patch 13/31] x86/fpu: Move KVMs FPU swapping to FPU core

On Thu, Oct 14 2021 at 14:26, Paolo Bonzini wrote:
> On 14/10/21 14:23, Thomas Gleixner wrote:
>>> In principle I don't like it very much; it would be nicer to say "you
>>> enable it for QEMU itself via arch_prctl(ARCH_SET_STATE_ENABLE), and for
>>> the guests via ioctl(KVM_SET_CPUID2)".  But I can see why you want to
>>> keep things simple, so it's not a strong objection at all.
>> Errm.
>> 
>>     qemu()
>>       read_config()
>>       if (dynamic_features_passthrough())
>> 	request_permission(feature)             <- prctl(ARCH_SET_STATE_ENABLE)
>> 
>>       create_vcpu_threads()
>>         ....
>> 
>>         vcpu_thread()
>> 	 kvm_ioctl(ENABLE_DYN_FEATURE, feature) <- KVM ioctl
>> 
>> That's what I lined out, right?
>> 
>
> I meant prctl for QEMU-in-user-mode vs. ioctl QEMU-in-guest-mode (i.e. 
> no prctl if only the guest uses it).  But anyway it's just abstract 
> "beauty", let's stick to simple. :)

It's not about simple. It's about correctness in the first place.

The prctl() is process wide and grants permission. If that permission is
not granted, e.g. by a seccomp rule, then the vCPU threads cannot use it
either. We are _not_ making exceptions for KVM just because it's KVM.

Trying to pretend that the usermode thread does not need it is just
illusion. The kernel representation of that very usermode vCPU thread must
have a large fpstate. It still can have XFD set, but that's a detail.

So what you are trying to sell me has nothing to do with beauty at all
except when your definition of beauty originates from a tunnel of horrors.

Thanks,

        tglx

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ