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 AC88A1A1DF5 for ; Thu, 13 Oct 2016 02:07:51 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (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 3EC503B716; Thu, 13 Oct 2016 09:07:51 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-52.phx2.redhat.com [10.3.116.52]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9D97ogX012183; Thu, 13 Oct 2016 05:07:50 -0400 To: "Anbazhagan, Baraneedharan" References: From: Laszlo Ersek Cc: "edk2-devel@lists.01.org" Message-ID: Date: Thu, 13 Oct 2016 11:07:49 +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: X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Thu, 13 Oct 2016 09:07:51 +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: Thu, 13 Oct 2016 09:07:51 -0000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 10/13/16 05:40, Anbazhagan, Baraneedharan wrote: > Whether TPL needs to be raised before setting CommunicationBuffer and > BufferSize in gSmmCorePrivate to avoid a callback overwriting those > values before triggering SW SMI? I don't think so. The contents of the communication buffer is untrusted (it is passed in from the unprivileged side to the privileged side), so the SMI handler (running in SMM) has to do full validation / verification anyway. Another way to look at this is the following: assume that the runtime OS calls a variable service on one processor. That variable service has an unprivileged part (which formats the request in the communication buffer, and triggers the SMI), and a privileged part (the code that validates and serves the request in SMM). Now assume that the runtime OS deliberately races, on another processor, with the unpriv variable service code that runs on the first processor; i.e., the second CPU tries to tamper with the communication buffer just in the time window that you describe. There's nothing that the unpriv variable code running on the first processor can do against this. 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. Thanks Laszlo