[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID:
<DS7PR10MB53580D81F624AC15BEBBC39AFDFAA@DS7PR10MB5358.namprd10.prod.outlook.com>
Date: Tue, 19 Sep 2023 14:46:35 +0000
From: Casper Dik <casper.dik@...cle.com>
To: "oss-security@...ts.openwall.com" <oss-security@...ts.openwall.com>,
Steve
Thompson <susurrus.of.qualia@...il.com>
Subject: RE: [External] : Possible AMD Zen2 CVE
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
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
