[CRIU] Ptrace with FSGSBASE

Cyrill Gorcunov gorcunov at gmail.com
Sat Mar 10 01:25:17 MSK 2018

On Thu, Mar 08, 2018 at 09:22:44PM +0000, Bae, Chang Seok wrote:
> Hi, 
> 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. 
> Chang
> [1] http://www.felixcloutier.com/x86/RDFSBASE:RDGSBASE.html
> [2] http://www.felixcloutier.com/x86/WRFSBASE:WRGSBASE.html 

Hi! Internally in criu we fetch the regset via ptrace and keep them in images
as they were at moment of dump (if ldt is being used we don't support
such tasks) so I think the changes should not break criu.

More information about the CRIU mailing list