linux-kernel - Re: Can we break RDPID/RDTSCP ABI ASAP and see if it's okay?

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:   Mon, 13 Nov 2017 10:06:47 -0800
From:   Andy Lutomirski <luto@...nel.org>
To:     Paolo Bonzini <pbonzini@...hat.com>
Cc:     Andy Lutomirski <luto@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Peter Zijlstra <peterz@...radead.org>, X86 ML <x86@...nel.org>,
        Borislav Petkov <bp@...en8.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        linux-abi@...r.kernel.org
Subject: Re: Can we break RDPID/RDTSCP ABI ASAP and see if it's okay?

On Mon, Nov 13, 2017 at 5:54 AM, Paolo Bonzini <pbonzini@...hat.com> wrote:
> On 28/10/2017 21:38, Andy Lutomirski wrote:
>> We currently do this on boot:
>>
>> write_rdtscp_aux((node << 12) | cpu);
>>
>> This *sucks*.  It means that, to very quickly obtain the CPU number
>> using RDPID, an ALU op is needed.  It also doesn't bloody work on
>> systems with more than 4096 CPUs.
>>
>> IMO it should be ((u64)node << 32) | cpu.
>
> MSR_TSC_AUX is still documented as reserving bits 32-63 in the October
> 2017 SDM, and indeed on a Haswell you get a #GP if you write a nonzero
> value to it.
>
> Has Intel quietly "unreserved" them on machines that have RDPID?
>

Dunno.  I don't have such a machine.

But this is a genuine problem on machines with >4096 CPUs.