Messages in this thread | | | Date | Tue, 25 Aug 2020 08:13:51 -0700 | Subject | Re: [REGRESSION] x86/cpu fsgsbase breaks TLS in 32 bit rr tracees on a 64 bit system | From | hpa@zytor ... |
| |
On August 24, 2020 5:30:56 PM PDT, Andy Lutomirski <luto@kernel.org> wrote: >On Mon, Aug 24, 2020 at 4:52 PM H. Peter Anvin <hpa@zytor.com> wrote: >> >> On 2020-08-24 14:10, Andy Lutomirski wrote: >> > >> > PTRACE_READ_SEGMENT_DESCRIPTOR to read a segment descriptor. >> > >> > PTRACE_SET_FS / PTRACE_SET_GS: Sets FS or GS and updates the base >accordingly. >> > >> > PTRACE_READ_SEGMENT_BASE: pass in a segment selector, get a base >out. >> > You would use this to populate the base fields. >> > >> > or perhaps a ptrace SETREGS variant that tries to preserve the old >> > base semantics and magically sets the bases to match the selectors >if >> > the selectors are nonzero. >> > >> > Do any of these choices sound preferable to any of you? >> > >> >> My suggestion would be to export the GDT and LDT as a (readonly or >mostly >> readonly) regset(s) rather than adding entirely new operations. We >could allow >> the LDT and the per-thread GDT entries to be written, subject to the >same >> limitations as the corresponding system calls. >> > >That seems useful, although we'd want to do some extensive >sanitization of the GDT. But maybe it's obnoxious to ask Kyle and >Robert to parse the GDT, LDT, and selector just to emulate the >demented pre-5.9 ptrace() behavior. > >--Andy
We only want to allow the same access that user space gets, that's exactly the sanitization we need. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
| |