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 6E6D9C19759 for ; Thu, 1 Aug 2019 08:30:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3C2622087E for ; Thu, 1 Aug 2019 08:30:21 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="KVeh8Jw9" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729613AbfHAIaU (ORCPT ); Thu, 1 Aug 2019 04:30:20 -0400 Received: from mail-lf1-f65.google.com ([209.85.167.65]:46008 "EHLO mail-lf1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727506AbfHAIaU (ORCPT ); Thu, 1 Aug 2019 04:30:20 -0400 Received: by mail-lf1-f65.google.com with SMTP id u10so10820542lfm.12; Thu, 01 Aug 2019 01:30:18 -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=2xNohy2xyMAt9HM3Gyk3aetZhs8G9eF7ELJFgFiK0/I=; b=KVeh8Jw9S5Hs+wIxrPmvLbiA/a8qd2ZozSyly4TxKurfCOo1wsw0V1V4FfYAeJ2wAl hX+8KRVyClJNg+3FptaphJmcdmM9LnzOh6gagbOFy1eMrZjqDl8bcVFvxVo1dAiR9p+b FgdFqaoPZgECEcYJFHKHAoCypPwq4VSG353KdX7BgFGul9ORNUmXLocQaAQdLdRYnRab T20nnn0f6BhIpOqtJKrlqaa9f6Yn6/vlQQ1nLKTFluF8kJjAcp5eNSoiPczaPKAQJHFy DDP/HFLbIHCTMQOK6z+FkUHrlVi24L40YmEl1myxFuqnS8aWTlzma/wECZhp/dCoKJv3 W0sw== 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=2xNohy2xyMAt9HM3Gyk3aetZhs8G9eF7ELJFgFiK0/I=; b=LzNOOLJ8i1HHyeTpxE2+GpVdssv8bCiSKiOTnQAdQlI8miOya3BBc4LIBfvHtJGC7r ALQRVHHiY8H8dDNkFQ7AeYC9QqEAz42yH7zN05PYFoI32Yw5dlf8lhG2ectZ5Cgf1b/K RNP7jdLBOkBBhalOvOneQhubnWbg+XyLUWRFgWGphRltCQLE6+KCq4LLSRlxJo2MoKxK j05d1rSCt3hCq+HVXKbThoOpk3VcpPCDnHMNX9tt7QayBBO2ZsZ45iimK08J8mHzp6us Mf1qyeUWVuGK4lXxyGk+sMipfaysxbV38mWNuTYZX40/fdWec54Nd1Y7CnkjCxMYcmmi nQiA== X-Gm-Message-State: APjAAAV6Rp+/Wkaudm7wMdKKATfevRsTpz0ZWkmjSDZ00A7YoDAjpx7q x56J4fXo+pcpyh//iIf3XYAYG7QlIK1fYBBP4v4= X-Google-Smtp-Source: APXvYqzzD88SDt0GVEYWnLJkJRlwD14+HIfeihD4WoOdeKaL/6vYosJryMtEFIiIAgKt+K60XVbK4UMpvkES4vMcWVE= X-Received: by 2002:a19:f806:: with SMTP id a6mr47249319lff.102.1564648217496; Thu, 01 Aug 2019 01:30:17 -0700 (PDT) MIME-Version: 1.0 References: <1564489420-677-1-git-send-email-sumit.garg@linaro.org> <19d9be198619e951750dedeb4d0a7f372083b42c.camel@pengutronix.de> In-Reply-To: From: Janne Karhunen Date: Thu, 1 Aug 2019 11:30:05 +0300 Message-ID: Subject: Re: [Tee-dev] [RFC v2 0/6] Introduce TEE based Trusted Keys support To: Sumit Garg Cc: Rouven Czerwinski , "tee-dev @ lists . linaro . org" , Daniel Thompson , Jonathan Corbet , jejb@linux.ibm.com, Ard Biesheuvel , Linux Doc Mailing List , Jarkko Sakkinen , Linux Kernel Mailing List , dhowells@redhat.com, linux-security-module@vger.kernel.org, keyrings@vger.kernel.org, Mimi Zohar , Casey Schaufler , linux-integrity@vger.kernel.org, linux-arm-kernel , "Serge E. Hallyn" Content-Type: text/plain; charset="UTF-8" Sender: owner-linux-security-module@vger.kernel.org Precedence: bulk List-ID: On Thu, Aug 1, 2019 at 10:58 AM Sumit Garg wrote: > > Anyway, just my .02c. I guess having any new support in the kernel for > > new trust sources is good and improvement from the current state. I > > can certainly make my stuff work with your setup as well, what ever > > people think is the best. > > Yes your implementation can very well fit under trusted keys > abstraction framework without creating a new keytype: "ext-trusted". The fundamental problem with the 'standardized kernel tee' still exists - it will never be generic in real life. Getting all this in the kernel will solve your problem and sell this particular product, but it is quite unlikely to help that many users. If the security is truly important to you, would you really trust any of this code to someone else? In this day and age, I really doubt many do. Everyone does their own thing, so this is why I really see all that as a userspace problem. -- Janne