From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yb1-f179.google.com (mail-yb1-f179.google.com [209.85.219.179]) by mx.groups.io with SMTP id smtpd.web10.54769.1612283286522517642 for ; Tue, 02 Feb 2021 08:28:06 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@linaro.org header.s=google header.b=rO31IUVY; spf=pass (domain: linaro.org, ip: 209.85.219.179, mailfrom: ilias.apalodimas@linaro.org) Received: by mail-yb1-f179.google.com with SMTP id i71so7460670ybg.7 for ; Tue, 02 Feb 2021 08:28:06 -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=8QE7luvyzE8gX7hSgAXx9z3nMimUx7Ry4ixbrSy6z+I=; b=rO31IUVY+iChoozcRugBQK3FkSsa8L3UVX7QYjKr0bdLjoijRk7Ulo5tZ/XFBBQ7ak kH7g94B7j65ru8JuJuOTRnYYOjVI01W5l4BGjNgojB+iloQhAGZvRtr1f7yVgpZd+MjR MWZT09NXuInqHiMivewCnLM4d1QxuQVCskjFXOsK+EVvWmCMNjhX2DDLpEswNjyntA4z 5xXUNl0Vw26foMHbPhAy7rBg5tNqvVPHyf7p//XqYVm1hXrxYQFMUznpCgm+qxQ8M/zT ghuoSVMqzYRWRM+V32Ddz2x4TdaGzi0r59lR+MAX+1unfbJe0xkx7lp7A2RRameZX+f2 8DYA== 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=8QE7luvyzE8gX7hSgAXx9z3nMimUx7Ry4ixbrSy6z+I=; b=TUfgVd7WcTpbMqmOu48JK0SGPATtpIABz07eXa1lEKIMcAER1nn8y6HoxZrpX9WGu3 TpNNsNTeT72ijUaLSvh+9mdehyjo5S7oix/8n+VhkHz4m4xquZWU8YHLiLmAjFtue+KE GqPdc0TGT1YzRx9ABendNbrir/Dg8/5jQ3iCdvnvJlysUjnmVMEwfq59+ugipjTfSWIJ ij0Chh52Mi68LxbXX2Nb2PR2vWpJQIIsTMfiyARLr9rqFyXq5oketUJFJHQVSSveioSB oso0vcE4wtj4NjQsOY1EvW+MsdBeG+x9veEaGsZcJVsKN+yXSkiFXU1J1mPPyRhJ0MyF 7ssA== X-Gm-Message-State: AOAM531l85tvYe/x7eb0AP74v2lDfuK+x8SEdQsIGtfPaxgZk3n4MR12 HUMPUHTwETsp3I8SooR+HE40BSvGATxIYa8QRAqSQg== X-Google-Smtp-Source: ABdhPJygv610Z8RMqx9gTuTupRchP/iOSl4LM85AlTu+rdYkZdaesdAgNo3TELo/CIBZL34SqYpOSPc6IdcvbwpYeHY= X-Received: by 2002:a25:8311:: with SMTP id s17mr16396277ybk.259.1612283285689; Tue, 02 Feb 2021 08:28:05 -0800 (PST) MIME-Version: 1.0 References: <20201216110903.17995-1-sughosh.ganu@linaro.org> <20201216110903.17995-2-sughosh.ganu@linaro.org> In-Reply-To: From: "Ilias Apalodimas" Date: Tue, 2 Feb 2021 18:27:29 +0200 Message-ID: Subject: Re: [PATCH edk2-platforms v3 1/2] Drivers/OpTeeRpmb: Add an OP-TEE backed RPMB driver To: Sami Mujawar Cc: Sughosh Ganu , "devel@edk2.groups.io" , Ard Biesheuvel , Leif Lindholm , Sahil Malhotra , nd Content-Type: text/plain; charset="UTF-8" Hi Sami, On Tue, 2 Feb 2021 at 17:13, Sami Mujawar wrote: > > Hi Ilias, > > Please see my response inline marked [SAMI]. > > Regards, > > Sami Mujawar > > -----Original Message----- > From: Ilias Apalodimas > Sent: 02 February 2021 02:50 PM > 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 > > 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 ? > [SAMI] This is for the case where the FFA_MSG_SEND_DIRECT_REQ does not reach the target endpoint. > [/SAMI] > > > > > 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? > [SAMI] Yes [/SAMI] > > > > 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. > > [SAMI] Thank you for the explanation. It makes sense. I think a comment describing this rationale would be helpful for someone trying to understand the code. > [/SAMI] That's a good idea. I'll add it just before the hardcoded values for storage and memory IDs. We need to keep in mind that this is evolving work and some things will change once the majority of FFA has been implemented. The architecture will be similar, we'll just have to account for dynamic discovery and memory sharing between secure partitions. Unfortunately this has many moving pieces at the moment, so we might as well make the reading easier. > > 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