Ptrace with FSGSBASE

Robert O'Callahan robert at ocallahan.org
Thu Mar 8 22:04:06 UTC 2018


Thanks for the notification!

On Fri, Mar 9, 2018 at 10:22 AM, Bae, Chang Seok <chang.seok.bae at intel.com>
wrote:

> I’m working on enabling FSGSBASE instructions [1, 2] in Linux kernel. The
> FSGSBASE instruction set allows
> to read/write FS/GS base directly from any privilege. With that, any
> thread may have own FS/GS base
> regardless of its selector. The reason I’m contacting you is to coordinate
> any legacy behavior that your tool chain
> may rely on, before submitting our patches.
>
> Currently, FS/GS base is reloaded from GDT/LDT if selector is not zero.
> With that, ptrace has such implications
> on fs/gs set via SETREG* so far:
>
> (1) If fs/gs only set
>         - to any nonzero value, fs_base/gs_base is fetched from GDT/LDT,
> when tracee resumes.
>         - to zero, current fs_base/gs_base is kept
> (2) If fs_base/gs_base only set to any new,
>         - when fs/gs is zero, new fs_base/gs_base is set
>         - when fs/gs is nonzero, new value is ignored
>                 and fs_base/gs_base is fetched from GDT/LDT, when tracee
> resumes
> (3) If both fs/gs and fs_base/gs_base are set;
>         - fs/gs set to any nonzero, fs_base/gs_base fetched from
>                 GDT/LDT entry of the new fs/gs (selector), when tracee
> resumes
>         - fs/gs set to zero, new fs_base/gs_base is set
>
> Note. ptrace's SETREG* accepts user_regs_struct aligned data, where fs/gs
> and fs_base/gs_base entries are.
>
> We prepared kernel patch set with following behaviors when FSGSBASE
> instructions are enabled.
>
>         (1) is taken as regarded as a legacy behavior; it will do the same
>         (2) & (3), (New) regardless of fs/gs value, new base value is
> always set
>
> This new behavior is driven by that each thread’s FS/GS base is preserved
> during context switch.
>

Every call to PTRACE_SET_REGS sets all of  fs, gs, fs_base and gs_base. So
what does it mean to set fs/gs and not fs_base/gs_base? Are you comparing
the old and new values of these registers and saying that we "set fs" if
and only if the value of fs changes?

Anyway I think rr will be fine with the new behavior. Our modifications to
fs/gs/fs_base/gs_base are always either a) setting values that the kernel
set during recording to make them happen during replay or b) emulating
PTRACE_SET_REGS that a tracee ptracer tried to set on another tracee.
Either way I think the effects are going to be the same as what would
happen if the program were run without rr.

Thanks,
Rob
-- 
Su ot deraeppa sah dna Rehtaf eht htiw saw hcihw, efil lanrete eht uoy ot
mialcorp ew dna, ti ot yfitset dna ti nees evah ew; deraeppa efil eht. Efil
fo Drow eht gninrecnoc mialcorp ew siht - dehcuot evah sdnah ruo dna ta
dekool evah ew hcihw, seye ruo htiw nees evah ew hcihw, draeh evah ew
hcihw, gninnigeb eht morf saw hcihw taht.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rr-dev/attachments/20180309/3f3b11fe/attachment.html>


More information about the rr-dev mailing list