From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org 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 75F4121A143EF for ; Mon, 7 Jan 2019 17:11:16 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B1313F823; Tue, 8 Jan 2019 01:11:15 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-126-62.rdu2.redhat.com [10.10.126.62]) by smtp.corp.redhat.com (Postfix) with ESMTP id EAF486012C; Tue, 8 Jan 2019 01:11:12 +0000 (UTC) To: Ard Biesheuvel , Achin Gupta Cc: Jagadeesh Ujja , "Gao, Liming" , "Kinney, Michael D" , "edk2-devel@lists.01.org" , "Zhang, Chao B" , Leif Lindholm , Supreeth Venkatesh , Jian J Wang , nd References: <1546434828-24405-1-git-send-email-jagadeesh.ujja@arm.com> <1546434828-24405-5-git-send-email-jagadeesh.ujja@arm.com> <8a6e1c80-5b6e-e337-06af-5992bc38a844@redhat.com> <20190107185012.GF14419@e104320-lin> <20190107192137.GG14419@e104320-lin> From: Laszlo Ersek Message-ID: <83efb9e7-2f69-8412-cc4d-0d602241395d@redhat.com> Date: Tue, 8 Jan 2019 02:11:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Tue, 08 Jan 2019 01:11:15 +0000 (UTC) Subject: Re: [PATCH v2 04/11] MdePkg/Include: Add StandaloneMmServicesTableLib library X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2019 01:11:16 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 01/07/19 20:37, Ard Biesheuvel wrote: > On Mon, 7 Jan 2019 at 20:21, Achin Gupta wrote: >> Could you please explain the need for End of DXE signalling and >> the traditional SMM IPL. It is not obvious to me :o( >> > > The point is that there are PI specified events that we are currently > not signalling in standalone MM, so in that sense, we are not > implementing the PI spec fully. > > Note that EndOfDxe is security sensitive - it is used as a trigger to > lock down and/or secure stuff, and if it never get signalled, > standalone MM drivers may falsely assume that the context is more > secure than it is. Yes, see PI 1.6, Vol2 ("DXE"), 5.1.2.1 "End of DXE Event". (I won't quote the spec here, as I could quote the entire section; all of it is relevant here.) In my interpretation anyway, the MM infrastructure basically "trusts" DXE until End-of-DXE is signaled. See also: - 5.6 "DXE MM Ready to Lock Protocol", - 4.6 "MM Ready to Lock Protocol", in Vol4. The kind of "early distrust" that Achin describes up-thread may be well-founded, and it might obviate the above event groups. I'm not sure. The concept is novel to me (after having struggled for months in ~2015 to wrap my brain around traditional SMM in the first place), so I'm having trouble at reasoning about standalone MM. Thanks, Laszlo