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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1CBCDC433F5 for ; Tue, 5 Oct 2021 05:45:53 +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 40F91611C1 for ; Tue, 5 Oct 2021 05:45:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 40F91611C1 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=foundries.io 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 9D56F80FA5; Tue, 5 Oct 2021 07:45:50 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=foundries.io 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=foundries.io header.i=@foundries.io header.b="CCJPahIT"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id D523781D6C; Tue, 5 Oct 2021 07:45:48 +0200 (CEST) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 61A7B805F9 for ; Tue, 5 Oct 2021 07:45:45 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=foundries.io Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=jorge@foundries.io Received: by mail-wr1-x42b.google.com with SMTP id r10so18706435wra.12 for ; Mon, 04 Oct 2021 22:45:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foundries.io; s=google; h=from:date:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=PfDkUBU1JEKcdmr5c9CRMMnPh59Bzj2BUiQXEWSJBdk=; b=CCJPahITkflCLEB/y3OjFBesN5vaN8ha6Sv4vvUCqzxwnG/u1sVeZ/7kIAJk+ZLfNR B7Z6GJQGbu22SEIyz9E9frYSxRBxtNO20nYqA+Jt7xpAbS+lScpo3QEB5CPzQm09o6Nz WAo6eiJ5/6rm5tQ7S+bKygcJEhsp2/1dzCnbfqhlfusrZ/JoD9BT16GCQhvCnv95dePZ 6GXxYxZMBLvvVIE3fAwb/gziPb5UXn5Dt3jwhx8mAhKR7T73q15TsEYhy7iV/pc4+Ma9 KGNG9D7jQrxcifMsrVERlH4PUXop2hIsS1LphhY82kwug1v/MIJ/1e5ZlRrYIaoNq075 YQ4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:date:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=PfDkUBU1JEKcdmr5c9CRMMnPh59Bzj2BUiQXEWSJBdk=; b=OBcNVzY+B4eAfvdGce9M/Pa885Ouc1x/D1QcD6GcEGGqysf4R9Y3IQWiBOpzMv2AxB 6C+2ADmExgkhLu4N6E5pJptUfc1LBAPmtPRaPdXwTXkf+lUGe20P60jZospG30m5/Wqq 3O6x8Or0m8VU2YVTAuh8BvhS5jNrqN/uA0YTOx3KBkTq/NCEBdzkcaFm+hPFFEVxLaw1 bp1AHLT5VBZk3gMRQjWnzlGG0MyIbAD6oNaavntXPyBbZXk/jJDikYuhkozrETM2Kifh l7aF2kHuIhtQWyLFpYOb0LjsK6Gfsj442rA7uvaOJgeGT9w6nbHS7BF+5ft5daRHE+JE 9fEQ== X-Gm-Message-State: AOAM53321R64oxHiS9dnmXPTLoiprq0cETCe0iQQlf4Ikg+IYTHlwFS0 mfFOvrAgK6TxfR5byksKNLjPYw== X-Google-Smtp-Source: ABdhPJzKCAsbGL45Byr1TbnnztlfhFnsAmEffYe/LVj7ikQQf53fo6APyPQWztPjppHW9z0jq6eo1g== X-Received: by 2002:adf:a2d8:: with SMTP id t24mr7479060wra.91.1633412744879; Mon, 04 Oct 2021 22:45:44 -0700 (PDT) Received: from trex (197.red-79-154-202.dynamicip.rima-tde.net. [79.154.202.197]) by smtp.gmail.com with ESMTPSA id k26sm747156wms.39.2021.10.04.22.45.43 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Mon, 04 Oct 2021 22:45:44 -0700 (PDT) From: "Jorge Ramirez-Ortiz, Foundries" X-Google-Original-From: "Jorge Ramirez-Ortiz, Foundries" Date: Tue, 5 Oct 2021 07:45:43 +0200 To: "Alex G." Cc: "Jorge Ramirez-Ortiz, Foundries" , michal.simek@xilinx.com, trini@konsulko.com, sjg@chromium.org, u-boot@lists.denx.de, ricardo@foundries.io, mike@foundries.io, igor.opaniuk@foundries.io Subject: Re: FIT image: load secure FPGA Message-ID: <20211005054543.GA4478@trex> References: <20211004203226.GA4704@trex> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) 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 04/10/21, Alex G. wrote: > On 10/4/21 3:32 PM, Jorge Ramirez-Ortiz, Foundries wrote: > > Hello, > > hi Alex, > > We are enabling secure boot on Zynqmp with SPL. > > > > The issue however is that during secure boot, the bootrom not only > > validates the first loader (SPL and PMUFW combo) but it will also > > expect a signed bitstream during load(FPGA). > > > > Since currently the SPL load of an FPGA image from FIT does not > > support loading images for authentication (fpga_loads), I'd like to > > discuss how to best implement such support. > > What do you mean by "loading images for authentication" ? right, it eventually means executing fpga_loads insted of fpga_load ( a function that will provide additional params to the PMUFW. "loads" will load FPGA bitstreams that are either signed, encrypted or both. When they are only signed, they are first authenticated by the PMUFW and then loaded. > > > > A pretty standard file.its description of the FPGA loadable looks like > > this: > > > > fpga { > > description = "FPGA binary"; > > data = /incbin/("${DEPLOY_DIR_IMAGE}/${SPL_FPGA_BINARY}"); > > type = "fpga"; > > arch = "${UBOOT_ARCH}"; > > compression = "none"; > > load = <${fpgaloadaddr}>; > > hash-1 { > > algo = "${FIT_HASH_ALG}"; > > }; > > }; > > > > We could extend imagetool.h struct image_tool_params to add more > > params or perhpas just define different 'types' of fpga? > > > Check "4) '/images' node" > in doc/uImage.FIT/source_file_format.txt > > The intent is to give either: > * loadaddr="$(addr)" : copy image to $(addr), Done > * compatible="": Use this driver to upload the FPGA > > It seems to me like the right way to go is to make a new compatible="" FPGA > loader is for fpga_load(): > > fpga { > description = "FPGA binary"; > data = /incbin/("${YOCTO_BS_PATH}"); > type = "fpga"; > compression = "none"; > compatible = "zynqmp-fancy-fpga", so you think we should capture on compatible the characteristics of the FPGA image? > hash-1 { > algo = "${FIT_HASHISH}"; > }; > }; > > > > Something like: > > "fpga" > > "fpga-auth" : authenticated > > "fpga-enc" : encrypted > > "fpga-sec" : encrypted and authenticated > > Can these properties be inferred from the FPGA image? If not, they could be > required when using a new fpga loader. I don't think they should be added to > "fpga-legacy". maybe.. with a bit of boot header parsing... But doing so would deviate from the current approach making it somewhat inconsistent: ie, there is no a common "fpga load" command but instead we have "fpga load" and "fpga loads" as separate commands so perhaps the parsing is not that obvious or it would have been done differently. I'd rather follow the current approach and just explicitly qualify the bitstream. > > Alex > > > Then it would be a matter of modifying > > https://github.com/u-boot/u-boot/blob/master/common/spl/spl_fit.c#L572 > > > > any thoughts? > > > > TIA > > Jorge > >