On Wed, Aug 2, 2017 at 9:56 AM, Kees Cook <keesc...@chromium.org> wrote: > On Wed, Aug 2, 2017 at 9:42 AM, Thomas Garnier <thgar...@google.com> wrote: >> I noticed that not only we have the problem of gs:0x40 not being >> accessible. The compiler will default to the fs register if >> mcmodel=kernel is not set. >> >> On the next patch set, I am going to add support for >> -mstack-protector-guard=global so a global variable can be used >> instead of the segment register. Similar approach than ARM/ARM64. > > While this is probably understood, I have to point out that this would > be a major regression for the stack protection on x86.
I agree, the optimal solution will be using updated gcc/clang. > >> Following this patch, I will work with gcc and llvm to add >> -mstack-protector-reg=<segment register> support similar to PowerPC. >> This way we can have gs used even without mcmodel=kernel. Once that's >> an option, I can setup the GDT as described in the previous email >> (similar to RFG). > > It would be much nicer if we could teach gcc about the percpu area > instead. This would let us solve the global stack protector problem on > the other architectures: > http://www.openwall.com/lists/kernel-hardening/2017/06/27/6 Yes, while I am looking at gcc I will take a look at other architecture to see if I can help there too. > > -Kees > > -- > Kees Cook > Pixel Security -- Thomas _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel