Messages in this thread | | | From | "Bae, Chang Seok" <> | Subject | Re: [PATCH v9 00/17] Enable FSGSBASE instructions | Date | Mon, 24 Feb 2020 18:02:17 +0000 |
| |
> On Dec 4, 2019, at 12:20, Andy Lutomirski <luto@kernel.org> 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
| |