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 X-Spam-Level: X-Spam-Status: No, score=-11.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C2098C7618B for ; Mon, 29 Jul 2019 07:09:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 84C21206BA for ; Mon, 29 Jul 2019 07:09:12 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="dW1tFk4j" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726678AbfG2HJL (ORCPT ); Mon, 29 Jul 2019 03:09:11 -0400 Received: from mail-io1-f65.google.com ([209.85.166.65]:35901 "EHLO mail-io1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725957AbfG2HJK (ORCPT ); Mon, 29 Jul 2019 03:09:10 -0400 Received: by mail-io1-f65.google.com with SMTP id o9so14154678iom.3 for ; Mon, 29 Jul 2019 00:09:10 -0700 (PDT) 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=VUdf5YnKpAJwylxl/ycwhJ4KC3kGMhohvJ8eC68Wkak=; b=dW1tFk4jEtVlXfgeb3SHVVbL78P7kmDnXs/6cBlP5NoogRImJw72mLK3rJ50mB13Tz 75I84NhCw7Rufe6pGZLxmDGJXZvDT9AImVTyTLIBueDJb1Fsx5/IbxpYrEssvWsPbsLS zNF6DsHTnfgab8E7fzAMT5mi1LbNAvs/N4MbtfUzIdhck8gSe5U+IhTR2uuAwWYhFbx8 z3nz7LYMoUlxDoPZa4+M9ksh+KmF4Yat5qslLoRA71UyibFTXRIDVZPHgUZ0gYGnSA0B xUpSWYdlvQKAlZDVsBwuVah0jG6Ot6RsJLbpnUe4TH4RWbMxydx7X4qYTkOf6omvvijg Nj+w== 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=VUdf5YnKpAJwylxl/ycwhJ4KC3kGMhohvJ8eC68Wkak=; b=jNzTbx/M4wxMBqkWpJta3QVMRlz9jlsiL0zCEy6s/yHt937nlM4mDMK0kqYLTvOSz3 MzxUCdHW8ggfOdWigCNB0sUisNkNyli7RYf8/2I+zDQOrqlM+fE68oStZDT6ZIZrAqTq JwNZBgsV/oqw9NGWPyaMvMBpI9Bsw6548QElKBQe6+cXenxDZLa3Qi1n2xpiOI935zsL Sujk/pnc9NuHZYmjmGOVzquzyq5UAI48OU9Bkzj9S0pVM8hRKVsMLgkxp58Tw5prw8h1 FUuZiHpYqbnyaevkWbj1bLyRwgJSfsoxlaZ1LIseAKGuMkbyVnfF+Oi5EIQwRaFlfB/5 92mA== X-Gm-Message-State: APjAAAW5X84aBS3raXjV7SKy4XlvVHC2q7AJ8AJdTJGsl07bScH/NsVw wHqbcpPEf79YedjWMvEiweWpx9opD1+uTc8ziVm3vw== X-Google-Smtp-Source: APXvYqxfyLRG2NB8NA6t2hptMHKLx1/S6kETRqPNP50e41r75/fCTH+7913CQDbpvLvodTcgaUntXV0H/NiJXLo2GsY= X-Received: by 2002:a6b:c9d8:: with SMTP id z207mr96480501iof.184.1564384149745; Mon, 29 Jul 2019 00:09:09 -0700 (PDT) MIME-Version: 1.0 References: <1560421833-27414-1-git-send-email-sumit.garg@linaro.org> <1560421833-27414-4-git-send-email-sumit.garg@linaro.org> <20190708153908.GA28253@jax> <20190709070354.GA5791@jax> In-Reply-To: From: Jens Wiklander Date: Mon, 29 Jul 2019 09:08:58 +0200 Message-ID: Subject: Re: [RFC 3/7] tee: add private login method for kernel clients To: Sumit Garg Cc: keyrings@vger.kernel.org, linux-integrity@vger.kernel.org, linux-security-module@vger.kernel.org, Jonathan Corbet , dhowells@redhat.com, jejb@linux.ibm.com, Jarkko Sakkinen , Mimi Zohar , jmorris@namei.org, serge@hallyn.com, Ard Biesheuvel , Daniel Thompson , Linux Doc Mailing List , Linux Kernel Mailing List , "tee-dev @ lists . linaro . org" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Sumit, On Tue, Jul 9, 2019 at 11:36 AM Sumit Garg wrote: > > On Tue, 9 Jul 2019 at 12:33, Jens Wiklander wrote: > > > > On Tue, Jul 09, 2019 at 11:26:19AM +0530, Sumit Garg wrote: > > > Thanks Jens for your comments. > > > > > > On Mon, 8 Jul 2019 at 21:09, Jens Wiklander wrote: > > > > > > > > Hi Sumit, > > > > > > > > On Thu, Jun 13, 2019 at 04:00:29PM +0530, Sumit Garg wrote: > > > > > There are use-cases where user-space shouldn't be allowed to communicate > > > > > directly with a TEE device which is dedicated to provide a specific > > > > > service for a kernel client. So add a private login method for kernel > > > > > clients and disallow user-space to open-session using this login method. > > > > > > > > > > Signed-off-by: Sumit Garg > > > > > --- > > > > > drivers/tee/tee_core.c | 6 ++++++ > > > > > include/uapi/linux/tee.h | 2 ++ > > > > > 2 files changed, 8 insertions(+) > > > > > > > > > > diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c > > > > > index 0f16d9f..4581bd1 100644 > > > > > --- a/drivers/tee/tee_core.c > > > > > +++ b/drivers/tee/tee_core.c > > > > > @@ -334,6 +334,12 @@ static int tee_ioctl_open_session(struct tee_context *ctx, > > > > > goto out; > > > > > } > > > > > > > > > > + if (arg.clnt_login == TEE_IOCTL_LOGIN_REE_KERNEL) { > > > > TEE_IOCTL_LOGIN_REE_KERNEL is defined as 0x80000000 which is in the > > > > range specified and implementation defined by the GP spec. I wonder if > > > > we shouldn't filter the entire implementation defined range instead of > > > > just this value. > > > > > > Agree. Will rather check for entire implementation defined range: > > > 0x80000000 - 0xFFFFFFFF. > > > > > I had a second thought on this. It would be more restrictive for > user-space TEE client library which may need to use implementation > defined login method. So either we could define specific ranges for > kernel and user-space or we can start with single login method > reserved for kernel. I think we should reserve a range for kernel internal use. Only reserving a single single login for kernel could force us to restrict the API once more later, better to take a chunk now and be done with it. Half of 0x80000000 - 0xFFFFFFFF is probably more than enough too to leave a range for user space too. > > > > > > > > > > + pr_err("login method not allowed for user-space client\n"); > > > > pr_debug(), if it's needed at all. > > > > > > > > > > Ok will use pr_debug() instead. > > > > > > > > + rc = -EPERM; > > > > > + goto out; > > > > > + } > > > > > + > > > > > rc = ctx->teedev->desc->ops->open_session(ctx, &arg, params); > > > > > if (rc) > > > > > goto out; > > > > > diff --git a/include/uapi/linux/tee.h b/include/uapi/linux/tee.h > > > > > index 4b9eb06..f33c69c 100644 > > > > > --- a/include/uapi/linux/tee.h > > > > > +++ b/include/uapi/linux/tee.h > > > > > @@ -172,6 +172,8 @@ struct tee_ioctl_buf_data { > > > > > #define TEE_IOCTL_LOGIN_APPLICATION 4 > > > > > #define TEE_IOCTL_LOGIN_USER_APPLICATION 5 > > > > > #define TEE_IOCTL_LOGIN_GROUP_APPLICATION 6 > > > > > +/* Private login method for REE kernel clients */ > > > > It's worth noting that this is filtered by the TEE framework, compared > > > > to everything else which is treated opaquely. > > > > > > > > > > IIUC, you are referring to login filter in optee_os. Change to prevent > > > filter for this login method is part of this PR [1]. > > > > > > [1] https://github.com/OP-TEE/optee_os/pull/3082 > > > > No, I was referring to the changes in tee_ioctl_open_session() above. > > It's relevant for user space to know since it will be prevented from > > using that range of login identifiers. > > Ok, so you mean to extend the comment here for user-space to know that > this login method/range is filtered by the TEE framework. Will do > that. > > > This will restrict the user space > > API, but I think the risk of breakage is minimal as OP-TEE is the only > > in-tree driver registering in the TEE framework. I'm not aware of any > > out-of-tree drivers registering. > > I am not sure if I follow you here. How do you expect this change to > break out-of-tree TEE driver registration? It's a change in common code that put restrictions on the API. Thanks, Jens > > -Sumit > > > > > Thanks, > > Jens > > > > > > > > -Sumit > > > > > > > > +#define TEE_IOCTL_LOGIN_REE_KERNEL 0x80000000 > > > > > > > > > > /** > > > > > * struct tee_ioctl_param - parameter > > > > > -- > > > > > 2.7.4 > > > > > > > > > > > > > Thanks, > > > > Jens