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


Groups > linux.kernel > #1199201

Re: [PATCH 2/2] x86/ldt: allow to disable modify_ldt at runtime

From Willy Tarreau <w@1wt.eu>
Newsgroups linux.kernel
Subject Re: [PATCH 2/2] x86/ldt: allow to disable modify_ldt at runtime
Date 2015-08-03 21:10 +0200
Message-ID <pTthx-3DC-29@gated-at.bofh.it> (permalink)
References <pTsEO-2EE-29@gated-at.bofh.it> <pTsEP-2EE-45@gated-at.bofh.it> <pTsY9-31v-3@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Mon, Aug 03, 2015 at 11:45:24AM -0700, Andy Lutomirski wrote:
> I'm not entirely convinced that the lock bit should work this way.  At
> some point, we might want a setting for "32-bit only" or even "32-bit,
> present, not non-conforming only" (like we do unconditionally for
> set_thread_area).  When we do that, having -1 act like 0 might be
> confusing.
> 
> I'd actually favor rigging it up to support enumerated values and/or
> the word "locked" somewhere in the text.  So we could have "0", "1
> locked", "1" or even "enabled" "enabled locked", "disabled", "disabled
> locked", "safe 32-bit", "safe 32-bit locked", etc.

Got it, that makes sense indeed. I asked myself whether we'd use more
than these 3 values, and estimated that "locked on" didn't make much
sense here, and I thought that nobody would like to manipulate such
things using bitmaps. But with words like this it can indeed make
sense.

I feel like it's probably part of a larger project then. Do you think
we should step back and only support 0/1 for now ? I also have the
patch available.

> I'll add an explicit 16-bit check to my infinite todo list for the asm
> part.  Now that the synchronous modify_ldt code is merged, it won't be
> racy, and it would make a 32-bit only mode actually be useful (except
> maybe on AMD -- someone needs to test just how badly broken IRET is on
> AMD systems -- I know that AMD has IRET-to-16-bit differently broken
> from Intel, and that causes test-cast failures.  Grump.)
> 
> P.S. Hey CPU vendors: please consider stopping your utter suckage when
> it comes to critical system instructions.  Intel and AMD both
> terminally screwed up IRET in multiple ways that clearly took actual
> effort.  Intel screwed up SYSRET pretty badly (AFAIK every single
> 64-bit OS has had at least one root hole as a result), and AMD screwed
> SYSRET up differently (userspace crash bug that requires a performance
> hit to mitigate because no one at AMD realized that one might preempt
> a process during a syscall).

Well the good thing is that SYSRET reused the LOADALL opcode so at
least this one cannot be screwed on 64-bit :-) It would have helped us
to emulate IRET though.

> P.P.S. You know what would be *way* better than allowing IRET to
> fault?  Just allow IRET to continue executing the next instruction on
> failure (I'm talking about #GP, #NP, and #SS here, not page faults).
> 
> P.P.P.S.  Who thought that IRET faults unmasking NMIs made any sense
> whatsoever when NMIs run on an IST stack?  Seriously, people?

A dedicated flag "don't clear NMI yet" would have been nice in EFLAGS
so that the software stack could set it in fault handlers. It would be
one-shot and always cleared by IRET. That would have been very handy.

Willy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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


Thread

[PATCH 0/2] x86: allow to enable/disable modify_ldt at run time Willy Tarreau <w@1wt.eu> - 2015-08-03 20:30 +0200
  [PATCH 2/2] x86/ldt: allow to disable modify_ldt at runtime Willy Tarreau <w@1wt.eu> - 2015-08-03 20:30 +0200
    Re: [PATCH 2/2] x86/ldt: allow to disable modify_ldt at runtime Andy Lutomirski <luto@amacapital.net> - 2015-08-03 20:50 +0200
      Re: [PATCH 2/2] x86/ldt: allow to disable modify_ldt at runtime Andy Lutomirski <luto@amacapital.net> - 2015-08-03 21:10 +0200
        Re: [PATCH 2/2] x86/ldt: allow to disable modify_ldt at runtime Willy Tarreau <w@1wt.eu> - 2015-08-03 21:20 +0200
      Re: [PATCH 2/2] x86/ldt: allow to disable modify_ldt at runtime Willy Tarreau <w@1wt.eu> - 2015-08-03 21:10 +0200
      Re: [PATCH 2/2] x86/ldt: allow to disable modify_ldt at runtime Borislav Petkov <bp@alien8.de> - 2015-08-04 06:00 +0200
        Re: [PATCH 2/2] x86/ldt: allow to disable modify_ldt at runtime Willy Tarreau <w@1wt.eu> - 2015-08-04 08:10 +0200
    Re: [PATCH 2/2] x86/ldt: allow to disable modify_ldt at runtime Kees Cook <keescook@chromium.org> - 2015-08-04 00:40 +0200
      Re: [PATCH 2/2] x86/ldt: allow to disable modify_ldt at runtime Willy Tarreau <w@1wt.eu> - 2015-08-04 01:30 +0200
        Re: [PATCH 2/2] x86/ldt: allow to disable modify_ldt at runtime Kees Cook <keescook@chromium.org> - 2015-08-04 03:40 +0200
  [PATCH v3 1/1] x86: allow to enable/disable modify_ldt at run time Willy Tarreau <w@1wt.eu> - 2015-08-04 11:00 +0200

csiph-web