Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965132AbaD3Wqr (ORCPT ); Wed, 30 Apr 2014 18:46:47 -0400 Received: from mga09.intel.com ([134.134.136.24]:45841 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965000AbaD3Wqq (ORCPT ); Wed, 30 Apr 2014 18:46:46 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.97,960,1389772800"; d="scan'208";a="532739458" Message-ID: <53617D54.2060709@linux.intel.com> Date: Wed, 30 Apr 2014 15:46:44 -0700 From: "H. Peter Anvin" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Jiri Kosina CC: Steven Rostedt , Linus Torvalds , linux-kernel@vger.kernel.org, x86@kernel.org, Salman Qazi , Ingo Molnar , Michal Hocko , Borislav Petkov , Vojtech Pavlik , Petr Tesarik , Petr Mladek Subject: Re: 64bit x86: NMI nesting still buggy? References: <535FA920.9080503@linux.intel.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/30/2014 03:10 PM, Jiri Kosina wrote: > On Tue, 29 Apr 2014, H. Peter Anvin wrote: > >>> [2] "A special case can occur if an SMI handler nests inside an NMI >>> handler and then another NMI occurs. During NMI interrupt >>> handling, NMI interrupts are disabled, so normally NMI interrupts >>> are serviced and completed with an IRET instruction one at a >>> time. When the processor enters SMM while executing an NMI >>> handler, the processor saves the SMRAM state save map but does >>> not save the attribute to keep NMI interrupts disabled. >>> Potentially, an NMI could be latched (while in SMM or upon exit) >>> and serviced upon exit of SMM even though the previous NMI >>> handler has still not completed." >> >> I believe [2] only applies if there is an IRET executing inside the SMM >> handler, which should not normally be the case. It might also have been >> addressed since that was written, but I don't know. > > Is there any chance that Intel would reveal what's behind this paragraph > and how likely it is to expect such BIOSes in the wild? > I can ask internally and try to find out. It might very well be stale, I don't know. -hpa -- 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/