Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1699682

Re: FSGSBASE ABI considerations

Show all headers | View raw

On Sun, Jul 30, 2017 at 8:05 PM, Andy Lutomirski <luto@kernel.org> 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.  With FSGSBASE, it means that using gdb to do,
> say, 'print func()' may corrupt gsbase.
>
> What, if anything, should we do about this?  One option would be to
> make gs_base be accurate all the time (it currently isn't) and teach
> PTRACE_SETREGS to restore in the opposite order despite the struct
> layout.

I do not think that ordering should ever matter. If it does, it means
that you've designed something. We already screwed that up with the
msr interface, can we try to not do it again?

Could we perhaps do something like:

 - every process starts out with CR4.FSGSBASE cleared

 - if we get an #UD due to the process using the {rd|wr}{gs|fs}base
instructions,  we enable FSGSBASE and mark the process as using those
instructions.

 - once a process is marked as FSGSBASE, the kernel prioritizes
FSGSBASE. We'll still save/restore the selector too, but every time we
restore the selector, we will first do a rd*base, and then do a
wr*base afterwards

IOW, the "selector" ends up being meaningless after people have used
fsgsbase. It is saved and restored as a _value_, but it has no effect
what-so-ever on the actual base pointer.

Yes, it's modal, but at least you don't end up in some situation where
it matters whether you write the selector first or not.

Hmm?

                 Linus

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

FSGSBASE ABI considerations Andy Lutomirski <luto@kernel.org> - 2017-07-31 05:10 +0200
  Re: FSGSBASE ABI considerations Linus Torvalds <torvalds@linux-foundation.org> - 2017-07-31 06:40 +0200
    Re: FSGSBASE ABI considerations Andy Lutomirski <luto@kernel.org> - 2017-07-31 16:20 +0200
  Re: FSGSBASE ABI considerations "Kirill A. Shutemov" <kirill@shutemov.name> - 2017-07-31 13:00 +0200
    Re: FSGSBASE ABI considerations Andy Lutomirski <luto@kernel.org> - 2017-07-31 16:20 +0200
  RE: FSGSBASE ABI considerations "Bae, Chang Seok" <chang.seok.bae@intel.com> - 2017-07-31 23:30 +0200
    Re: FSGSBASE ABI considerations Andy Lutomirski <luto@kernel.org> - 2017-08-07 18:20 +0200
  Re: FSGSBASE ABI considerations Stas Sergeev <stsp@list.ru> - 2017-08-07 10:10 +0200
    Re: FSGSBASE ABI considerations Andy Lutomirski <luto@kernel.org> - 2017-08-07 18:30 +0200
      Re: FSGSBASE ABI considerations Christopher Lameter <cl@linux.com> - 2017-08-07 19:00 +0200
      Re: FSGSBASE ABI considerations Linus Torvalds <torvalds@linux-foundation.org> - 2017-08-07 19:40 +0200
        Re: FSGSBASE ABI considerations Andy Lutomirski <luto@kernel.org> - 2017-08-07 21:10 +0200
      Re: FSGSBASE ABI considerations Stas Sergeev <stsp@list.ru> - 2017-08-08 00:20 +0200

csiph-web