From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932193AbbHCTTY (ORCPT ); Mon, 3 Aug 2015 15:19:24 -0400 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:35616 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932143AbbHCTTV (ORCPT ); Mon, 3 Aug 2015 15:19:21 -0400 Date: Mon, 3 Aug 2015 21:18:54 +0200 From: Willy Tarreau To: Andy Lutomirski Cc: Andy Lutomirski , Kees Cook , Steven Rostedt , "security@kernel.org" , X86 ML , Borislav Petkov , Sasha Levin , LKML , Konrad Rzeszutek Wilk , Boris Ostrovsky , Andrew Cooper , Jan Beulich , xen-devel Subject: Re: [PATCH 2/2] x86/ldt: allow to disable modify_ldt at runtime Message-ID: <20150803191854.GC24014@1wt.eu> References: <1438626217-23970-1-git-send-email-w@1wt.eu> <1438626217-23970-3-git-send-email-w@1wt.eu> <20150803190148.GB24014@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 03, 2015 at 12:06:12PM -0700, Andy Lutomirski wrote: > On Mon, Aug 3, 2015 at 12:01 PM, Willy Tarreau wrote: (...) > > 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. > > Sounds good to me. OK I'll send the other one instead once I unpack my PC. > > 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. > > You sure? I'm reasonably confident that Athlon 64 and newer support > SYSRET in legacy and long mode. Of course, I think that SYSCALL is > totally worthless in legacy mode (SYSCALL_MASK isn't available, so I > suspect that the lack of sensible TF handling would be a > show-stopper). I meant loadall cannot be screwed since it was replaced. > >> 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. > > > > How about a dedicated "NMI masked" flag in EFLAGS? That would be > straightforward and dead simple to handle. Sounds like an oxymoron. But such a flag should be atomically manipulated so that you don't re-arm queued NMIs before calling iret. With two flags, a read-only one for "NMI masked" and a modifiable one "keep NMI masked", you can provide an atomic behaviour where you have this latch executed on iret : NMI_MASKED &= KEEP_NMI_MASKED; KEEP_NMI_MASKED = 0; But anyway we're discussing in the void, this CPU doesn't exist so unless intel/AMD designers want to improve their design (and start by talking together to reach the exact same behavior), we'll never see anything like this :-/ Willy