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::143; helo=mail-it1-x143.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-it1-x143.google.com (mail-it1-x143.google.com [IPv6:2607:f8b0:4864:20::143]) (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 16BCF21962301 for ; Mon, 7 Jan 2019 10:55:49 -0800 (PST) Received: by mail-it1-x143.google.com with SMTP id b5so2571374iti.2 for ; Mon, 07 Jan 2019 10:55:49 -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=lEzDtVjaZRhuVPxH2l7/TFQkd87Mh1ygAfFEiMc5HEw=; b=QdZsaYgLaKzPquNkXIO0Zhw0NKL04vJFln6TqQyqUmbhur99bWpOaV7KO8nFnkMWBc wJpaTK2WUOzjIWNvfXYhYWtONUk+O6kvL6o2cdIdnjo+Wi4iYgFLq3djaYsqrd1Vu3Su amQ33K8FM610Pe4ziuxcWO6CK+RO1dQ0X6/lA= 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=lEzDtVjaZRhuVPxH2l7/TFQkd87Mh1ygAfFEiMc5HEw=; b=LzeSjCHdXDuuzCpgJt8RsW/V73Jr7ocGh0hp2aen8M7OEtMnhXN1+R6OnMUsFMhQKm jJKDKhYn9R8QB/42VetZG4JMuHWjWuyI20Ijxs81cSwVImRBotf9BrSfjsPnvB1gCujz VGf7UxQ93T+coR4qxycaViTVcIdj0OCTgFbg0FW7dR2H9nfhuo+vyzOqmMhZgLdXvq2T 573IlM/BBoUfNllrW8m8uvqxemv0/IphK1QWJlyGbKBWDuWV+mG/hTQ6eMbOLwt970DX lR4wBBcTv00uwy+cMvHRcn2gZ8mojot7yPBB94Girr9tEaTxhAzmXKRxIvGbDuKue3U5 b11g== X-Gm-Message-State: AJcUukeKuDqa2BciUZh4LLAbCEorEiQBaiUjRa5nbZFFNLWBru7Qked+ gK/0aTq3CvXf0uLh9ugxWUS4b6Czrnk/sK84XP3/kQ== X-Google-Smtp-Source: ALg8bN4npimfGUrP75+OGiXEWORRZOXHWVarkWnzvWbtJNPdJH2zgUyRwQhtvt858FJr1VpF4wwT/Mon2QuquXAIAD4= X-Received: by 2002:a05:660c:4b:: with SMTP id p11mr8308917itk.71.1546887349070; Mon, 07 Jan 2019 10:55:49 -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> In-Reply-To: <20190107185012.GF14419@e104320-lin> From: Ard Biesheuvel Date: Mon, 7 Jan 2019 19:55:36 +0100 Message-ID: To: Achin Gupta Cc: Laszlo Ersek , 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: Mon, 07 Jan 2019 18:55:50 -0000 X-List-Received-Date: Mon, 07 Jan 2019 18:55:50 -0000 X-List-Received-Date: Mon, 07 Jan 2019 18:55:50 -0000 X-List-Received-Date: Mon, 07 Jan 2019 18:55:50 -0000 X-List-Received-Date: Mon, 07 Jan 2019 18:55:50 -0000 X-List-Received-Date: Mon, 07 Jan 2019 18:55:50 -0000 X-List-Received-Date: Mon, 07 Jan 2019 18:55:50 -0000 X-List-Received-Date: Mon, 07 Jan 2019 18:55:50 -0000 X-List-Received-Date: Mon, 07 Jan 2019 18:55:50 -0000 X-List-Received-Date: Mon, 07 Jan 2019 18:55:50 -0000 X-List-Received-Date: Mon, 07 Jan 2019 18:55:50 -0000 X-List-Received-Date: Mon, 07 Jan 2019 18:55:50 -0000 X-List-Received-Date: Mon, 07 Jan 2019 18:55:50 -0000 Content-Type: text/plain; charset="UTF-8" On Mon, 7 Jan 2019 at 19:50, Achin Gupta wrote: > > On Mon, Jan 07, 2019 at 06:33:26PM +0100, Ard Biesheuvel wrote: > > On Mon, 7 Jan 2019 at 16:28, Laszlo Ersek wrote: > > > > > > On 01/04/19 12:57, Ard Biesheuvel wrote: > > > > On Thu, 3 Jan 2019 at 17:14, Laszlo Ersek wrote: > > > >> > > > >> On 01/03/19 12:03, Ard Biesheuvel wrote: > > > >>> On Wed, 2 Jan 2019 at 14:14, Jagadeesh Ujja wrote: > > > >>>> > > > >>>> Some of the existing DXE drivers can be refactored to execute within > > > >>>> the Standalone MM execution environment as well. Allow such drivers to > > > >>>> get access to the Standalone MM services tables. > > > >>>> > > > >>>> Add a mechanism to determine the execution mode is required. > > > >>>> i.e, in MM or non-MM > > > >>>> > > > >>>> Contributed-under: TianoCore Contribution Agreement 1.1 > > > >>>> Signed-off-by: Jagadeesh Ujja > > > >>>> --- > > > >>>> MdePkg/Include/Library/StandaloneMmServicesTableLib.h | 43 ++++++++++++++++++++ > > > >>>> MdePkg/Library/StandaloneMmServicesTableLib/StandaloneMmServicesTableLib.c | 39 ++++++++++++++++++ > > > >>>> MdePkg/Library/StandaloneMmServicesTableLib/StandaloneMmServicesTableLib.inf | 36 ++++++++++++++++ > > > >>>> MdePkg/MdePkg.dec | 4 ++ > > > >>>> 4 files changed, 122 insertions(+) > > > >>>> > > > >>> > > > >>> OK, so since the PI spec only refers to MM mode now, this library > > > >>> class should be > > > >>> > > > >>> MmServicesTableLib|Include/Library/MmServicesTableLib.h > > > >>> > > > >>> with an implementation in MdeModulePkg that exposes the deprecated SMM > > > >>> system table as the MM system table. > > > >>> > > > >>> In StandaloneMmPkg, we can add an implementation that exposes the > > > >>> standalone MM system table. > > > >>> > > > >>> (They are binary compatible, so it is just a matter of casting one > > > >>> pointer to the other) > > > >>> > > > >>> With this in place, we can go ahead and update FaultTolerantWrite and > > > >>> Variable SMM driver to switch from SmmServicesTableLib to > > > >>> MmServicesTableLib. This will require existing x86 platforms to define > > > >>> a new library class resolution for MmServicesTableLib, referring to > > > >>> the implementation in MdeModulePkg. This is unfortunate, but it is an > > > >>> unavoidable consequence of the PI spec changes. > > > >> > > > >> It shouldn't be too intrusive or hard to review, I expect. > > > >> > > > >>> > > > >>> Remaining question is what to do with InSmm() ... > > > >> > > > >> I'm lacking the context on this; on the other hand, I can refer back to > > > >> at least one earlier discussion -- there had been multiple -- of the > > > >> discrepancy between the PI spec and the edk2 code. See: > > > >> > > > >> - bullet (9) in > > > >> , > > > >> - and > > > >> . > > > >> > > > >> Not sure how that can be applied to Arm. > > > >> > > > > > > > > The code I posted yesterday does not use InMm() at all. For standalone > > > > MM, it should always return TRUE anyway, and any code that a driver > > > > would execute if it returned FALSE needs to be factored out anyway, > > > > since it should not end up in standalone MM binaries as dead code. > > > > > > > > > > OK. That seems to make sense. I've read up a bit on "standalone MM" in > > > the PI v1.6 spec, vol 4. Having no access to UEFI protocols even in the > > > entry point function, at driver init time, seems challenging to me. I > > > guess I'll learn more about this as a part of the usual list traffic. > > > > > > What is the MODULE_TYPE that standalone MM drivers use, in place of > > > DXE_SMM_DRIVER (= EFI_FV_FILETYPE_MM, 0x0A)? > > > > > > Hm... from the other patches, it seems to be MM_STANDALONE (= > > > EFI_FV_FILETYPE_MM_STANDALONE, 0x0E). OK. > > > > > > If I'd like to see a short summary of standalone MM, relative to > > > traditional MM, and why it is more suitable -- I presume -- for aarch64, > > > which document should I look at, from > > > , for example? > > > > > > > Perhaps Achin can answer this, since he has been driving the spec side > > of this? (and maintains StandaloneMmPkg) > > 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. > > On AArch64, the MM standalone mode is initialised during the SEC phase. This > corresponds to Trustzone initialisation. Furthermore, the MM standalone > execution context is placed in user mode (Secure EL0) instead of running it in a > privileged processor mode (S-EL1 or EL3 on AArch64, Ring -2 or SMM on x86). This > restricts what the MM standalone context can see and do. Lastly, after SEC no > more MM Standalone drivers can be initialized during PEI or DXE (in contrast to > the example in PI 1.6 Section 1.5.2). > > Hope that makes sense? > I agree, but this is not what StandaloneMmPkg implements today: it implements a MmFvDispatchHandler that permits a FV to be brough into the MM environment, and the MM dispatcher will happily dispatch all the MM_STANDALONE modules it contains. Also, there are some other pieces missing (which I mentioned in one of the other threads but I suppose you may not have caught up yet): EndOfDxe (as well as some other PI defined events) needs to be signalled to the standalone MM context by some non-MM agent, and I think there are other parts of the traditional SMM IPL that have not been ported to standalone MM yet. > I have not seen all the patches in this and related series but the use of InMM() > to allow code to have a DXE driver or a MM Standalone driver personality seems > to defeat the entire purpose of Standalone MM. My concern is that any code that > is relevant only to DXE or PEI must not be a part of the MM Standalone > context. This could be achieved through proper refactoring + conditional > compilation. If the decision is taken at runtime then this is just traditional > MM. >