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=-5.1 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 200DFC433EF for ; Fri, 3 Sep 2021 17:47:20 +0000 (UTC) Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 3D16160238 for ; Fri, 3 Sep 2021 17:47:18 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 3D16160238 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 9D25C83551; Fri, 3 Sep 2021 19:47:16 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="q4uOLP5z"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 1891E83551; Fri, 3 Sep 2021 19:47:15 +0200 (CEST) Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id ADAAD8354A for ; Fri, 3 Sep 2021 19:47:10 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=mr.nuke.me@gmail.com Received: by mail-ot1-x32a.google.com with SMTP id q11-20020a9d4b0b000000b0051acbdb2869so8997otf.2 for ; Fri, 03 Sep 2021 10:47:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=c4N7bk9gHpxKBbpCBPIf8zczb0xFGQM2yh03rvEMML8=; b=q4uOLP5zijuYNJa+g1eaJlCSfwqPzEwLJwEJGmgX4GGwZOnXti+1XdIKRllXPdQbTT jfpEZN2FU53Jm0dx8M2UuvYVoZ3V3WarvyuMrMBK9IqCmcTUE2fN8+8Ew1K5x1j9oMC1 jtYpYxA2pA7vAV/aoPTntsVOVuIcGKFaZRula7VZhCB479yC19bCLK2k29cOHpnywH3U 2UTlnB0ixMoF9v8dZpupliNmOUTR+jkXgFecY3ney2WN6q7ne3fryE4ac1xRp0ClWRte qtG3YYCZh4WyHsQhJh6N+dF0GlXb5x+K6bG4jGU9v/vXg7YmElIFvxNCYiiArtZxrds+ c17g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=c4N7bk9gHpxKBbpCBPIf8zczb0xFGQM2yh03rvEMML8=; b=ETb1sGqXluL90EQZmoqWyXKFU6gzNvgWWj1ChLHgDczI6G4pWpqX4Vc/w7L4N+e0WW nGTYhqw2F91sIe79ERbc4d3F9M1mz5vUzp0mRe5oDaRgIOrJII1mrs3H4xgiS1dYTTpG +tZYQc3Fb07sE+E221vTCEaWRsUJdbjMApbEJI5BkX1CLrHxJ9EKwwSi1Gek5EiNDaHQ YrqcOBQlFBRDTAUWPWDb9rbaNv07xlpaepVlcAGRD/oUfrh6BH215zgSHBuS6f98HvmJ GDPpiPb6QE2CNAvKRn3ykf1R7bBFR57gqAUTv0IchxetT1FQwjwgLb6+98/Sb3tu5yzV 00ug== X-Gm-Message-State: AOAM530gLO/RFpTEAarBoKhFba9fSDs1E0nuVkzRmq/WAKtrZkyupShF YVUqJuZfUUWZbfSEridQjIk= X-Google-Smtp-Source: ABdhPJx/Pak/UGEDxj7ZlzSMmhsFKKn/HbvuTvEZVSLx6YFmKfPBfYf2QQkClAXlY0bg2BuL4ZvoNw== X-Received: by 2002:a9d:1d0:: with SMTP id e74mr200506ote.41.1630691228876; Fri, 03 Sep 2021 10:47:08 -0700 (PDT) Received: from nuclearis3.gtech (c-98-195-139-126.hsd1.tx.comcast.net. [98.195.139.126]) by smtp.gmail.com with ESMTPSA id o8sm1110412oiw.55.2021.09.03.10.47.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 03 Sep 2021 10:47:08 -0700 (PDT) Subject: Re: [RFC PATCH] stm32mp1: Replace STM32IMAGE config with TFABOOT_FIP To: Marek Vasut , Patrick DELAUNAY , u-boot@lists.denx.de, bernard.puel@st.com Cc: Etienne Carriere , Patrice CHOTARD , Tom Rini , Lionel DEBIEVE References: <966fc974-8331-aeac-ba15-5b2ab19c0eaf@gmail.com> <20210826214705.255294-1-mr.nuke.me@gmail.com> <5dce263b-7325-9119-cb2b-74a9f397b970@denx.de> <13b65ac5-306f-1265-34d6-e0ffbd761e5b@denx.de> From: "Alex G." Message-ID: Date: Fri, 3 Sep 2021 12:47:07 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <13b65ac5-306f-1265-34d6-e0ffbd761e5b@denx.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean On 9/3/21 10:32 AM, Marek Vasut wrote: > On 9/1/21 11:07 AM, Patrick DELAUNAY wrote: >> On 8/31/21 6:42 PM, Marek Vasut wrote: >>> I would argue that the U-Boot crypto code went through multiple >> >>> independent security reviews, personally I trust that more than code >>> fully controlled and maintained by any one single company, so I am >>> not buying the security constraint argument here. >> >> >> When I talk about security, it is not crypto code, but some security >> features as isolation between cortex A and Cortex M, key >> infractructure, trusted environment execution, secure update. > > I'll offload this answer to Alexandru, however as far as I can tell, SPL > is perfectly capable of starting the TEE and setting up the correct > execution levels etc. too. There is not a unisex size for security. It's all driven by requirements. My client wants certain pieces of code to be triple-encrypted with a full-body latex suit (and kevlar reinforced). I don't care about A and M separation, clock control and other fancies. In fact it's better that those are handled by linux because that helps with boot time, considerably. I can achieve that by ECDSA-signing the FSBL, and putting that critical code in TEE trusted applications. I don't need to TiVO-ize the device, lock the kernel, etc. Because of that, can incorporate GPL-v3 programs and libraries, and generally have more flexibility in the software architecture. I'm more than happy to deal with the TZC and ETZPC in SPL, because SPL is fast. Again, this is really driven by the totality of requirements. TF-A is a pretty poor solution in this case for a trio of reasons. When I was trying TF-A, I found a small bug in assembly code. I tried to submit a fix, which was immediately rejected. I was required to sign a CLA granting patent rights. I can't do that legally on behalf of my client. This puts TF-A on a take it or leave it basis, such that I can't fix problems with it. TF-A also requires me to use a new file format (FIP). It's a binary format which is already a huge red flag for me. It seems very similar to a concatenation of EFI HOBs and FFS, and it makes no sense why TF-A would not have just gone with those more established formats. Is it secure? I don't know. It's pretty new to start with, and much more inflexible than FIT. Why would I recommend to my client an unproven format, when FIT has already gone through several CVEs and is more widely supported? Definitely not. Then TF-A is one extra codebase in the secure path of the system. Do I want to have to deal with an extra program bringing its own possible flaws on holes? Not really. The official STM wiki seems to document the "how" of security: "Use TF-A and TEE, all others unsupported". It doesn't explain the "why". The "how" is what my client complained it takes two minutes to boot. And those two minutes are the reason I'm working on this. It would help to have better explained options with their corresponding security implications. Even absent that, SPL is perfectly capable of starting a secure system. I think it's also more flexible. Let's get serious. Without SPL, I wouldn't have been able to boot linux in one second, with a secure OS. Alex