add how to recognize uop$

pocs/cpus/reptar/minimized/README.md

@@ -11,5 +11,5 @@ You can build them all simply by running `make`. Building the code requires `nas
 - **reptar.xlat.elf.asm**: This is similar to `reptar.align.elf.asm` but generates tracing information on the syscalls it executes, so that when the program enters at a different register location, it is possible to observe the consequences. Pause will freeze the process, exit will pass `AL` as the exit code and yield will simply leave the latest `RIP` on `RCX`.
 - **reptar.loopless.elf.asm**: This is an easier to modify reproducer that will also trigger the bug somewhat reliably but also allows to modify the instructions executed before and after. Note the registers that the program uses at the top.
 - **reptar.loop.elf.asm**: This is a more documented reproducer that explains what happens when the bug triggers and which instructions execute and which don't. Running the program on GDB should allow for quick debugging.
-- **reptar.vdso.bin.asm**: This is an experiment where we map ourselves just before the VDSO (you must disable ASLR first and adjust the addresses) and then make the "wrong RIP" point to the VDSO address of the time() function. As a result, the current time is stored in the address pointed to by RAX, which is then clflushed so it triggers a segfault to the current time. If we had corrupted the uop$ then we would instead expect a crash, so it appears that a long jump to the VDSO doesn't corrupt the uop$. To test try: `taskset -c 7 gdb ./reptar.vdso.bin  -ex r -ex 'python import datetime;print(datetime.datetime.utcfromtimestamp(gdb.parse_and_eval("*$rdi")))' -ex q` - if successful you should see the current date/time.
+- **reptar.vdso.bin.asm**: This is an experiment where we map ourselves just before the VDSO (you must disable ASLR first and adjust the addresses) and then make the "wrong RIP" point to the VDSO address of the time() function. As a result, the current time is stored in the address pointed to by RAX, which is then clflushed so it triggers a segfault to the current time. If we had corrupted the uop$ then we would instead expect a crash, so it appears that a long jump to the VDSO doesn't corrupt the uop$. To test try: `taskset -c 7 gdb ./reptar.vdso.bin  -ex r -ex 'python import datetime;print(datetime.datetime.utcfromtimestamp(gdb.parse_and_eval("*$rdi")))' -ex 'p $rsp' -ex q` - if the uop$ was not corrupted, you should see the current date/time. If it was, we would expect a segfault when writing to `0x42` at the poisoned address.
 - **reptar.mce.elf.asm**: Trigger this with `./log_mce.sh` and adjust the cpu 15/7 so they are siblings. This code will trigger an MCE on some affected CPUs and log the details. Look at `mce.txt` for the expected MCE errors. If no MCE is visible, define `MCE_INSTRUCTION='rep movsb'` as that works instead on some CPUs.

pocs/cpus/reptar/minimized/reptar.vdso.bin.asm

@@ -1,6 +1,8 @@
 %macro TINY_ELF_PAYLOAD 0
 _start:
     lea rax, [rsp - 0x1000]
+    mov rbx, rax
+    mov r14, 0x41
     xor rbp, rbp
     mov rdx, .end_of_program
     lea r13, [rsp-0x4000]
@@ -21,10 +23,11 @@ _start:
             sub r9, rbp
             cmp r9, 0xb0 ; we are past vdso
             cmova rax, r13 ; this will PF but recover
+            cmova rbx, r14
             align 64
             times 64-16 nop
             clflush [rax]
-            clflush [rsp]
+            clflush [rbx+1]
             .reptar:
                 rep
                 db 0x44; rex.r