tunables vs osxsave vs checkpointing vs _dl_runtime_resolve

[H.J. Lu]

On Thu, Mar 18, 2021 at 10:18 AM DJ Delorie via Libc-alpha
<libc-alpha@sourceware.org> wrote:
>
>
> In response to this customer bug...
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1937515
>
> I spent some time digging into this code, and was able to reproduce it
> using criu (checkpoint/restore in userspace).  In a nutshell: if you
> create a task on a machine WITH xsave (or xsavec), and migrate it
> (somehow) to a machine WITHOUT xsave (or xsavec), any further DSO
> calls will fail because we've already chosen an xsave/xsavec resolver.
>
> This, of course, is guaranteed to fail, and cannot be fixed.  With
> criu I had to override the checks with a command line option just to
> prove my point.
>
> However, if you *know* you might do this, there should be a way to use
> tunables to avoid xsave/xsavec - with the usual caveats about "YMMV" -
> so that a process could be migrated across such CPUs without fault.
>
> Our tunables almost provide this.
>
> IMHO the tunables logic should interact with cpu features like this:
>
> 1. Read the CPU features available
> 2. Apply tunables
> 3. Make secondary decisions based on the results
>
> The code that handles xsave breaks these rules; the save size for
> extended registers is computed before tunables are applied, so
> disabling xsave, xsavec, or osxsave in tunables has no affect.
> *After* tunables, we use the save size to determine if xsave/xsavec
> are enabled!
>
> It looks like just moving the save_size logic in update_usable()
> (cpu_features.c) to after the tunables check in init_cpu_features()
> should "solve" this problem, allowing tunables to determine if
> xsave/xsavec are used in dl_runtime_resolve.  However, the code is
> complex and hairy and there's a good chance for gotchas in there.
>
> Comments?
>

Please open a glibc bug and CC me.

-- 
H.J.