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 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 D301FC19759 for ; Thu, 1 Aug 2019 10:40:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 95672206B8 for ; Thu, 1 Aug 2019 10:40:42 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="e7zESjZM" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731060AbfHAKkl (ORCPT ); Thu, 1 Aug 2019 06:40:41 -0400 Received: from mail-lf1-f66.google.com ([209.85.167.66]:43669 "EHLO mail-lf1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725930AbfHAKkl (ORCPT ); Thu, 1 Aug 2019 06:40:41 -0400 Received: by mail-lf1-f66.google.com with SMTP id c19so49869251lfm.10; Thu, 01 Aug 2019 03:40:39 -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=isUGmEYOLpjEg3jfVYEfLLyDXZizpluoarkdQOeJEco=; b=e7zESjZM2/wzjwmiWWWbSAsTWhAV77ru/rCVx4JUymN/53sRSzBFQXud45X8Dr61zK sqmwE48x+NwYk2Cj06PSvNDR8EAL73UGkym1ZfUF++xJXuhNMPXz+ZbmblOckb2EDibR hn6TqYNEl4I925P779zb0qgrYlBYkGxknrNhHKo6jUgsDvnooc9DJ8mSJdetEzKQzfIu yGRZza/lQjKJDFIMW4HrtW4SNKRhMMEr9D67Icb79a0oMCaE2HtXRxR5M4RhrEn5SpKM a576UQfrDmvM2vsFwwi7Yxa0NJUzNBsNMxHNw41zLHW1yIPJgW5/e35MPiKmD1Qk/tSb zgFg== 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=isUGmEYOLpjEg3jfVYEfLLyDXZizpluoarkdQOeJEco=; b=ocAW3vNpNejlf8c0y698MOcyJuojw2geujr5OI8EZf8JixVMH5BGYxyF12OwheKIUr FTkdTfoVZjrYAQL6lLfV8xkuHqGIc/iMpZpVLlt3/G8K2a8OuhouDCchfXqv1C8P+dsd Zet/ZJ0cIQSfEO8PU9iF47fqCK9jcvbKzlbzGLkdcrjgFbU5maowA9KThaHBi4VpCbGc 2xh8w4QFQSqKfm0c1HP/Lse5r4w5kFs7HdDXpVRCMS31VWfrjBTkcGB8JxnURvRAvKP+ QarxpIYxLhb/Bz+SMCtaKJqZ24UyvFuxi+VZcheCsLlaZmPr7uHMGqwUDCV2qchzCwIc chkg== X-Gm-Message-State: APjAAAVpPfQFmrrocYYUn3tEzDYHhy5pR6AJwrLW++aj5K8MBLqchcvZ fLMKoKL1ZfUbOrA4QSy8DD5B9YmUQv4xYWyeyXU= X-Google-Smtp-Source: APXvYqzBC9Gdh1FFxLOeL/OcODPMG8H50PClL/jL6/hOC+Ro8fVfZSKCPuosp/rXDAuw8uu1AiQV5PVAqbOPMwJCVac= X-Received: by 2002:ac2:5181:: with SMTP id u1mr10511367lfi.42.1564656038513; Thu, 01 Aug 2019 03:40:38 -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 13:40:26 +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-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 1, 2019 at 1:00 PM Sumit Garg wrote: > > > 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? > > AFAIK, layered security is better in case we move from lower privilege > level to higher privilege level rather than in reverse order. You can look at this in many ways. Another way to look at it is that the services should be provided with the least amount of permissions required for the task. Further you can containerize something, the better. As for your PLATFORMS support: it is all nice, but there is no way to convince op-tee or any other tee to be adopted by many real users. Every serious user can and will do their own thing, or at very best, buy it from someone who did their own thing and is trusted. There is zero chance that samsung, huawei, apple, nsa, google, rambus, payment system vendors, .. would actually share the tee (or probably even the interfaces). It is just too vital and people do not trust each other anymore :( Anyway, enough about the topic from my side. I guess people will tell what they want, I'm fine with any, and it is all progress from the current state :) -- Janne