RE: [External] : [oss-security] Possible AMD Zen2 CVE

[Casper Dik <casper.dik () oracle com>]

I think you've run into an issue with gcc.

It does not always honor the order and it I have seen issues
where I was not able to get gcc to properly order the code unless
I was using some trick.  That particular trick, a smidgen of volatile
casts did not work.

The code in question:

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

In the "good" binary the "incw" of the obj.lock is after the "incq" of obj.value;
but in the "bad" binary you see the instructions correctly, incw before incq.

I had the problem with an Intel system running Solaris (hence  different
assembly output):

good:
     wr_thread+0xe7:         48 ff 05 8a 09 10  incq   +0x10098a(%rip)   <obj+0x8>
                            00 
    wr_thread+0xee:         66 ff 05 7b 09 10  incw   +0x10097b(%rip)   <obj>
                            00 

bad:
    wr_thread+0xee:         66 ff 05 8b 09 10  incw   +0x10098b(%rip)   <obj>
                            00 
    wr_thread+0xf5:         48 ff c0           incq   %rax
    wr_thread+0xf8:         48 89 05 89 09 10  movq   %rax,+0x100989(%rip)      <obj+0x8>
                            00 
    wr_thread+0xff:         48 89 05 9a 09 10  movq   %rax,+0x10099a(%rip) 
     
Casper