Re: [PATCH] x86/CPU/AMD: Clear RDRAND CPUID bit on AMD family 15h/16h

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 17/08/2019 09:44, Borislav Petkov wrote:
> On Thu, Aug 15, 2019 at 10:25:24PM +0100, Andrew Cooper wrote:
>> I'm afraid that a number of hypervisors do write-discard, given the
>> propensity of OSes (certainly traditionally) to go poking at bits like
>> this without wrmsr_safe().
>>
>> You either need to read the MSR back and observe that the bit has really
>> changed, or in this case as Thomas suggests, look at CPUID again (which
>> will likely be the faster option for the non-virtualised case).
> One thing I didn't think of when we talked about this: this happens only
> after you resume the hypervisor.

:) It hadn't escaped my notice, hence the intervention on this thread.

> And the words "resume the hypervisor" already means an improbable use case.

Qubes and OpenXT are two laptop+hypervisor oriented distros where
suspend/resume is a big deal, and these will have to follow AMD's
recommendation here.

However, for servers which don't do S3/S4, we can reason about safely
leaving RDRAND enabled, irrespective of guest configuration.

~Andrew



[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux