[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <CVG0PQ1NV1XZ.1R2BD85Z1M3FO@suppilovahvero>
Date: Mon, 11 Sep 2023 13:32:12 +0300
From: "Jarkko Sakkinen" <jarkko@...nel.org>
To: "Sumit Garg" <sumit.garg@...aro.org>
Cc: <linux-integrity@...r.kernel.org>, <keyrings@...r.kernel.org>,
"Jens Wiklander" <jens.wiklander@...aro.org>, <jejb@...ux.ibm.com>,
<zohar@...ux.ibm.com>, <sudeep.holla@....com>,
<achin.gupta@....com>, <linux-security-module@...r.kernel.org>,
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] KEYS: trusted: tee: Refactor register SHM usage
On Tue Sep 5, 2023 at 2:04 PM EEST, Sumit Garg wrote:
> Hi Jarkko,
>
> On Wed, 23 Aug 2023 at 19:58, Jens Wiklander <jens.wiklander@...aro.org> wrote:
> >
> > On Wed, Aug 23, 2023 at 3:04 PM Sumit Garg <sumit.garg@...aro.org> wrote:
> > >
> > > On Wed, 23 Aug 2023 at 13:32, Jens Wiklander <jens.wiklander@...aro.org> wrote:
> > > >
> > > > On Wed, Aug 23, 2023 at 8:55 AM Sumit Garg <sumit.garg@...aro.org> wrote:
> > > > >
> > > > > On Tue, 22 Aug 2023 at 18:25, Jens Wiklander <jens.wiklander@...aro.org> wrote:
> > > > > >
> > > > > > On Tue, Aug 22, 2023 at 04:59:33PM +0530, Sumit Garg wrote:
> > > > > > > The OP-TEE driver using the old SMC based ABI permits overlapping shared
> > > > > > > buffers, but with the new FF-A based ABI each physical page may only
> > > > > > > be registered once.
> > > > > > >
> > > > > > > As the key and blob buffer are allocated adjancently, there is no need
> > > > > > > for redundant register shared memory invocation. Also, it is incompatibile
> > > > > > > with FF-A based ABI limitation. So refactor register shared memory
> > > > > > > implementation to use only single invocation to register both key and blob
> > > > > > > buffers.
> > > > > > >
> > > > > > > Fixes: 4615e5a34b95 ("optee: add FF-A support")
> > > > > > > Reported-by: Jens Wiklander <jens.wiklander@...aro.org>
> > > > > > > Signed-off-by: Sumit Garg <sumit.garg@...aro.org>
> > > > > > > ---
> > > > > > > security/keys/trusted-keys/trusted_tee.c | 64 ++++++++----------------
> > > > > > > 1 file changed, 20 insertions(+), 44 deletions(-)
> > > > > > >
> > > > > > > diff --git a/security/keys/trusted-keys/trusted_tee.c b/security/keys/trusted-keys/trusted_tee.c
> > > > > > > index ac3e270ade69..aa3d477de6db 100644
> > > > > > > --- a/security/keys/trusted-keys/trusted_tee.c
> > > > > > > +++ b/security/keys/trusted-keys/trusted_tee.c
> > > > > > > @@ -65,24 +65,16 @@ static int trusted_tee_seal(struct trusted_key_payload *p, char *datablob)
> > > > > > > int ret;
> > > > > > > struct tee_ioctl_invoke_arg inv_arg;
> > > > > > > struct tee_param param[4];
> > > > > > > - struct tee_shm *reg_shm_in = NULL, *reg_shm_out = NULL;
> > > > > > > + struct tee_shm *reg_shm = NULL;
> > > > > > >
> > > > > > > memset(&inv_arg, 0, sizeof(inv_arg));
> > > > > > > memset(¶m, 0, sizeof(param));
> > > > > > >
> > > > > > > - reg_shm_in = tee_shm_register_kernel_buf(pvt_data.ctx, p->key,
> > > > > > > - p->key_len);
> > > > > > > - if (IS_ERR(reg_shm_in)) {
> > > > > > > - dev_err(pvt_data.dev, "key shm register failed\n");
> > > > > > > - return PTR_ERR(reg_shm_in);
> > > > > > > - }
> > > > > > > -
> > > > > > > - reg_shm_out = tee_shm_register_kernel_buf(pvt_data.ctx, p->blob,
> > > > > > > - sizeof(p->blob));
> > > > > > > - if (IS_ERR(reg_shm_out)) {
> > > > > > > - dev_err(pvt_data.dev, "blob shm register failed\n");
> > > > > > > - ret = PTR_ERR(reg_shm_out);
> > > > > > > - goto out;
> > > > > > > + reg_shm = tee_shm_register_kernel_buf(pvt_data.ctx, p->key,
> > > > > > > + sizeof(p->key) + sizeof(p->blob));
> > > > > >
> > > > > > This is somewhat fragile. What if struct trusted_key_payload has a small
> > > > > > unexpected change in layout?
> > > > >
> > > > > key and blob buffers are just two adjacent fixed sized byte arrays. So
> > > > > I am not worried here as long as they stay adjacent (which has been
> > > > > the case since trusted keys were introduced in the kernel).
> > > >
> > > > Yeah, that was my point, but fine if you don't believe it's an issue.
> > > >
> > >
> > > Does it resolve the issue with FFA ABI for you? It would be good to
> > > have your Tested-by tag.
> >
> > It does:
> > Tested-by: Jens Wiklander <jens.wiklander@...aro.org>
> > Reviewed-by: Jens Wiklander <jens.wiklander@...aro.org>
> >
>
> Can you help pick up this fix for v6.6 kernel release?
I pushed it and also added the missing stable tag:
commit 1037d6ec29cdfaaec5277c194b0278eb0a30c3f8 (HEAD -> master, origin/master, origin/HEAD)
Author: Sumit Garg <sumit.garg@...aro.org>
Date: Tue Aug 22 16:59:33 2023 +0530
KEYS: trusted: tee: Refactor register SHM usage
The OP-TEE driver using the old SMC based ABI permits overlapping shared
buffers, but with the new FF-A based ABI each physical page may only
be registered once.
As the key and blob buffer are allocated adjancently, there is no need
for redundant register shared memory invocation. Also, it is incompatibile
with FF-A based ABI limitation. So refactor register shared memory
implementation to use only single invocation to register both key and blob
buffers.
[jarkko: Added cc to stable.]
Cc: stable@...r.kernel.org # v5.16+
Fixes: 4615e5a34b95 ("optee: add FF-A support")
Reported-by: Jens Wiklander <jens.wiklander@...aro.org>
Signed-off-by: Sumit Garg <sumit.garg@...aro.org>
Tested-by: Jens Wiklander <jens.wiklander@...aro.org>
Reviewed-by: Jens Wiklander <jens.wiklander@...aro.org>
Signed-off-by: Jarkko Sakkinen <jarkko@...nel.org>
BR, Jarkko
Powered by blists - more mailing lists