Re: FSGSBASE ABI considerations

07.08.2017 19:20, Andy Lutomirski пишет: I think this is the half-step. It clearly shows that you don't want such state to ever exist, but why not to go a step further and just make the bases to be reset not only by any unrelated modify_ldt() call, but always on schedule? You can state that

Re: FSGSBASE ABI considerations

07.08.2017 19:20, Andy Lutomirski пишет: I think this is the half-step. It clearly shows that you don't want such state to ever exist, but why not to go a step further and just make the bases to be reset not only by any unrelated modify_ldt() call, but always on schedule? You can state that

Re: FSGSBASE ABI considerations

On Mon, Aug 7, 2017 at 10:35 AM, Linus Torvalds wrote: > On Mon, Aug 7, 2017 at 9:20 AM, Andy Lutomirski wrote: >> >> Windows does something sort of like this (I think), but I don't like >> this solution. I fully expect that someone will write a

Re: FSGSBASE ABI considerations

On Mon, Aug 7, 2017 at 10:35 AM, Linus Torvalds wrote: > On Mon, Aug 7, 2017 at 9:20 AM, Andy Lutomirski wrote: >> >> Windows does something sort of like this (I think), but I don't like >> this solution. I fully expect that someone will write a program that >> does: >> >> old = rdgsbase(); >>

Re: FSGSBASE ABI considerations

On Mon, Aug 7, 2017 at 9:20 AM, Andy Lutomirski wrote: > > Windows does something sort of like this (I think), but I don't like > this solution. I fully expect that someone will write a program that > does: > > old = rdgsbase(); > wrgsbase(new); > call_very_fast_function(); >

Re: FSGSBASE ABI considerations

On Mon, Aug 7, 2017 at 9:20 AM, Andy Lutomirski wrote: > > Windows does something sort of like this (I think), but I don't like > this solution. I fully expect that someone will write a program that > does: > > old = rdgsbase(); > wrgsbase(new); > call_very_fast_function(); > wrgsbase(old); > >

Re: FSGSBASE ABI considerations

I hope this will finally enable thread local support to work in a sane way in gcc so that we can actually use it in kernel space and get rid of all the this_cpu_xxx() macros? And thread local RMVs primitives may actually be provided by gcc and be usable in user space so that we can write user

Re: FSGSBASE ABI considerations

I hope this will finally enable thread local support to work in a sane way in gcc so that we can actually use it in kernel space and get rid of all the this_cpu_xxx() macros? And thread local RMVs primitives may actually be provided by gcc and be usable in user space so that we can write user

Re: FSGSBASE ABI considerations

On Mon, Aug 7, 2017 at 1:06 AM, Stas Sergeev wrote: > Hello. > > 31.07.2017 06:05, Andy Lutomirski пишет: >> >> - User code can use the new RD/WR FS/GS BASE instructions. >> Apparently some users really want this for, umm, userspace threading. >> Think Java. > > I wonder how java

Re: FSGSBASE ABI considerations

On Mon, Aug 7, 2017 at 1:06 AM, Stas Sergeev wrote: > Hello. > > 31.07.2017 06:05, Andy Lutomirski пишет: >> >> - User code can use the new RD/WR FS/GS BASE instructions. >> Apparently some users really want this for, umm, userspace threading. >> Think Java. > > I wonder how java avoids the

Re: FSGSBASE ABI considerations

On Jul 31, 2017, at 5:23 PM, Bae, Chang Seok wrote: >> On an FSGSBASE-enabled system, I think we need to provide deterministic, >> documented, tested behavior. I can think of three plausible choices: >> 1a. modify_ldt() immediately updates FSBASE and GSBASE all

Re: FSGSBASE ABI considerations

On Jul 31, 2017, at 5:23 PM, Bae, Chang Seok wrote: >> On an FSGSBASE-enabled system, I think we need to provide deterministic, >> documented, tested behavior. I can think of three plausible choices: >> 1a. modify_ldt() immediately updates FSBASE and GSBASE all threads that >> reference the

Re: FSGSBASE ABI considerations

