On Wed, 19 Dec 2018, Richard Earnshaw (lists) wrote: > On 19/12/2018 17:17, Richard Biener wrote: > > On Wed, 19 Dec 2018, Florian Weimer wrote: > > > >> * Peter Bergner: > >> > >>> On 12/19/18 7:59 AM, Florian Weimer wrote: > >>>> * Richard Biener: > >>>> > >>>>> Sure, if we'd ever deploy this in production placing this in the > >>>>> TCB for glibc targets might be beneifical. But as said the > >>>>> current implementation was just an experiment intended to be > >>>>> maximum portable. I suppose the dynamic loader takes care > >>>>> of initializing the TCB data? > >>>> > >>>> Yes, the dynamic linker will initialize it. If you need 100% reliable > >>>> initialization with something that is not zero, it's going to be tricky > >>>> though. Initial-exec TLS memory has this covered, but in the TCB, we > >>>> only have zeroed-out reservations today. > >>> > >>> We have non-zero initialized TCB entries on powerpc*-linux which are used > >>> for the GCC __builtin_cpu_is() and __builtin_cpu_supports() builtin > >>> functions. Tulio would know the magic that was used to get them setup. > >> > >> Yes, there's a special symbol, __parse_hwcap_and_convert_at_platform, to > >> verify that the dynamic linker sets up the TCB as required. This way, > >> binaries which need the feature will fail to run on older loaders. This > >> is why I said it's a bit tricky to implement this. It's even more > >> complicated if you want to backport this into released glibcs, where we > >> normally do not accept ABI changes (not even ABI additions). > > > > It's easy to change the mitigation scheme to use a zero for the > > non-speculated path, you'd simply replace ands with zero by > > ors with -1. For address parts that gets you some possible overflows > > you do not want though. > > And you have to invert the value before using it as a mask.
For the cases an OR doesn't work yes. Fortunately most targets have an and-not instruction. (x86 doesn't unless you have BMI) Richard.
