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 3C093C77B7F for ; Fri, 19 May 2023 12:56:13 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 5C20F86266; Fri, 19 May 2023 14:56:11 +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="sXEypN7Q"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id DA2EA862DA; Fri, 19 May 2023 14:56:09 +0200 (CEST) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 59736862F7 for ; Fri, 19 May 2023 14:56:05 +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-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-3f41d087a84so5619075e9.1 for ; Fri, 19 May 2023 05:56:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1684500965; x=1687092965; 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=6RGhBAIi7dcRKgkhlTXqBK8Pn77eqai1wrsqMXiSlYU=; b=sXEypN7QmzQQAnkZ8ckHp/yPxeuwPJz97mmnQFNDQ+M7vTbZzsz6OQ2n7PFqaiZzuJ XqyDqWozx7SwuELMMjKAVc9ooR8dkF4/SIjPeS6a8mpx7Q2FaMY0PFe5ujWwQTTUAUNX PpKH68cRS4qDKIEQqkvx723DnILg5aDMLILuZQu3xrWjRN7SlQ5wK+hIErGEBxtYMHEN xN5NEaxwUkic5FvNeGIcE65yk+xMprDZuIp3OAFWqNU4wt3gos8y32KEmMZjpEgDoYbF Cf4VtrnBpEjVn6ySfDzpMBb+fYPCyXQ2BVQgmttR5aJlQvvoOZJoYZu8yhhXhyWNvLTs 5CjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684500965; x=1687092965; 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=6RGhBAIi7dcRKgkhlTXqBK8Pn77eqai1wrsqMXiSlYU=; b=QgGYlIu8i+JinegvEPcqYP9jdfXSoS7s7aiKKcglvPX7HtAz908n0fKAPcV55Hej/B P6QtWjX/mB/kx1KErLzAGrJVu27+VMW/PnzEokzU/3fDv0PxV5KGjxKqiiv+1mUCj4+5 4v4WlKDZoyPeRw725IU8pp+RSRVooTTAjOSkqiG+S/eCwZq8pfOv45+jeC0FqCp8lYbb S6QoShJEviKw4oxB6BTGG5m3wlTV9DRl01AR5U6LmToGmB/xGJYdO4QWxLNmRke89qcs cgAlMp3oR1tdwo0m2kHgP7U3i6GTPU+roz6cJUXBDcusQq0QLTs8FZ+0ciqSRkYZvYUw 98wQ== X-Gm-Message-State: AC+VfDwB8s6eEZ2OMYRDgVFAIov500GYaRnNkbUoIG00XqFC/sSNwHH7 L3Pke/Ly+0GQRKSany3N9cxfYQ== X-Google-Smtp-Source: ACHHUZ6swRf8QH4pgTYosm9XWEkn2w4dH2yEvubKpp0suYboYdqW0/G69sB9W+zpd5pIX+nS5j3kog== X-Received: by 2002:a05:600c:2181:b0:3f3:3cba:2f2d with SMTP id e1-20020a05600c218100b003f33cba2f2dmr1493232wme.7.1684500964662; Fri, 19 May 2023 05:56:04 -0700 (PDT) Received: from hades (ppp176092130041.access.hol.gr. [176.92.130.41]) by smtp.gmail.com with ESMTPSA id u20-20020a05600c00d400b003f42894ebe2sm2313825wmm.23.2023.05.19.05.56.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 May 2023 05:56:04 -0700 (PDT) Date: Fri, 19 May 2023 15:56:01 +0300 From: Ilias Apalodimas To: Abdellatif El Khlifi Cc: Drew.Reed@arm.com, achin.gupta@arm.com, jens.wiklander@linaro.org, nd@arm.com, robh@kernel.org, sjg@chromium.org, trini@konsulko.com, u-boot@lists.denx.de, xueliang.zhong@arm.com, Gowtham Suresh Kumar 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230512121044.111574-10-abdellatif.elkhlifi@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 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. 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? > +++ 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