From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 550DB1A1EC4 for ; Fri, 14 Oct 2016 05:37:02 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id CBE16635D7; Fri, 14 Oct 2016 12:37:01 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-51.phx2.redhat.com [10.3.116.51]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9ECawdg009457; Fri, 14 Oct 2016 08:36:59 -0400 To: Ken Taylor , "Anbazhagan, Baraneedharan" , Paolo Bonzini References: <1c6dc322-d226-4146-e38b-5aa280659ce5@redhat.com> <8662cfa11ebd43e08bac64be7562392e@SCL-EXCHMB-13.phoenix.com> Cc: "edk2-devel@lists.01.org" From: Laszlo Ersek Message-ID: <1e38e993-ff95-b4c7-534d-a0a77755aac7@redhat.com> Date: Fri, 14 Oct 2016 14:36:58 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <8662cfa11ebd43e08bac64be7562392e@SCL-EXCHMB-13.phoenix.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Fri, 14 Oct 2016 12:37:01 +0000 (UTC) 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: Fri, 14 Oct 2016 12:37:02 -0000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 10/14/16 01:52, Ken Taylor wrote: > 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 the local APIC on some processors. In addition, I have 2nd > hand knowledge that some processors don't immediately return to SMM > on RSM if other processors are still in SMM; this allows some > processors to resume early and continue execution while execution on > other cores continues in SMM. > > Second, CPUs are not the only bus master capable of changing the > contents of a CommBuffer that is passed to an SMI handler. I could, > for example, schedule a USB or a SATA transaction that will clobber > CommBuffer contents some arbitrary amount of time after I've > triggered an SMI, and CommBuffer would 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 as pointers, BARs, object lengths and commands to > local variables. Operate only on local copies from that point > forward. Good points, thank you! (Practically elaborating on what Paolo said as well.) I completely missed PCI DMA here. Thanks! Laszlo > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Anbazhagan, 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 Bonzini >> >> 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. >> >> Even this is not strictly necessary if you can set aside some memory in SMRAM for a >> copy the communication buffer. Then you can do: >> >> tmp = comm buffer size >> if tmp > sizeof(privileged buffer) >> return error >> copy tmp bytes from comm buffer to privileged buffer >> >> and not look anymore at the buffer provided by the user. >> >> Of course, "bring all CPUs into SMM" can double as a poor man's mutex, so there >> may be reasons to do that anyway. >> >> Paolo > > Am thinking in BDS phase - if a module have periodic callback and uses SmmCommunicate within the callback, then it could potentially overwrite those gSmmCorePrivate 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 > > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel >