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::141; helo=mail-it1-x141.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-it1-x141.google.com (mail-it1-x141.google.com [IPv6:2607:f8b0:4864:20::141]) (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 3138C211B7361 for ; Thu, 17 Jan 2019 04:18:59 -0800 (PST) Received: by mail-it1-x141.google.com with SMTP id g85so1004132ita.3 for ; Thu, 17 Jan 2019 04:18:59 -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=o743tCTHRqxdUpFNBmqwrwuMdjCo3Y9NKdl9sbQf+Pk=; b=SxaXmlGQppGrA7sOz8H4gShH1OIJ9F1M/FQd7JqyQi47pqmd8sI4UOkzXTfOCJCxNl lkQ4Qqst5v7PdqZRB7tXbKdL3fcY6aGAXSlGCfVVeE0r0quuh3CWiWn+6QohkfcKlIb6 7GHgfmUSij50Ntcc6goSUdpda0eQKKMvaLCRM= 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=o743tCTHRqxdUpFNBmqwrwuMdjCo3Y9NKdl9sbQf+Pk=; b=kkQO0v1+dzgXfgz9zJLLChUsDkwwCeGuxwXeVulobY1xDx5BVWCAgtdUI6Alrs/MBu Uidji1fNsg5okIZ/SIj8bXQF6QggmXHM7tZ3mON7okeBSdkSX0zYu+eNrcFXGVbg4brT XY/eKJeLmH6VFppC9j2TnoYo+ovNA6I3f1kv4IZJ5te6DZizx4+lWWOyzS+WbhMzdQ/F k17UFFv24EW2v44ksggVNbcRdFnz7CWmaycKvPrwIja6Kzuf7avOLVmecwn6ooji/P6h XtmLWtSe+ZYFeNKhL8Sc2JAanFI3SwLHm7UgTG9l/Hov7KiAcd+WDPz52m0rjg3jik3O S0hg== X-Gm-Message-State: AJcUukeSI45M5rZyrDphP4v+YI+o7nxC8fmnjvEiDWyc0GL816jaIq6V Vl3D0NXYTcVqr0Tn1X1fVpmJi/uJ0f2j9ziS11XR5Q== X-Google-Smtp-Source: ALg8bN55DVM7PyHjonzTaFYm8y+SVZ5cnW+G0AoU29j/vcqd9zd2KaoQFRd4sFnwU+Es1EwC3pr1zsbTLztGpve4C+s= X-Received: by 2002:a05:660c:4b:: with SMTP id p11mr8514581itk.71.1547727538302; Thu, 17 Jan 2019 04:18:58 -0800 (PST) MIME-Version: 1.0 References: <20190104144336.8941-1-ard.biesheuvel@linaro.org> <20190104144336.8941-7-ard.biesheuvel@linaro.org> <20190117110456.z22z2udhnbza3liy@bivouac.eciton.net> <20190117120817.c2kpkldlzn7zjrkg@bivouac.eciton.net> In-Reply-To: <20190117120817.c2kpkldlzn7zjrkg@bivouac.eciton.net> From: Ard Biesheuvel Date: Thu, 17 Jan 2019 13:18:46 +0100 Message-ID: To: Leif Lindholm Cc: "edk2-devel@lists.01.org" , Masahisa Kojima Subject: Re: [PATCH edk2-platforms 6/7] Platform/DeveloperBox: add .DSC/.FDF description of MM components 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: Thu, 17 Jan 2019 12:18:59 -0000 X-List-Received-Date: Thu, 17 Jan 2019 12:18:59 -0000 X-List-Received-Date: Thu, 17 Jan 2019 12:18:59 -0000 X-List-Received-Date: Thu, 17 Jan 2019 12:18:59 -0000 Content-Type: text/plain; charset="UTF-8" On Thu, 17 Jan 2019 at 13:08, Leif Lindholm wrote: > > On Thu, Jan 17, 2019 at 12:10:01PM +0100, Ard Biesheuvel wrote: > > > > ################################################################################ > > > > # > > > > @@ -294,8 +295,10 @@ [PcdsFixedAtBuild.common] > > > > !endif > > > > gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareRevision|$(BUILD_NUMBER) > > > > > > > > - gArmTokenSpaceGuid.PcdMmBufferBase|0xFFC00000 > > > > - gArmTokenSpaceGuid.PcdMmBufferSize|0x00200000 > > > > + gEfiSecurityPkgTokenSpaceGuid.PcdUserPhysicalPresence|TRUE > > > > > > So, I can see why you add this hard-wired for the purpose of testing. > > > But please, add a *very* conspicuous, and strongly worded, comment > > > statement preceding it. > > > > Well, I was talking to Peter about this the other day: according to > > the spec, this setting should only matter before exit boot services, > > and since this platform only supports serial and GOP consoles, one > > could argue that only a physically present user could interact with it > > before that time. > > But that also makes the Pcd pointless. > > > The obvious way of implementing this non-trivially on this platform is > > to use a DIP switch, but that requires you to open the case to > > enroll/delete the platform key. Perhaps that does not matter, and it > > would in fact produce a less dangerous reference implementation. > > I would be totally OK with that. > I would also be totally OK with a DynamicPcd settable through the UI > (which is what most machines I come across have). > That won't work for this implementation: the state of dynamic PCDs does not propagate into the MM world (nor should it), and so no MM driver implementing the dynamic PCD protocol exists. > But I would also be cool with a sufficiently evil "here be dragons" > statement, pointing out that we don't care that much > *on*this*specific*system* because the NOR isn't actually hw protected > anyway, and this implementation is all about exercising the software > stack.. > I'll go with that for the time being.