[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrUrvrQNw6dPau_rtHjA_YuCVdCTWYd4dsdcvcGsOaspmg@mail.gmail.com>
Date: Mon, 24 Aug 2020 14:10:12 -0700
From: Andy Lutomirski <luto@...nel.org>
To: "Robert O'Callahan" <robert@...llahan.org>
Cc: "Bae, Chang Seok" <chang.seok.bae@...el.com>,
Kyle Huey <me@...ehuey.com>, Andy Lutomirski <luto@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...nel.org>,
"H . Peter Anvin" <hpa@...or.com>, Andi Kleen <ak@...ux.intel.com>,
"Shankar, Ravi V" <ravi.v.shankar@...el.com>,
LKML <linux-kernel@...r.kernel.org>,
"Hansen, Dave" <dave.hansen@...el.com>
Subject: Re: [REGRESSION] x86/cpu fsgsbase breaks TLS in 32 bit rr tracees on
a 64 bit system
On Sat, Aug 22, 2020 at 6:19 AM Andy Lutomirski <luto@...capital.net> wrote:
>
> We can give you a new ptrace operation to load the selector and deduce the base from the descriptor table if it would help.
Concretely, we could add one of these:
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?
--Andhy
Powered by blists - more mailing lists