From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by mx.groups.io with SMTP id smtpd.web11.31033.1673459155381129256 for ; Wed, 11 Jan 2023 09:45:55 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=ed7CDWnf; spf=pass (domain: kernel.org, ip: 139.178.84.217, mailfrom: ardb@kernel.org) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id A944361DB4 for ; Wed, 11 Jan 2023 17:45:54 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C6DF3C43398 for ; Wed, 11 Jan 2023 17:45:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1673459152; bh=BNXo0gqNXPwYmhORFQ1HERLfre4dwuduEVcPjED5zjE=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=ed7CDWnf7pkTIWLY73Y8UTc16StIPBA844BWqeTOT17ZFxbc664C0q1wtN6Mb/5HC qfqZgo2TbTdzlmK9owa7E77Av+l6JXmkSPnZr6lJcMgNaMW62ehAscU5nBGyRyklDk TmHg0ouT4Ps9jrXZW5n+E0T/oCw9VBXO0DG15n9oGg+wol21tH9jG75GR2deXYlqOC WhspnPbCCErD/2Qhm2bYlrBZ//c3hrzhIUBdXa1LGMcH/KW1kvuHzSAf1rRThqLsO4 kIL3d1UHM/3ZcX+m3qG0PY1B4TjmmKkMSoGgg67DlEzi5w2uFunMdnF/mJvCafNx7m RWKpMQXhu7XcQ== Received: by mail-lf1-f43.google.com with SMTP id m6so24675562lfj.11 for ; Wed, 11 Jan 2023 09:45:52 -0800 (PST) X-Gm-Message-State: AFqh2kqf/F6hyXWsGdRdVouEdnSYnkpiRjzdBCAZKiYQcleetasx54gv Foo/611wASDuWEtQ32SgNiOWg2FKKgFgVpc5pQs= X-Google-Smtp-Source: AMrXdXvUjWCra3rSajqWXnucCE87rrctV62kWQWZcP54Konr82VTznDmFjeSYFK2ASyWcROcAs6JJzJt4JzlQubGzC0= X-Received: by 2002:a05:6512:3d93:b0:4b8:9001:a694 with SMTP id k19-20020a0565123d9300b004b89001a694mr3537959lfv.426.1673459150564; Wed, 11 Jan 2023 09:45:50 -0800 (PST) MIME-Version: 1.0 References: <20221110134738.3798618-1-ardb@kernel.org> <20221110134738.3798618-3-ardb@kernel.org> In-Reply-To: From: "Ard Biesheuvel" Date: Wed, 11 Jan 2023 18:45:39 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [PATCH 2/3] ArmVirtPkg/ArmVirtQemu: Expose TRNG hypercall via RngDxe if implemented To: devel@edk2.groups.io, pierre.gondois@arm.com Cc: Liming Gao , Rebecca Cran , Leif Lindholm , Sami Mujawar , Gerd Hoffmann , "Jason A . Donenfeld" Content-Type: text/plain; charset="UTF-8" On Wed, 11 Jan 2023 at 18:38, PierreGondois wrote: > > > > On 1/11/23 17:49, Ard Biesheuvel wrote: > > On Fri, 18 Nov 2022 at 17:48, PierreGondois wrote: > >> > >> Hello Ard, > >> > >> On 11/10/22 14:47, Ard Biesheuvel wrote: > >>> Currently, we only expose the EFI_RNG_PROTOCOL in ArmVirtQemu if QEMU > >>> provides a virtio-rng device, and it doesn't do so by default. > >>> > >>> Given that KVM exposes the ARM architected TRNG service (and has done so > >>> for a while now), let's incorporate the RngDxe driver which has recently > >>> grown support for the ARM firmware/hypervisor service. > >>> > >>> If both the service and the virtio device are available, two > >>> implementations of the RNG protocol will be exposed, but this is fine: > >>> callers that don't care about the distinction will grab the first one > >>> available. > >>> > >>> Signed-off-by: Ard Biesheuvel > >>> --- > >>> ArmVirtPkg/ArmVirtQemu.dsc | 11 +++++++++++ > >>> ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc | 5 +++++ > >>> ArmVirtPkg/ArmVirtQemuKernel.dsc | 11 +++++++++++ > >>> 3 files changed, 27 insertions(+) > >>> > >>> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc > >>> index f77443229e8e..1771ad562225 100644 > >>> --- a/ArmVirtPkg/ArmVirtQemu.dsc > >>> +++ b/ArmVirtPkg/ArmVirtQemu.dsc > >>> @@ -140,6 +140,8 @@ [PcdsFeatureFlag.common] > >>> > >>> gArmVirtTokenSpaceGuid.PcdTpm2SupportEnabled|$(TPM2_ENABLE) > >>> > >>> + gArmTokenSpaceGuid.PcdMonitorConduitHvc|TRUE > >>> + > >> > >> It seems that the PSCI conduit needs to be dynamically set. > > > > Why? And how is this different from PSCI for resetting the system? > > The PSCI implementation used for ArmVirtQemu is parsing the conduit > to use, so it can handle both cases: > https://github.com/tianocore/edk2/blob/fe405f08a09e9f2306c72aa23d8edfbcfaa23bff/ArmVirtPkg/Library/ArmVirtPsciResetSystemLib/ArmVirtPsciResetSystemLib.c#L49 > Hmm, that is a fair point. I wonder if we should simply detect whether we are executing at EL1 or EL2, and use HVC or SVC respectively. > > > > Note that ArmVIrtQemu was never intended to run at EL2, even if it > > seems to work to some extent. > > Ok understood. > > > > > > >> The psci conduit that should be used is configured by qemu depending on the > >> virtualization=[on|off] parameter. When off, HVC must be used (SMC otherwise). > >> Cf: > >> https://github.com/qemu/qemu/blob/master/hw/arm/virt.c#L2052 > > (replacing with a permanent link) > https://github.com/qemu/qemu/blob/aa96ab7c9df59c615ca82b49c9062819e0a1c287/hw/arm/virt.c#L2080 > > >> > >> If using the wrong conduit, qemu traps the instruction and stops. > >> For KvmTool, the conduit is always HVC. > >> > >> Command used: > >> [PATH_TO]/qemu/build/qemu-system-aarch64 \ > >> -serial stdio -M virt,highmem=on,virtualization=off \ > >> -cpu cortex-a57 -smp 4 -m 4096 \ > >> -drive file=pflash0.img,format=raw,if=pflash,readonly=on \ > >> -drive file=pflash1.img,format=raw,if=pflash > >> > >> Regards, > >> Pierre > >> > >> > >> > >> > >> > > > > >