Hello. 31.07.2017 06:05, Andy Lutomirski пишет: - User code can use the new RD/WR FS/GS BASE instructions. Apparently some users really want this for, umm, userspace threading. Think Java. I wonder how java avoids the lack of the user-space continuations support while getting the userspace

Re: FSGSBASE ABI considerations

Hello. 31.07.2017 06:05, Andy Lutomirski пишет: - User code can use the new RD/WR FS/GS BASE instructions. Apparently some users really want this for, umm, userspace threading. Think Java. I wonder how java avoids the lack of the user-space continuations support while getting the userspace

RE: FSGSBASE ABI considerations

> On an FSGSBASE-enabled system, I think we need to provide deterministic, > documented, tested behavior. I can think of three plausible choices: > 1a. modify_ldt() immediately updates FSBASE and GSBASE all threads that > reference the modified selector. > 1b. modify_ldt() immediatley updates

RE: FSGSBASE ABI considerations

> On an FSGSBASE-enabled system, I think we need to provide deterministic, > documented, tested behavior. I can think of three plausible choices: > 1a. modify_ldt() immediately updates FSBASE and GSBASE all threads that > reference the modified selector. > 1b. modify_ldt() immediatley updates

Re: FSGSBASE ABI considerations

On Mon, Jul 31, 2017 at 3:55 AM, Kirill A. Shutemov wrote: > On Sun, Jul 30, 2017 at 08:05:43PM -0700, Andy Lutomirski wrote: >> Hi all- >> >> Chang wants to get the FSGSBASE patches in. Here's a bit on a brain >> dump on what I think the relevant considerations are and why

Re: FSGSBASE ABI considerations

On Mon, Jul 31, 2017 at 3:55 AM, Kirill A. Shutemov wrote: > On Sun, Jul 30, 2017 at 08:05:43PM -0700, Andy Lutomirski wrote: >> Hi all- >> >> Chang wants to get the FSGSBASE patches in. Here's a bit on a brain >> dump on what I think the relevant considerations are and why I haven't >> sent out

Re: FSGSBASE ABI considerations

On Sun, Jul 30, 2017 at 9:38 PM, Linus Torvalds wrote: > On Sun, Jul 30, 2017 at 8:05 PM, Andy Lutomirski wrote: >> >> This means that, when gdb saves away a regset and reloads it using >> PTRACE_SETREGS or similar, the effect is to load gs_base

Re: FSGSBASE ABI considerations

On Sun, Jul 30, 2017 at 9:38 PM, Linus Torvalds wrote: > On Sun, Jul 30, 2017 at 8:05 PM, Andy Lutomirski wrote: >> >> This means that, when gdb saves away a regset and reloads it using >> PTRACE_SETREGS or similar, the effect is to load gs_base and then load >> gs. If gs != 0, this will blow

Re: FSGSBASE ABI considerations

On Sun, Jul 30, 2017 at 08:05:43PM -0700, Andy Lutomirski wrote: > Hi all- > > Chang wants to get the FSGSBASE patches in. Here's a bit on a brain > dump on what I think the relevant considerations are and why I haven't > sent out my patches. I'm not sure if it would be relevant input for the

Re: FSGSBASE ABI considerations

On Sun, Jul 30, 2017 at 08:05:43PM -0700, Andy Lutomirski wrote: > Hi all- > > Chang wants to get the FSGSBASE patches in. Here's a bit on a brain > dump on what I think the relevant considerations are and why I haven't > sent out my patches. I'm not sure if it would be relevant input for the

Re: FSGSBASE ABI considerations

On Sun, Jul 30, 2017 at 8:05 PM, Andy Lutomirski wrote: > > This means that, when gdb saves away a regset and reloads it using > PTRACE_SETREGS or similar, the effect is to load gs_base and then load > gs. If gs != 0, this will blow away gs_base. Without FSGSBASE, this >

Re: FSGSBASE ABI considerations

On Sun, Jul 30, 2017 at 8:05 PM, Andy Lutomirski wrote: > > This means that, when gdb saves away a regset and reloads it using > PTRACE_SETREGS or similar, the effect is to load gs_base and then load > gs. If gs != 0, this will blow away gs_base. Without FSGSBASE, this > doesn't matter so much.