From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 18128C77B7F for ; Fri, 19 May 2023 14:07:53 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id D24BE86258; Fri, 19 May 2023 16:07:51 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=linaro.org header.i=@linaro.org header.b="rh4fG7FD"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id C4BF98466B; Fri, 19 May 2023 16:07:49 +0200 (CEST) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 4A04A8466B for ; Fri, 19 May 2023 16:07:46 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=ilias.apalodimas@linaro.org Received: by mail-wr1-x42d.google.com with SMTP id ffacd0b85a97d-30948709b3cso1467405f8f.3 for ; Fri, 19 May 2023 07:07:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1684505266; x=1687097266; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=WtriY+4gpL/zDwb9b6b8lm0QA3K3wkukixFvWjuGgR8=; b=rh4fG7FDpQeATtWmdvIspxDZz81crlbtf4hI+9Rw1xoCjFNl31p5+o72zascW3A6xt uv9Iw9O/xhfYKDTllHuOr0MDlFl9R7LsfMGTQP5LBRjBieHavkc7odoRU2PA2Ab/emac rn6hoasWG869SkNx92oIz/Zoldw1voe4hVCvkzNSQ3gj01avSVgTDLntVSp0MnAICXR/ +N2N/QWPiF4258/gtsNokwxYKV7eJtyiOvRc4HcPeEfuwx/5V4659ollnCKYT6Idrc1q a6stBH3uu2qWkY6yCiGZ/KxPrQjeD2PY4NglsC/w78rY3buNtqj9b4YieKAQrCWNc/VG 5TZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684505266; x=1687097266; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=WtriY+4gpL/zDwb9b6b8lm0QA3K3wkukixFvWjuGgR8=; b=H9ZeYravP4J9qYCYs0HH8U/aK8xfefouvJUy+IAZO0ZWwc+ODek+w7FuiWBUQr0aRy NDXkAxCC8mWX0FCI/YhZsW0+3NZXbBZby8S5oHXVenMOEys11wwXv99hdjZbY9Rj8yI/ xBfzahxJGaBtGuybHYX1SWFe1txV98MpaajK9KsQwzlRtDhC7DiGhJI6FQgUmhGm32s2 Q+V0GxG4W6YE9bHnQXEZNZTOAUd39Od/RuFu8JBCzGmHj/SmmlaaisITDLs0Ra57j5EJ kPthRIVrb3ajVm3+EFQ+I1xwaH97tTdqHhbPCwTENAD18CUP8rtbKXnoLVWRZBvPwsHu q/7Q== X-Gm-Message-State: AC+VfDxtkWWtS3N5BDIOLI/Ixv8hYaNSxtpGQd67wxmf25gh3dh+C3HS lJuA4aKVtqxfjcCdYScd3jXNWL0QDWwrbdvMoZ4= X-Google-Smtp-Source: ACHHUZ7cPkYB+jdEO1FzbimGZ+iHBQ1wvs2RHdeVlJQzOu/lKo2yV+DZBOeUiRnrnw6myPbr9jd2yw== X-Received: by 2002:adf:f784:0:b0:2ee:f77f:3d02 with SMTP id q4-20020adff784000000b002eef77f3d02mr2116351wrp.0.1684505265671; Fri, 19 May 2023 07:07:45 -0700 (PDT) Received: from hades (ppp176092130041.access.hol.gr. [176.92.130.41]) by smtp.gmail.com with ESMTPSA id g17-20020a7bc4d1000000b003f423a04016sm2531137wmk.18.2023.05.19.07.07.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 May 2023 07:07:45 -0700 (PDT) Date: Fri, 19 May 2023 17:07:43 +0300 From: Ilias Apalodimas To: Abdellatif El Khlifi Cc: u-boot@lists.denx.de, nd@arm.com Subject: Re: [PATCH v12 09/10] arm_ffa: efi: introduce FF-A MM communication Message-ID: References: <20230412094245.44674-1-abdellatif.elkhlifi@arm.com> <20230512121044.111574-1-abdellatif.elkhlifi@arm.com> <20230512121044.111574-10-abdellatif.elkhlifi@arm.com> <20230519133655.GA94049@e130802.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230519133655.GA94049@e130802.arm.com> X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.8 at phobos.denx.de X-Virus-Status: Clean On Fri, May 19, 2023 at 02:36:55PM +0100, Abdellatif El Khlifi wrote: > Hi Ilias, > > > Hi Abdellatif > > > > I still have some concerns on this > > > > In the past [0] I asking why this needs to be a Kconfig option. Since FF-A > > is a mechanism we can use to discover SPs, in theory we dont need the > > ifdefery. We might need something if the code difference grows too much > > but I think we are fine for now. > > Is my understanding correct you prefer that CONFIG_EFI_MM_COMM_TEE implies > CONFIG_ARM_FFA_TRANSPORT ? So, no ifdefs anymore in efi_variable_tee.c. I wonder what it takes to autodiscover that and get rid of all ifdefs (OPTEE and FF-A). In theory you could probe FF-A and if it's not there switch to the smc calling no? > > > > > On top of that I am nissing how was this tested? did you test the current > > SMC to optee and the stmm for the RPMB backend? > > We use Corstone-1000 platform for testing FF-A. > U-Boot communicates with smm-gateway (leight version of stmm) using FF-A SMC ABIs. > In the secure world we use TF-A, Optee OS and Trusted Services providing smm-gateway SP. > In U-Boot we don't use the Optee driver because we use FF-A communication only. > I hope this clears all doubts. Ok, but you will still need to load op-tee from BL2. My problem here is that this is a bit confusing from an architectural point of view and people need to be aware of what config options to choose, but if my understanding is correct we can automate that. Thanks /Ilias > > Cheers > Abdellatif > > > > > > +++ b/include/mm_communication.h > > > @@ -6,6 +6,9 @@ > > > * Copyright (c) 2017, Intel Corporation. All rights reserved. > > > * Copyright (C) 2020 Linaro Ltd. > > > * Copyright (C) 2020 Linaro Ltd. > > > + * Copyright 2022-2023 Arm Limited and/or its affiliates > > > + * Authors: > > > + * Abdellatif El Khlifi > > > */ > > > > > > #ifndef _MM_COMMUNICATION_H_ > > > @@ -13,6 +16,9 @@ > > > > > > #include > > > > > > +/* MM service UUID string (big-endian format). This UUID is common across all MM SPs */ > > > +#define MM_SP_UUID "33d532ed-e699-0942-c09c-a798d9cd722d" > > > + > > > /* > > > * Interface to the pseudo Trusted Application (TA), which provides a > > > * communication channel with the Standalone MM (Management Mode) > > > @@ -248,4 +254,11 @@ struct smm_variable_var_check_property { > > > u16 name[]; > > > }; > > > > > > +/* supported MM transports */ > > > +enum mm_comms_select { > > > + MM_COMMS_UNDEFINED, > > > + MM_COMMS_FFA, > > > + MM_COMMS_OPTEE > > > +}; > > > + > > > #endif /* _MM_COMMUNICATION_H_ */ > > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig > > > index c5835e6ef6..08a6b84101 100644 > > > --- a/lib/efi_loader/Kconfig > > > +++ b/lib/efi_loader/Kconfig > > > @@ -55,13 +55,23 @@ config EFI_VARIABLE_FILE_STORE > > > stored as file /ubootefi.var on the EFI system partition. > > > > > > config EFI_MM_COMM_TEE > > > - bool "UEFI variables storage service via OP-TEE" > > > - depends on OPTEE > > > + bool "UEFI variables storage service via the trusted world" > > > + depends on OPTEE || ARM_FFA_TRANSPORT > > > help > > > + Allowing access to the MM SP services (SPs such as StandAlonneMM, smm-gateway). > > > + When using the u-boot OP-TEE driver, StandAlonneMM is supported. > > > + When using the u-boot FF-A driver any MM SP is supported. > > > + > > > If OP-TEE is present and running StandAloneMM, dispatch all UEFI > > > variable related operations to that. The application will verify, > > > authenticate and store the variables on an RPMB. > > > > > > + When ARM_FFA_TRANSPORT is used, dispatch all UEFI variable related > > > + operations to the MM SP running in the secure world. > > > + A door bell mechanism is used to notify the SP when there is data in the shared > > > + MM buffer. The data is copied by u-boot to the shared buffer before issuing > > > + the door bell event. > > > + > > > config EFI_VARIABLE_NO_STORE > > > bool "Don't persist non-volatile UEFI variables" > > > help > > > diff --git a/lib/efi_loader/efi_variable_tee.c b/lib/efi_loader/efi_variable_tee.c > > > index dfef18435d..2effb705d7 100644 > > > --- a/lib/efi_loader/efi_variable_tee.c > > > +++ b/lib/efi_loader/efi_variable_tee.c > > > @@ -4,9 +4,14 @@ > > > * > > > * Copyright (C) 2019 Linaro Ltd. > > > * Copyright (C) 2019 Linaro Ltd. > > > + * Copyright 2022-2023 Arm Limited and/or its affiliates > > > + * > > > + * Authors: > > > + * Abdellatif El Khlifi > > > */ > > > > > > #include > > > +#include > > > #include > > > #include > > > #include > > > @@ -15,6 +20,36 @@ > > > #include > > > #include > > > > > > +#if IS_ENABLED(CONFIG_ARM_FFA_TRANSPORT) > > > + > > > +#include > > > +#include > > > +#include > > > + > > > +#ifndef FFA_SHARED_MM_BUFFER_SIZE > > > +#error "FFA_SHARED_MM_BUFFER_SIZE must be defined in include/configs/.h" > > > +#define FFA_SHARED_MM_BUFFER_SIZE 0 > > > +#endif > > > + > > > +#ifndef FFA_SHARED_MM_BUFFER_OFFSET > > > +#error "FFA_SHARED_MM_BUFFER_OFFSET must be defined in include/configs/.h" > > > +#define FFA_SHARED_MM_BUFFER_OFFSET 0 > > > +#endif > > > + > > > +#ifndef FFA_SHARED_MM_BUFFER_ADDR > > > +#error "FFA_SHARED_MM_BUFFER_ADDR must be defined in include/configs/.h" > > > +#define FFA_SHARED_MM_BUFFER_ADDR 0 > > > +#endif > > > + > > > +/* MM return codes */ > > > +#define MM_SUCCESS (0) > > > + > > > +static const char *mm_sp_svc_uuid = MM_SP_UUID; > > > + > > > +static u16 mm_sp_id; > > > + > > > +#endif > > > + > > > extern struct efi_var_file __efi_runtime_data *efi_var_buf; > > > static efi_uintn_t max_buffer_size; /* comm + var + func + data */ > > > static efi_uintn_t max_payload_size; /* func + data */ > > > @@ -24,6 +59,7 @@ struct mm_connection { > > > u32 session; > > > }; > > > > > > +#if (IS_ENABLED(CONFIG_OPTEE)) > > > > > /** > > > * get_connection() - Retrieve OP-TEE session for a specific UUID. > > > * > > > > [...] > > > > Isn't this problematic? At the moment there's not > 8.4 hardware out > > there. As a result the SPMC *is* implemented in OP-TEE. So how do we > > expect FF-A to work? > > > > [...] > > > > [0] https://lore.kernel.org/u-boot/Y3NV991bKRgas1zZ@hera/ > > > > Thanks > > /Ilias