From 3260e18de7d0e2075f6a3581b68a340067281b1a Mon Sep 17 00:00:00 2001 From: "Eduardo' Vela\" Nava (sirdarckcat)" Date: Mon, 20 Nov 2023 10:58:05 +0100 Subject: [PATCH] Update README.md --- pocs/cpus/top-of-stack/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pocs/cpus/top-of-stack/README.md b/pocs/cpus/top-of-stack/README.md index 0752b46e..034bf320 100644 --- a/pocs/cpus/top-of-stack/README.md +++ b/pocs/cpus/top-of-stack/README.md @@ -39,7 +39,7 @@ What is worse is that in the user to kernel case, the RSB/RAS is thought to not ### Architectural Top of the Stack -If the top of the stack is accessed (for example, via a _‘push’_), a speculatively executed _‘ret’_ instruction will actually predict using the value from that location. A _‘clflush’_ can be added for the negative testing (notice that we still see some hits in some of the microarchitectures, which might support the theory of the usage of store-buffers). +The easiest way to see/test the behavior is to fill the RSB/RAS (in case the IBPB instruction does not clear the RAS, as is the case on some AMD microarchitectures) and perform an IBPB (to flush the BTB). If the top of the stack is accessed (for example, via a _‘push’_), a speculatively executed _‘ret’_ instruction will actually predict using the value from that location. A _‘clflush’_ can be added for the negative testing (notice that we still see some hits in some of the microarchitectures, which might support the theory of the usage of store-buffers). Here is an example of a test (based on KTF [^5]):