Re: [PATCH 14/15] x86/fsgsbase/64: Support legacy behavior when FS/GS updated by ptracer

[Andy Lutomirski]

On Wed, Mar 21, 2018 at 7:01 AM, Metzger, Markus T
<markus.t.metzger@xxxxxxxxx> wrote:
>> -----Original Message-----
>> From: Andy Lutomirski [mailto:luto@xxxxxxxxxx]
>> Sent: 21 March 2018 01:47
>
> Hello Andy,
>
>> I retract this particular comment.  But I still think that all this complexity needs to
>> be more clearly justified.  My objection to the old approach wasn't that I thought
>> it was obviously wrong -- I thought that someone needed to survey existing
>> ptrace() users and see if anyone needed the fancier code that you're adding.  Did
>> you find something that needs this fancy code?
>
> There are 3 cases:
> - only FS changed, e.g. "p $fs = ..."

If a person literally types that, I have no problem if they get
different behavior on different systems.  If it's some existing
program that needs to keep working, then we may be out of luck, since
gdb seems to use SETREGS.

> - only FS_BASE changed, e.g. "p $fs_base = ..."

That's fine no matter what, I think.

> - both change, e.g. "p foo()" when restoring the original register state on return
>   from the inferior call

This is the interesting case.  If everything that matters uses
SETREGS, then I think we're in good shape, and we should probably just
make writing to FS using ptrace on FSGSBASE systems *not* change
FSBASE, since that way is much simpler.