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: <ZPDTrfppUdG7uxPX@google.com>
Date:   Thu, 31 Aug 2023 10:53:49 -0700
From:   Sean Christopherson <seanjc@...gle.com>
To:     Christian Lamparter <chunkeey@...il.com>
Cc:     vbox-dev@...tualbox.org, open list <linux-kernel@...r.kernel.org>,
        x86@...nel.org
Subject: Re: Missing L3 linesize on AMD Ryzen 7940HS chip causes crash in amd_cpuid4.

On Thu, Aug 31, 2023, Christian Lamparter wrote:
> This is because L3 cache's line_size is "0" (this is coming from the 80000006 edx
> value of 0x00009000).
> 
> This can't be right... or? Well, digging around. I found the following explanation
> in AMD's community forum:
> <https://community.amd.com/t5/processors/ryzen-7-3700x-cpuid-function-id-0x80000006-returns-wrong-number/td-p/376937>
> So there's an issue with "wonky L3 values" that happens even earlier with the
> AMD 3700X. In this forum post, the author talks about the
> "L3 cache associativity (bits 12-15) is 0x9".
> 
> And the same is happening with both AMD 7950X and 7940HS.
> The kicker is: this value of "9" means:
> "Please look at CPUID.8000_001D".

Ugh, that's just nasty.

> Which I think boils down to implementing X86_FEATURE_TOPOEXT
> for virtualbox to get over this issue?
> 
> Now, is there something I'm missing? I don't know if qemu is be affected.

AFAICT, QEMU should be fine, so long as the underlying hardware is sane.  Unless
I'm misreading things, QEMU doesn't generate the redirect to 0x8000001D when
synthesizing cache information, and when passing through host cache information,
both 0x80000006 and 0x8000001D are passed through verbatim.

> Or if there's another way around it.

At a glance, having virtualbox zero out EDX if its trying to redirect should also
work.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