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: <3dab0fd6-be64-2c72-1ee9-ecd040fd43b5@redhat.com>
Date:   Fri, 3 Aug 2018 22:17:02 +0200
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Peter Shier <pshier@...gle.com>, tglx@...utronix.de
Cc:     mingo@...hat.com, hpa@...or.com, x86@...nel.org, bp@...e.de,
        konrad.wilk@...cle.com, dwmw@...zon.co.uk,
        Jim Mattson <jmattson@...gle.com>,
        linux-kernel@...r.kernel.org, Peter Feiner <pfeiner@...gle.com>,
        kvm@...r.kernel.org
Subject: Re: [PATCH] proc: added ept_ad flag to /proc/cpuinfo

On 02/08/2018 21:33, Peter Shier wrote:
> 
>> > The Intel Haswell architecture has an EPT feature whereby the access &
>> > dirty bits in EPT entries are updated without taking a guest exit.
>>
>> Why would this be Haswell specific?
>>
>> Aside of that I don't see what this has to do with exits. From the SDM:
>>
>>   " * If bit 21 is read as 1, accessed and dirty flags for EPT are
>>       supported (see Section 28.2.4)"
>>
>> And nothing in 28.2.4 says anything about exits. It's all about whether the
>> feature is supported or not. If it is supported it can be enabled in EPTP.

Right, if it's not supported KVM instead has to use the R/W/X permission
bits to emulate accessed and dirty bits, taking an exit on every update.

But then it seems to me that you're more interested in the KVM behavior
than the processor behavior, and then the information you need is
already in the /sys/modules/kvm_intel/parameters directory.  (Most
processor features have a parameter so that it's possible to test code
paths for old processors).  I don't particularly see a need to add them
in /proc/cpuinfo.

Paolo

> Thank you Thomas. I missed what I think is your fundamental point
> regarding duplication created by this patch between CPU feature bits
> and KVM's consumption of the IA32_VMX_EPT_VPID_CAP MSR.
> 
> Should all the features in this MSR be exposed via CPU feature bits
> and should KVM consume only from there rather than reading the MSR
> directly? There are 16 feature bits in the MSR per SDM Vol 3d section
> A.10.
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