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=-0.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no 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 41771C19759 for ; Thu, 1 Aug 2019 08:00:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1180E206A2 for ; Thu, 1 Aug 2019 08:00:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="KyWodxvz" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730613AbfHAIAF (ORCPT ); Thu, 1 Aug 2019 04:00:05 -0400 Received: from mail-lj1-f195.google.com ([209.85.208.195]:37351 "EHLO mail-lj1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730514AbfHAIAF (ORCPT ); Thu, 1 Aug 2019 04:00:05 -0400 Received: by mail-lj1-f195.google.com with SMTP id z28so14180137ljn.4; Thu, 01 Aug 2019 01:00:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VAiKQtrdWdpAymEw2Fi6xVY10VrsZzJSh6lsPenXn5c=; b=KyWodxvzOSUl5vMHnbnrwzIAAyi2FLqjzsrJG4CDOo0xubx8uDbAyXqHvMjXb2EZKR 3OTkmSgzUW5s4OFzZOJtJzkxL2Vw9tpTOsPuHNmJL10tEdjzf6+u9Z5Dm7Ybjzo2Fsnq upL41HGVkP0Apu7kDsQGa73HXRgsYJ4eGQN4LQaCrmmTCyKiMdEQRG2WVK4rAboEaFkL GR3a+bW/b/pBTN2NDcQHelOqJxfXR1ACeiixyEc+ACqJNOoNIwLeHNt7Gkj296UvulJw dWF9aAtR4dZnfFwdJPh3B21ex1Yyr1oWQ/ZqlU8QV6eNaXvHxEZcelG2uu1GWLoxBxgQ 663w== 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=VAiKQtrdWdpAymEw2Fi6xVY10VrsZzJSh6lsPenXn5c=; b=GvMWCV/U9YOcLE4xcfMJjDR2SgtqeDGi7BJRHME7AqL7mr1ixuAmutOym0m4hpP9gI 9KJJiLh0a33oWkNvIlGJye3VJr7FaBpYMltsPF9ZuwiNyVThVc7NF9sCkmpaeL+VW8S6 JzHBjf3FlyEYnvmCpoytOs3XjGzzCn0mZtlv4yiOnhnRm9vts48kC8gObXYDu9acLLD6 pbfAi5YymPeSa+la3G9jxEYjwOe/rxKK2TfAp80/A1tUUKudy7iAtQiRqmlNFesL/EmR ZOAG9VHLTE4JURgLRx0s0RPI0IYEwJ7AaY7xTuQbEpn6wiGR9N33TA0caDofY0MQk0Gu psaA== X-Gm-Message-State: APjAAAV4H70kcD1p9bp7ucO1MXqQOHlQUUBk8sp+jH9za1IPL0ZpS3Zt FL3iuRp9YJZkNG9rqQicEvdIFpDW58lVPftCJTA= X-Google-Smtp-Source: APXvYqx/gMgcGF2V7ylKamWcGjf6XGcn5JGjdm2r9vJ2Njp1NLJnu7wpmlveYBCUT/NrzJhe5JXapFqEUKI15zJ5ClQ= X-Received: by 2002:a2e:5d92:: with SMTP id v18mr67333062lje.9.1564646402586; Thu, 01 Aug 2019 01:00:02 -0700 (PDT) MIME-Version: 1.0 References: <1564489420-677-1-git-send-email-sumit.garg@linaro.org> In-Reply-To: From: Janne Karhunen Date: Thu, 1 Aug 2019 10:59:51 +0300 Message-ID: Subject: Re: [RFC v2 0/6] Introduce TEE based Trusted Keys support To: Sumit Garg Cc: keyrings@vger.kernel.org, linux-integrity@vger.kernel.org, linux-security-module@vger.kernel.org, Jens Wiklander , Jonathan Corbet , dhowells@redhat.com, jejb@linux.ibm.com, Jarkko Sakkinen , Mimi Zohar , James Morris , "Serge E. Hallyn" , Casey Schaufler , Ard Biesheuvel , Daniel Thompson , Linux Doc Mailing List , Linux Kernel Mailing List , linux-arm-kernel , "tee-dev @ lists . linaro . org" Content-Type: text/plain; charset="UTF-8" Sender: linux-integrity-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-integrity@vger.kernel.org On Thu, Aug 1, 2019 at 10:40 AM Sumit Garg wrote: > > I chose the userspace plugin due to this, you can use userspace aids > > to provide any type of service. Use the crypto library you desire to > > do the magic you want. > > Here TEE isn't similar to a user-space crypto library. In our case TEE > is based on ARM TrustZone which only allows TEE communications to be > initiated from privileged mode. So why would you like to route > communications via user-mode (which is less secure) when we have > standardised TEE interface available in kernel? The physical access guards for reading/writing the involved critical memory are identical as far as I know? Layered security is generally a good thing, and the userspace pass actually adds a layer, so not sure which is really safer? In my case the rerouting was to done generalize it. Any type of trust source, anywhere. > > > Isn't actual purpose to have trusted keys is to protect user-space > > > from access to kernel keys in plain format? Doesn't user mode helper > > > defeat that purpose in one way or another? > > > > Not really. CPU is in the user mode while running the code, but the > > code or the secure keydata being is not available to the 'normal' > > userspace. It's like microkernel service/driver this way. The usermode > > driver is part of the kernel image and it runs on top of a invisible > > rootfs. > > Can you elaborate here with an example regarding how this user-mode > helper will securely communicate with a hardware based trust source > with other user-space processes denied access to that trust source? The other user mode processes will never see the device node to open. There is none in existence for them; it only exists in the ramfs based root for the user mode helper. -- Janne