Spectre V1 diagnostic / mitigation

[Richard Biener]

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.

Richard.