Home Original page

[PATCH 0/5] i386: Optimize for Jump Conditional Code Erratum

Jeff Law law@redhat.com
Thu Nov 14 20:26:00 GMT 2019 
On 11/14/19 12:45 PM, Florian Weimer wrote:
[ ...]

> I suspect that if you do not run with a microcode update, the
> mitigation would only have to be applied to certain Jcc opcodes, so
> considerably fewer changes are needed.  I don't think there is public
> guidance regarding the required mitigation for that.  But given that
> it targets only Jcc instead of JMP/CALL/RET/Jcc, I expect that the
> impact would be less.  And who knows, maybe only conditional jumps of
> a certain encoding are affected.
This is what I was referring to.  Under what conditions does this
problem show up.  Yea, I know it's branches spanning cache lines, but
it's got to be more complex than that :-)


> 
>> The other thing that comes to mind is branch target alignment.   If a
>> jump is going to need alignment, might it be better to instead insert
>> the nops/prefixes at the previous label in some cases?
> 
> Yes, that's exactly what's suggested in the whitepaper.  We could also
> shift the function alignment itself, so that the entry point is not
> aligned on a 16-byte boundary, if that happens to move the control
> flow instructions away from the problematic 32-byte boundaries.
> Although that would likely break some software that assumes 16-byte
> function alignment.  There is at least one example of enterprise
> software that uses the padding around certain glibc system call
> wrappers to store their hot-patching trampolines, for example.
I  must have missed that.  Good to see my idea isn't totally off base.

Jeff
More information about the Binutils mailing list