From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4864:20::d41; helo=mail-io1-xd41.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-io1-xd41.google.com (mail-io1-xd41.google.com [IPv6:2607:f8b0:4864:20::d41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 9FC51211ADA2E for ; Tue, 8 Jan 2019 05:27:47 -0800 (PST) Received: by mail-io1-xd41.google.com with SMTP id t24so3121689ioi.0 for ; Tue, 08 Jan 2019 05:27:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HS8k/xeGZCFT39B0EMi5JzV8Il91iDqF/mtG2ZQS+Pc=; b=DNhdfuScq6RgN/Q8BxQXwmb9zWbAa633mz8t7gxSUZtvjom4GwOp4OoxwGKCj/WaOR fkBA/Iqj16F/mrq/H7XcaI4uqtayW068EoEJ9dn2V9GdjFLmoh9jEpzLvrYx4C7AHf/o RvWQn0TXeK23VoZrlqHbz4R9TpooBRFKFeSrI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HS8k/xeGZCFT39B0EMi5JzV8Il91iDqF/mtG2ZQS+Pc=; b=VARcJ5Z4g+3rIax1wg/nJETot4BoCFCqqTsivC0TDwY2GeuMclzZ37h9IFltfXa3lC i0LyHWdNEOGRzGtp2dnI53y+k5kNdxJTdcYgvheFpVm45DE53lZwDu1jkzM4DqDormdc AFO25EASkUwD4Rya5l43u1Mcu97LQXPR+4hKkcU6/7Dd7LyXJORhDAPAg4HIjt+U5rA1 dPtqkfvPbSdMddhkkYYCAQP/XLeVzKvIn5bOC66RnwUkXjWr0V61sm59K6l4GjdBHtPA baviK27z1j2magdfWkO8AqOM8OiSPRb3vHVOYgqRd+WDCDeSOWTakHDlbLtyvoyGcYrS tDxw== X-Gm-Message-State: AJcUukchuE5N59RH7WqC/isj2UDx4JeXG3XNke1i6pWEjWYpoNqeaLVA RXFJZyWTZyP+gg/N1ihHintsIcRKFRK3LbNIijI8ew== X-Google-Smtp-Source: ALg8bN4d9IsM/0j2i87Rvp1WJOoXayEX7lN8tt3AC1zWLvIH6+VT3OpnJLd2aPEhqePTiArAW6hReRAP0tMo8R1EU6o= X-Received: by 2002:a5e:c206:: with SMTP id v6mr1088281iop.60.1546954066575; Tue, 08 Jan 2019 05:27:46 -0800 (PST) MIME-Version: 1.0 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> In-Reply-To: <83efb9e7-2f69-8412-cc4d-0d602241395d@redhat.com> From: Ard Biesheuvel Date: Tue, 8 Jan 2019 14:27:35 +0100 Message-ID: To: Laszlo Ersek 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 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 13:27:47 -0000 Content-Type: text/plain; charset="UTF-8" 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. > 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 :-)