Messages in this thread | | | From | Andy Lutomirski <> | Date | Thu, 22 Mar 2018 01:39:58 +0000 | Subject | Re: [PATCH 14/15] x86/fsgsbase/64: Support legacy behavior when FS/GS updated by ptracer |
| |
On Wed, Mar 21, 2018 at 7:01 AM, Metzger, Markus T <markus.t.metzger@intel.com> wrote: >> -----Original Message----- >> From: Andy Lutomirski [mailto:luto@kernel.org] >> 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.
| |