linux-kernel - Re: [PATCH] proc: added ept

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:   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.
>