Ptrace with FSGSBASE

Robert O'Callahan robert at
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>

> 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.

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: <>

More information about the rr-dev mailing list