From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) by mx.groups.io with SMTP id smtpd.web12.53190.1612277395590629483 for ; Tue, 02 Feb 2021 06:49:56 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@linaro.org header.s=google header.b=xZuwGoyq; spf=pass (domain: linaro.org, ip: 209.85.128.46, mailfrom: ilias.apalodimas@linaro.org) Received: by mail-wm1-f46.google.com with SMTP id j11so1902243wmi.3 for ; Tue, 02 Feb 2021 06:49:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=BjgGryRn8cpyRu2K7CBR28hCy/ErqPUj3oTumlKUCzg=; b=xZuwGoyq5lO55A9vFrh8wpzXGvoNZq9iAuzop/ZB37wsjeFNVlyFV4foRLJNSPOr7a eCY2Wx8iSHpOOSjHD9QjIWwQGhK0QM2QxoGekBohZfLgFaaQ8vqtceroLeANzGLK1Kl4 kE7VXEJ3oAJmjFKbCWldceenoy1jZLM2kHwc5+Nxaxk0LJJb2tLMyFVBq274bmZZck/a Dl+Gm4q1L7/6aJicFXV4UVn1AeFkMs0axD3PReQYwrn/HO6o1nP75joaoPhpzCtBkGtZ MnOhxLJ5/BT1yIrFb6iWaI4CnWD6cXQVXfa0maoSHgUoJCR3hiIOYu2YieQTeMR722ZP haKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=BjgGryRn8cpyRu2K7CBR28hCy/ErqPUj3oTumlKUCzg=; b=qtlXC6sGI2gW3zBYK9mvN3h45uhgW1fCUL3KVqKXIi0PpGx0AD65Sy3lzBFS6kV5Z2 qRJw/bey+utaxJep8ygJE4SzzNlpO1foNCZwxpQluutfjDFk9EhKy04qt+iZv3clIcED f4evIumdwhzz6tGwqWmjfrtPW8dvZkvLfOPGPF2ev3TbSq8vSVzZfyRd3MCQkBWNbCca R4U2waky9v4qCgvTMFf9vsRnz/TCEgL1ncO9gGIh/OdZ1PT9kg+p2er6HYGJ3rezboH0 COLsstWE6g36fDMebgBjifr5c0K6cuUs4yufDl8RE9zTIDHgV+yuKIYtJwkUx+bbTPJL 5Sug== X-Gm-Message-State: AOAM532MzxoxnuWiOYcf5DwyUeAWrG26i+LEJsgLWme9VQ2Nwmq6B4au yJB8TG2K2bFNu2OaODckxhbzhg== X-Google-Smtp-Source: ABdhPJyiqFGtZ8UQH35/PymfgpIM7QQnbOTe9a2gS/7LFbq8eJjZ+cnTJFGrZf4vzYXiKi6m0yLuWw== X-Received: by 2002:a1c:678a:: with SMTP id b132mr3889945wmc.35.1612277394066; Tue, 02 Feb 2021 06:49:54 -0800 (PST) Return-Path: Received: from apalos.home (athedsl-376992.home.otenet.gr. [79.131.24.158]) by smtp.gmail.com with ESMTPSA id w129sm3606508wmb.11.2021.02.02.06.49.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Feb 2021 06:49:53 -0800 (PST) Date: Tue, 2 Feb 2021 16:49:51 +0200 From: "Ilias Apalodimas" To: Sami Mujawar Cc: Sughosh Ganu , "devel@edk2.groups.io" , Ard Biesheuvel , Leif Lindholm , Sahil Malhotra , nd Subject: Re: [PATCH edk2-platforms v3 1/2] Drivers/OpTeeRpmb: Add an OP-TEE backed RPMB driver Message-ID: References: <20201216110903.17995-1-sughosh.ganu@linaro.org> <20201216110903.17995-2-sughosh.ganu@linaro.org> MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Sami, Inlining some additional info on my explanation. > > > [...] > > > I actually picked up the error handling from the previous non-FFA code. > > > I'll check what's on Sughosh latest patches and fix it if there are > > > any differences. > > > Looking at it again EFI_BAD_BUFFER_SIZE can change to indicate out of > > > memory properly anyway. > > > > > > > Had another look at this. This seems fine if I just change > > EFI_BAD_BUFFER_SIZE -> EFI OUT_OF_RESOURCES because OP-TEE is only > > using these errors from FFA. Eventually the OP-TEE code that launches > > StMM today, will move to FFA and become a separate SP, so that will > > naturally be handled once that's done. I don't see a point of adding > > unused error cases. > > > > [SAMI] Referring to the FFA specification, DEN0077A, v1.0, section 10.2 FFA_MSG_SEND_DIRECT_REQ and Table 10.8: FFA_ERROR encoding, I think the > > error codes being handled above would be returned in SvcArgs.Arg2. > > Hmm why ? > > > The message flow would be as follows: > > - Caller sends FFA_MSG_SEND_DIRECT_REQ to the target endpoint. > > - if the message does not reach the target endpoint, an error code from Table 10.8 may be returned in w2 (i.e. SvcArgs.Arg2) > > That would be in the case you have a working TF-A implementation and the > message is never dispatched to the endpoint right? > > The current driver is not implementing the whole range of that spec. The > communication between secure/non secure world is still based on the OP-TEE > messaging mechanism. > The only part that complies to the FFA spec is the communication between the > driver itself and OP-TEE. > > - If the message reaches the target endpoint, then callee shall invoke one of the following interfaces: > > * FFA_MSG_SEND_DIRECT_RESP > > So what's happening here, is that we send an SVC with ARM_SVC_ID_FFA_MSG_SEND_DIRECT_REQ_AARCH64. > The op-tee relevant code is located at ./core/arch/arm/kernel/stmm_sp.c > There's 2 things we handle right now on OP-TEE: > 1. set the page permissions, after relocating the executable. > 2. Read/Write data on our RPMB. > > In both cases service_compose_direct_resp() is used to construct the response > and that set the return value on x3. What you mention and looking for is the discovery mechanism that FFA implements. This is not part of the patches (yet) and that's the reason the driver hardcodes mMemMgrId = 3U and mStorageId = 4U. In OP-TEE side the only reason we have to fill in x2 with the error code is if the request that comes in doesn't match any of these values. But that's never the case from this driver yet, since there's no SP discovery mechanism implemented to begin with. Hope that clears it up now. Regards /Ilias > > > Regards > /Ilias > > > * FFA_INTERRUPT > > * FFA_SUCCESS > > This would mean that if the callee responds with FFA_MSG_SEND_DIRECT_RESP, the callee returned error/status code shall be in w/x3-w/x7 (which I think in this case may be in SvcArgs.Arg3). > > [/SAMI] > > > > Regards > > /Ilias