[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrUxQ1XOs7V1XKOsk-iQ-qOwn41sWGYkepkVOE7PtfX24A@mail.gmail.com>
Date: Thu, 22 Mar 2018 01:40:38 +0000
From: Andy Lutomirski <luto@...nel.org>
To: "Bae, Chang Seok" <chang.seok.bae@...el.com>
Cc: Andy Lutomirski <luto@...nel.org>, X86 ML <x86@...nel.org>,
Andi Kleen <ak@...ux.intel.com>,
"H. Peter Anvin" <hpa@...or.com>,
"Metzger, Markus T" <markus.t.metzger@...el.com>,
"Luck, Tony" <tony.luck@...el.com>,
"Shankar, Ravi V" <ravi.v.shankar@...el.com>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 14/15] x86/fsgsbase/64: Support legacy behavior when FS/GS
updated by ptracer
On Wed, Mar 21, 2018 at 3:11 PM, Bae, Chang Seok
<chang.seok.bae@...el.com> wrote:
> On 3/20/18, 17:47, "Andy Lutomirski" <luto@...nel.org> wrote:
>> If I've understood all your emails right, when you looked at existing
>> ptrace users, you found that all of them that write to gs and/or
>> gs_base do it as part of a putregs call that writes them at the same
>> time. If so, then your patch does exactly the same thing that my old
>> patches did, but your patch is much more complicated. So why did you
>> add all that complexity?
>
> What is tried to be provided is backward compatibility by emulating
> “mov gs (fs) …” when index is only changed and preserve a (given) base value
> in other cases.
mov to gs changes GSBASE even if GS was unchanged.
But it's not clear to me that you've identified any case where
emulating this behavior is useful.
Powered by blists - more mailing lists