Re: [PATCH v9 00/17] Enable FSGSBASE instructions

From: Bae, Chang Seok
Date: Mon Feb 24 2020 - 13:02:23 EST



> On Dec 4, 2019, at 12:20, Andy Lutomirski <luto@xxxxxxxxxx> wrote:
>
> I think it could make sense to add a whole new ptrace() command to
> tell the tracee to, in effect, MOV a specified value to a segment
> register. This call would have the actual correct semantics in which
> it would return an error code if the specified value is invalid and
> would return 0 on success. And then a second ptrace() call could be
> issued to read out FSBASE or GSBASE if needed. Would this be useful?
> What gdb commands would invoke it?

We consider new commands to access GDT/LDT that hpa posted before [1] may be
helpful. If the kernel provides the interfaces to ptracer, we expect GDB for
both 32-/64-bits can make such changes for inferior calls:
(1) When FS/GS selector only updated,
GDB used to write the selector value via SETREGS. Now it can read the
base value from the new APIs and write the base also. This change does
not harm today's kernel, and it retains the legacy behavior on
FSGSBASE-enabled kernels in the future.
(2) When FS/GS base only updated,
(3) When both FS/GS selector and base updated,
GDB has no change from what it used to do. The new FSGSBASE-enabled
kernel improves the behavior by keeping the base regardless of a
selector.

The proposed change in GDB would do an additional GETREGS for every SETREGS
to obtain the old value. Other ptrace-users may need a similar patch if
sensitive to the outcome from writing FS/GS selector, but last time when we
surveyed for other tools [2, 3], we didn't find the issue. We also didn't
find actual users who rely on legacy behavior in practice.

We'd like to hear a clear opinion of whether the GDB changes along with the
new ptrace APIs are necessary and sufficient as preparing the FSGSBASE
support in the kernel.

[1] https://lore.kernel.org/patchwork/cover/954471/
[2] https://mail.mozilla.org/pipermail/rr-dev/2018-March/000616.html
[3] https://lists.openvz.org/pipermail/criu/2018-March/040654.html

Thanks,
Chang