From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-170.mimecast.com (us-smtp-delivery-170.mimecast.com [63.128.21.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 703771A1E93 for ; Thu, 13 Oct 2016 16:52:37 -0700 (PDT) X-CrossPremisesHeadersFilteredBySendConnector: SCL-EXCHMB-13.phoenix.com Received: from SCL-EXCHMB-13.phoenix.com (scl-owa.phoenix.com [134.122.240.15]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-88--6qwBHwbPDSSu5JPg8RsTA-1; Thu, 13 Oct 2016 19:52:35 -0400 Received: from SCL-EXCHMB-13.phoenix.com (2607:f0dc:5001:1:f438:5eb8:75e6:cad4) by SCL-EXCHMB-13.phoenix.com (2607:f0dc:5001:1:f438:5eb8:75e6:cad4) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Thu, 13 Oct 2016 16:52:33 -0700 Received: from SCL-EXCHMB-13.phoenix.com ([fe80::fd2e:a8f8:f740:cb3b]) by SCL-EXCHMB-13.phoenix.com ([fe80::fd2e:a8f8:f740:cb3b%12]) with mapi id 15.00.1156.000; Thu, 13 Oct 2016 16:52:33 -0700 From: Ken Taylor To: "Anbazhagan, Baraneedharan" , Paolo Bonzini , Laszlo Ersek CC: "edk2-devel@lists.01.org" Thread-Topic: [edk2] SmmCommunicationCommunicate question? Thread-Index: AdIlA3HcA9E3oGk2RRupWmjny+OfugAaH+aAAAekYAAAASv2gAAGjb8g Date: Thu, 13 Oct 2016 23:52:32 +0000 Message-ID: <8662cfa11ebd43e08bac64be7562392e@SCL-EXCHMB-13.phoenix.com> References: <1c6dc322-d226-4146-e38b-5aa280659ce5@redhat.com> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [134.122.40.54] MIME-Version: 1.0 X-OrganizationHeadersPreserved: SCL-EXCHMB-13.phoenix.com X-MC-Unique: -6qwBHwbPDSSu5JPg8RsTA-1 Subject: Re: SmmCommunicationCommunicate question? X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2016 23:52:37 -0000 Content-Language: en-US Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable I think there are a couple of assumptions here that should be reconsidered.= .. First, it is not always the case that entry into SMM on one CPU will always= pull all CPUs into SMM. There are methods to deliver targeted SMIs via th= e local APIC on some processors. In addition, I have 2nd hand knowledge th= at some processors don't immediately return to SMM on RSM if other processo= rs are still in SMM; this allows some processors to resume early and contin= ue execution while execution on other cores continues in SMM. Second, CPUs are not the only bus master capable of changing the contents o= f a CommBuffer that is passed to an SMI handler. I could, for example, sch= edule a USB or a SATA transaction that will clobber CommBuffer contents som= e arbitrary amount of time after I've triggered an SMI, and CommBuffer woul= d change on the fly even if all my processors are executing known good code= in SMM. If you want your SMI handler code to be safe, as a first step, either copy = CommBuffer to a local buffer in SMM, or copy all critical parameters such a= s pointers, BARs, object lengths and commands to local variables. Operate o= nly on local copies from that point forward. Regards, -Ken. -----Original Message----- From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Anba= zhagan, Baraneedharan Sent: Thursday, October 13, 2016 6:20 AM To: Paolo Bonzini; Laszlo Ersek Cc: edk2-devel@lists.01.org Subject: Re: [edk2] SmmCommunicationCommunicate question? > From: Paolo Bonzini [mailto:paolo.bonzini@gmail.com] On Behalf Of Paolo B= onzini >=20 > On 13/10/2016 11:07, Laszlo Ersek wrote: > > > > Instead, once the first CPU enters SMM, it brings all the other CPUs > > into SMM as well, where they will be executing known, secure code -- > > i.e., the first CPU to enter SMM forces the other CPUs to temporarily > > abandon any (possibly malicious) code the runtime OS may have prepared. > > Only *then* will the verification of the communication buffer commence. > > If the malicious code managed to race the unpriv part of the service > > successfully, now the privileged part will catch that, undisturbed. >=20 > Even this is not strictly necessary if you can set aside some memory in S= MRAM for a > copy the communication buffer. Then you can do: >=20 > tmp =3D comm buffer size > if tmp > sizeof(privileged buffer) > return error > copy tmp bytes from comm buffer to privileged buffer >=20 > and not look anymore at the buffer provided by the user. >=20 > Of course, "bring all CPUs into SMM" can double as a poor man's mutex, so= there > may be reasons to do that anyway. >=20 > Paolo Am thinking in BDS phase - if a module have periodic callback and uses SmmC= ommunicate within the callback, then it could potentially overwrite those g= SmmCorePrivate pointer while another module trying to use SmmCommunicate. _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel