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 6405C211A1E30 for ; Tue, 8 Jan 2019 08:52:30 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2DBED80F8D; Tue, 8 Jan 2019 16:52:30 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-197.rdu2.redhat.com [10.10.120.197]) by smtp.corp.redhat.com (Postfix) with ESMTP id 084E65C23E; Tue, 8 Jan 2019 16:52:26 +0000 (UTC) To: Ard Biesheuvel Cc: Achin Gupta , 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> <83efb9e7-2f69-8412-cc4d-0d602241395d@redhat.com> From: Laszlo Ersek Message-ID: Date: Tue, 8 Jan 2019 17:52:25 +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.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Tue, 08 Jan 2019 16:52:30 +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 16:52:31 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 01/08/19 14:27, Ard Biesheuvel wrote: > On Tue, 8 Jan 2019 at 02:11, Laszlo Ersek wrote: >> >> 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. > > I disagree. The whole point of standalone MM is to have parity with > x86 in terms of having a separate execution context where platform > specific services can reside. Even though DXE_SMM_DRIVER and > MM_STANDALONE modules are dispatched in different ways, they should be > able to be built from a shared source, and not signalling the EndOfDxe > event is highly likely to cause more problems that it solves. > > And actually, I think it is a valid security model to distinguish > between before and after EndOfDxe, since EndOfDxe will be signalled > before loading any third-party drivers, and so whatever has executed > up to that point can be held to higher standards in terms of trust. What you describe is absolutely *easier* to understand and to agree with, so I'm naturally drawn to it. I'm just pointing out -- sort of reasoning against myself! -- that Achin wrote up-thread, > The idea behind MM Standalone mode was to sandbox MM code in self > sufficient execution context. This was a step to avoid some of the > vulnerabilities in traditional SMM due to code and data sharing with > DXE. Through this, Achin seemed to imply that some SMM vulnerabilities had occurred due to SMM being *capable* of reading *any* RAM (and MMIO too) outside of SMRAM ("data sharing"); hence invalid pointer dereferences (even just reads) could lead to really bad problems. Then, I tried to fill the term "sandbox" with meaning -- i.e. MM would be prevented from reading any DXE data (anything outside of MMRAM). This looked sort of consistent with the extra restriction that standalone MM code couldn't consume UEFI protocols even at init time. And then I extrapolated: if MM can't trust DXE *at all*, then MM needs no notification that, due to BDS reaching a specific point, MM can trust DXE even *less* than before. There is no "less" than "not at all". In short, I agree with you, I'm just trying to comprehend the "threat model" (is that the right term?) behind Achin's story (AIUI). Thanks! Laszlo >> 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. >> > > I think that applies to all of us :-) >