Incorrect pointer checks within the the FwBlockServiceSmm driver can allow arbitrary RAM modifications During review of the FwBlockServiceSmm driver, certain instances of SpiAccessLib could be tricked into writing 0xff to arbitrary system and SMRAM addresses. Fixed in: INTEL Purley-R: 05.21.51.0048 Whitley: 05.42.23.0066 Cedar Island: 05.42.11.0021 Eagle Stream: 05.44.25.0052 Greenlow/Greenlow-R(skylake/kabylake): Trunk Mehlow/Mehlow-R (CoffeeLake-S): Trunk Tatlow (RKL-S): Trunk Denverton: 05.10.12.0042 Snow Ridge: Trunk Graneville DE: 05.05.15.0038 Grangeville DE NS: 05.27.26.0023 Bakerville: 05.21.51.0026 Idaville: 05.44.27.0030 Whiskey Lake: Trunk Comet Lake-S: Trunk Tiger Lake H/UP3: 05.43.12.0052 Alder Lake: 05.44.23.0047 Gemini Lake: Not Affected Apollo Lake: Not Affected Elkhart Lake: 05.44.30.0018 AMD ROME: trunk MILAN: 05.36.10.0017 GENOA: 05.52.25.0006 Snowy Owl: Trunk R1000: 05.32.50.0018 R2000: 05.44.30.0005 V2000: Trunk V3000: 05.44.30.0007 Ryzen 5000: 05.44.30.0004 Embedded ROME: Trunk Embedded MILAN: Trunk Hygon Hygon #1/#2: 05.36.26.0016 Hygon #3: 05.44.26.0007 https://www.insyde.com/security-pledge/SA-2022060

A timing and power-based side channel attack leveraging the x86 PREFETCH instructions on some AMD CPUs could potentially result in leaked kernel address space information.

AMD processors may speculatively re-order load instructions which can result in stale data being observed when multiple processors are operating on shared memory, resulting in potential data leakage.

I've been beating my head against a wall for a while on this. I'm not a security researcher, or even currently employed in the industry so my ability to analyze the problem I've seemingly discovered here is somewhat limited.

I have a laptop with an AMD Ryzen 5700U. I've been fooling around with spinlocks for a while and for various reasons. Back in late March I basically finished a R/W ticket spinlock that I instrumented for testing purposes. A short test program was written and I found I was getting deadlocks and other odd symptoms. I was unsure of the implementation of the algorithm and so I looked and looked at the code until my eyes started bleeding. The errors were occurring within a few thousand iterations with moderate parallelism.

I eventually wrote several alternate implementations of naive spinlocks, ticket spinlocks, and MCS spinlocks. Many of them were problematic. I eventually developed a much simplified test program implementing a very basic ticket spinlock that can be made to fail with a trivial code change that should not affect the operation of the algorithm.

The code is included as an attachment; it is relatively short at ~300 LOC, and most of those lines are boilerplate or initialization code. The business end is the wrthread() function which is the vector passed to pthreadcreate(), In a loop, the following code is found:

nrspin = t1lockacquire(&obj.lock); #if defined BROKEN temp = ++obj.value; #else ++obj.value; #endif t1lockrelease(&obj.lock);

If "BROKEN" is defined, you can see that an additional cache-line write is made with the assignment to 'temp'. When this code path is enabled, the underlying cmpxchg operation in t1lockacquire() occasionally succeeds when it shouldn't, with a probability on the order of 1:510^6 when the CPU frequency is allowed to climb to 4.3GHz. or thereabouts. I should, but have not yet investigated whether using an attached 4K, 60Hz monitor notably affects this problem.

The test program is essentially a bank-account simulator that adds $.01 to 'obj.value' each iteration for N threads. If the cmpxchg operation in t1lockacquire() functions correctly, the final "balance" in obj.value will be the number of threads multiplied by the number of iterations each thread performs. When the "-DBROKEN" codepath is enabled, the final result may be less than expected, indicating data loss from colliding threads. Very occasionally, a deadlock of all threads is observed.

As the probability of this error occurring is relatively low in a test program that really hammers on a single shared resource, I would expect this bug to manifest relatively rarely under typical usage patterns for code that is found to be vulnerable. However, different test programs, such as with the previously mentioned R/W ticket lock show much higher error-rates. In that case, the lock structure is five fields in a 32 or 64-bit word. One bit is used for mutual-exclusion between threads and the other fields track queue depth and/or the number of instantaneous active read-only threads. It appears that the act of using a cmpxchg operation followed by non-atomic field updates and a release operation on a single machine word vastly increases the probability of an error occurring in comparison to the included test code.

