From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49589) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yrpkj-0005Dw-Mn for qemu-devel@nongnu.org; Mon, 11 May 2015 11:36:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yrpkg-0006Q4-12 for qemu-devel@nongnu.org; Mon, 11 May 2015 11:36:21 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51207) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yrpkf-0006Py-Rk for qemu-devel@nongnu.org; Mon, 11 May 2015 11:36:17 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 5CFDC96C8 for ; Mon, 11 May 2015 15:36:17 +0000 (UTC) Message-ID: <5550CC6D.7080903@redhat.com> Date: Mon, 11 May 2015 17:36:13 +0200 From: Laszlo Ersek MIME-Version: 1.0 References: <1431352157-40283-1-git-send-email-pbonzini@redhat.com> <1431352157-40283-24-git-send-email-pbonzini@redhat.com> <5550C808.8000505@redhat.com> <5550C8FE.8080804@redhat.com> In-Reply-To: <5550C8FE.8080804@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 23/31] ich9: implement SMI_LOCK List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , kraxel@redhat.com Cc: qemu-devel@nongnu.org, mst@redhat.com On 05/11/15 17:21, Paolo Bonzini wrote: > > > On 11/05/2015 17:17, Laszlo Ersek wrote: >> If I understand correctly, this makes SMI_LOCK lock down the GBL_SMI_EN >> bit (and my OVMF patch that relies on that / tests it is satisfied too). >> >> But, it doesn't seem to lock down APMC_EN. According to the ICH9 spec, >> it doesn't need to -- however when we discussed this earlier (see >> Message-Id: <553F4D23.3060305@redhat.com>), the idea was to lock down >> APMC_EN as well. (And I don't understand why the ICH9 spec / hw >> implementation doesn't lock APMC_EN; without that, APM_CNT won't >> necessarily trigger an SMI.) > > I don't think it should. See here > > where I wrote explicitly "Even if the OS tries to maliciously set > APMC_EN to 0 (SMI_LOCK doesn't lock APMC_EN)...". It's not about feature detection -- the question (from <553F4D23.3060305@redhat.com>) is whether I should set APMC_EN myself *every time* before writing to APM_CNT, in the EFI_SMM_CONTROL2_PROTOCOL.Trigger() method. That protocol is provided by a runtime DXE driver and would be exercised by eg. the non-privileged half of the runtime variable service driver. It's no problem to set it, I have the code ready, I was just wondering if I should keep that hunk. (In fact it might not even matter: if the OS interferes and clears APMC_EN before the non-privileged half mentioned above manages to raise the SMI, then the call / transition to SMM will simply not happen, which is bad for the OS, and probably irrelevant for the firmware (... the security thereof).) I guess I'll keep re-setting APMC_EN in the Trigger() method; it won't hurt. Thanks Laszlo