I have not yet found the underlying microarchitectural features responsible for the manifestiation of this apparent CPU bug, which implies that individual spinlock algorithms must be tested in-situ to identify code arrangements that trigger the bug. It is my impression thus far that most spinlock implementations do not do this testing, which suggests that the number of spinlocks in the wild that are vulnerable to this bug is currently unknown. This bug might be exploitable to cause scheduler malfunctions, database corruption, etc. in a deterministic fashion, although i have yet to generate an exploit to this end -- that is beyond my expertise at this stage.

Currently, I lack access to a lab where this can be tested on other CPUs, Intel or otherwise to determine the scope of affected processors. (I have, however, detected the problem on a Core 2 Duo Macbook Pro from the Jurassic period, which is interesting.)

The bug has not been verified yet. I have been dealing with HP as the laptop is under warranty, but in approximately two months they have been unable to find a technician able to understand the source code or who is able to interpret the results. It is still possible I have made some sort of stupid error, but at this point I am reasonably confident I am using atomic operations correctly as per the x86-64 architecture specification documents.

I've posted this here to acquire feedback, and I would greatly appreciate advice on how to better characterize what is going on here, etc. Calling the test program with four threads and 10^7 for the number of loop iterations will usually trigger the bug.

On Mon, Sep 25, 2023 at 06:10:05PM +0100, Andrew Cooper wrote: On 25/09/2023 5:36 pm, Solar Designer wrote: While I am at it, here's the corresponding mitigation in Linux kernel:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=77245f1c3c6495521f6a3af082696ee2f8ce3921 Not really.  That patch entirely misunderstood the vulnerability.  I went through several rounds of getting AMD to better-understand their bug.

Linux's fix was rewritten in https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f58d6fbcb7c848b7f2469be339bc571f2e9d245b and this implements the same logic as I implemented in Xen. Oh wow. Thank you for correcting me (and correcting AMD first?) It's worth noting that because AMD did not allocate a $FOONO CPUID bit, there's no ability for a VM to figure out that it might move to vulnerable hardware and therefore should engage the workaround.  The best a VM can do is best-effort based on whether it looks like it's booting on a Zen1 system. Maybe directly probing for the bug is an option? Perhaps can be done within one thread (where the bug doesn't have security impact, but is detectable anyway, no)? Also the cross-thread nature is also poorly reported in public. Right, I couldn't find it mentioned anywhere other than your advisory.

Do you know if only the quotient leaks, or also the remainder? In the below, I assume the remainder leaks as well.

I'm concerned it could affect some cryptographic code, in particular (but in a very minor way) typical implementations of Argon2. There's a 3-year-pending pull request to the upstream/reference Argon2 implementation that I think would avoid the issue there (by optimizing out the divides):

https://github.com/P-H-C/phc-winner-argon2/pull/306

but there are many other implementations and I guess (almost?) all use the programming language's modulo division operation as-is. Luckily, the severity is minor - this would only affect the cache-timing unsafe flavors, providing an extra (more direct and maybe more reliable?) side-channel, and this only matters when the attacker has a copy of or has guessed the salts (the same as for other cache-timing unsafe password hashes/KDFs). So in terms of threat models and attack vectors, no change at all, but real-world (in)feasibility of otherwise-similar attacks can vary. No big deal, just something to improve where we can.

For others reading just the list postings and for archival, this newer Linux kernel commit is: author Borislav Petkov (AMD) <bp () alien8 de> 2023-08-11 23:38:24 +0200 committer Borislav Petkov (AMD) <bp () alien8 de> 2023-08-14 11:02:50 +0200

x86/CPU/AMD: Fix the DIV(0) initial fix attempt

Initially, it was thought that doing an innocuous division in the #DE handler would take care to prevent any leaking of old data from the divider but by the time the fault is raised, the speculation has already advanced too far and such data could already have been used by younger operations.

Therefore, do the innocuous division on every exit to userspace so that userspace doesn't see any potentially old data from integer divisions in kernel space.

Do the same before VMRUN too, to protect host data from leaking into the guest too.

Fixes: 77245f1c3c64 ("x86/CPU/AMD: Do not leak quotient data after a division by 0") Signed-off-by: Borislav Petkov (AMD) <bp () alien8 de> Cc: <stable () kernel org> Link: https://lore.kernel.org/r/20230811213824.10025-1-bp () alien8 de Alexander