Message ID | 20231122054404.3764288-2-nava.kishore.manne@amd.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2b07:b0:403:3b70:6f57 with SMTP id io7csp1113986vqb; Tue, 21 Nov 2023 21:44:45 -0800 (PST) X-Google-Smtp-Source: AGHT+IGlWK7Y6ljjVH8HFwS6xofnY3VTuuKtFLiEaZPFP+Lw3N20WdTaQzQtDz+hiac0OWW2GXCL X-Received: by 2002:a17:90b:4a04:b0:281:40b:5a7a with SMTP id kk4-20020a17090b4a0400b00281040b5a7amr1670896pjb.8.1700631885525; Tue, 21 Nov 2023 21:44:45 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1700631885; cv=pass; d=google.com; s=arc-20160816; b=XIBerNjVk5YiRPcIdghodZTnGnzfHv8uMnefSd0aFRouNhYlQR1g3RuPCbMF3fbEf0 zgvXLZJxZXhds8TKGn/0b3EF90qElD4uJtnV2bODEui9s+YkZoroMONNgD64fBCGslb+ qevm86M2usfqqPFdqeH6LsKPa/5ibODwvGQYdpNt5odNPtPId4OmVwI2KH7WPvGLSr3m iP/GETiIcCEAEZEFokYJkh5xSwWvJbjMHrSt/qZ99QU6GZrO4kH5CSxcdWscLQ3dUKnH fiA6rSpu5YuUU2vNovgLQWYHSAi/pozBvOCy2RBh1Xjy0q53wsD5WXyFAHHwuuqFFPtS z3UA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:to:from :dkim-signature; bh=8bJHqFsQ7Ql6vWH0BAWPzKyvwMprZO1GxJcYFeMfkmY=; fh=5bqgl+4tgA7Vt+pTddkEmoLZB0aah352OndmOQFBWKA=; b=HNi98esXW/J2IXrFpKj5PLnPiv04vjZieO1NBUAJyiTxfQbGxbqyfjfWfFv3CC9fvo 2mbFHDZhfdK/N6q7dheGuWfs53rLICqcj6eIe4a6VLW85IjRrH1SAc71Uiv4XNaDxCbD yiGxiiO4HCvwZkX6veUFiS8G2Kfoxj/K72M7UAA134jdEYdcit3i+G+OeXBfannWPQzF u1ytQrKC9wGKWRFRszjf06F1Mb01crtoYAzbJ7o/fo17GbzGOwkgiQoLywPSsPJzWwXH UaqyNRnwIf5P5BurlFB58i60+Gx5Dpa0HSrtHwyGE4ZI1Dv9PvnssCFKvE/YNjEQ+v/R zzBg== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@amd.com header.s=selector1 header.b=P+s4S2Fs; arc=pass (i=1 spf=pass spfdomain=amd.com dmarc=pass fromdomain=amd.com); spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=amd.com Received: from snail.vger.email (snail.vger.email. [23.128.96.37]) by mx.google.com with ESMTPS id t1-20020a17090aae0100b0027d33155aefsi739589pjq.99.2023.11.21.21.44.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Nov 2023 21:44:45 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37; Authentication-Results: mx.google.com; dkim=pass header.i=@amd.com header.s=selector1 header.b=P+s4S2Fs; arc=pass (i=1 spf=pass spfdomain=amd.com dmarc=pass fromdomain=amd.com); spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=amd.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id 58812819A6A7; Tue, 21 Nov 2023 21:44:28 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234351AbjKVFoZ (ORCPT <rfc822;ouuuleilei@gmail.com> + 99 others); Wed, 22 Nov 2023 00:44:25 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35784 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229498AbjKVFoS (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 22 Nov 2023 00:44:18 -0500 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2088.outbound.protection.outlook.com [40.107.220.88]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E6A2890; Tue, 21 Nov 2023 21:44:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CtYDkLAH6f7B5Qr+6rcNzU2QO0oESjIhTa7qLmitQgmy5emPbazJrjLHa+etf26sw7HOkvJM8xHv0c4FdVZEP22auuAjp38E32BLu0RzM3bX4MnptNfj5/PaXDR+tKacjpSNwFHZCTT4gOwJ9De3D95fQz51S/ZIaWahndTLgrInAaDSrX33aodlXmOeHGlRSKu4Xbi2NJ5ZzmIKjutpeIl+HEZuMleZlHcvvsCtdy/0a21fLTC/KU+3mGdbsN20DKd8jJk7KkePhzyGqeGSQKqBtvlla+sQLRGkH7MBM2JV8SNkDkKZfkn85efxU+XNzevvDxYQl30oXic56uZ++Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=8bJHqFsQ7Ql6vWH0BAWPzKyvwMprZO1GxJcYFeMfkmY=; b=oVqnyVW1T4OTL6bCRf8FxJZgBT/Y27unvWeOnowIUorcXkAgfGDvNO0oQ3zIAyJm+6TA+wc20+2TV0mLbmilPI4OCnt2yuPwHFNcE+L/UdG/zPZeQNe+M68Bw3Z63HchW5ITZEc1XzDFZlizxM6kGHklDY37ScvjzDULIOEW4z2Q6+hSQmbXc26s3nIkLHCGf9DZa5TSFeznVGfJd3g9Flig6uDTWdWFEhWLn1FFpBrednaFFXMooRbxutOSt/fwDNYNxygDiKJKKn0GQqQdyfC5cPaiJFSP5S4ZBN5gmno/WjsOctcO1dt6DK6Hvm9QsUb5VFUdxzFOwyid3HN80A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=kernel.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8bJHqFsQ7Ql6vWH0BAWPzKyvwMprZO1GxJcYFeMfkmY=; b=P+s4S2FsbCnKvofgZsD1StyhwCMzlEIIiYyT8KQr1n1PIInrosRJWhEJkDNoeiSrtdHzYOZ03E82rvZihmVbndxoKcIm4H+H19cqXx3IDwV+ONMG5UEnZSviL/FnRWt5DuRqoWHEm3yfbVKE7jxQomZbiaL1TyOsLo1SXsIQC08= Received: from MN2PR01CA0019.prod.exchangelabs.com (2603:10b6:208:10c::32) by CY5PR12MB6250.namprd12.prod.outlook.com (2603:10b6:930:22::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7025.18; Wed, 22 Nov 2023 05:44:11 +0000 Received: from BL02EPF0001A0FE.namprd03.prod.outlook.com (2603:10b6:208:10c:cafe::41) by MN2PR01CA0019.outlook.office365.com (2603:10b6:208:10c::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7002.26 via Frontend Transport; Wed, 22 Nov 2023 05:44:11 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C Received: from SATLEXMB04.amd.com (165.204.84.17) by BL02EPF0001A0FE.mail.protection.outlook.com (10.167.242.105) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7025.12 via Frontend Transport; Wed, 22 Nov 2023 05:44:11 +0000 Received: from localhost (10.180.168.240) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.34; Tue, 21 Nov 2023 23:44:10 -0600 From: Nava kishore Manne <nava.kishore.manne@amd.com> To: <mdf@kernel.org>, <hao.wu@intel.com>, <yilun.xu@intel.com>, <trix@redhat.com>, <robh+dt@kernel.org>, <krzysztof.kozlowski+dt@linaro.org>, <conor+dt@kernel.org>, <michal.simek@amd.com>, <mathieu.poirier@linaro.org>, <ben.levinsky@amd.com>, <sai.krishna.potthuri@amd.com>, <tanmay.shah@amd.com>, <nava.kishore.manne@amd.com>, <dhaval.r.shah@amd.com>, <arnd@arndb.de>, <shubhrajyoti.datta@amd.com>, <linux-fpga@vger.kernel.org>, <devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <linux-arm-kernel@lists.infradead.org> Subject: [RFC PATCH 1/3] dt-bindings: fpga: Add support for user-key encrypted bitstream loading Date: Wed, 22 Nov 2023 11:14:02 +0530 Message-ID: <20231122054404.3764288-2-nava.kishore.manne@amd.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20231122054404.3764288-1-nava.kishore.manne@amd.com> References: <20231122054404.3764288-1-nava.kishore.manne@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BL02EPF0001A0FE:EE_|CY5PR12MB6250:EE_ X-MS-Office365-Filtering-Correlation-Id: 9bec07ce-8717-4782-5ce7-08dbeb1e0db1 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Oh8yo332bctwMxeDEQd59bKPdlZrUIuV2m8/tJsZY9IH0I6CUiwwf967/58FGdwHm26bMiaVf9KndbUiZauFe7zVXF6njIRF4POLzAe/pnpR9uXR2Y5laBFmqa2dJGDSGUCRut+YvKBnR9zz9Z+1I8K8rSUfzjZW48rYeIqnt2SA0tTYtvWDHlvU2yOMOaTVw9v0hZyyJOQ20YNVXoI27NhBehnv49qXzaK8oYfWbMzK81weMkPiUOetw2QD+apWXEUnjcWmXeEATAQ9r5HmCRmkye1Rc4WbQcsmgzjWmjYQaRbDv29Cr81UFT1GkBGih/OSS0TpC7xqAz0rCuUsWdF+2yB/iCp0iBH6k9im8Y88oxuVhnc60dKBZJCbgruSa4CZsRP9XmSTk+ni15yDXnTVnD1RBKBmCqRz84RgOf5saYtWh2hiRC7Uli/vnwcwTqtnG7h2uBqeGKE18GUcFdAnu0SCGmMl+WY+UipnGcKtAJdYGqsNYqaT4470MM7IjEuXzphGKruiKd2XW360O33EwrQpjtPkdf3sFGe7eumtgU7Gm3a1DtGIXBfN/abDISd+OwCOk/ldm507h6DI3YEDhS7C7A5LS+Q0Y7fL2HeSYfX1jSHX+E3J7PxS5xbAAwLSGR/zwhyhGJxgk93ZnN1y53RW5vUufH+224NFAxvNQEZ0x+4BBYH3H2gbEnFl06HsutoA6+CgISqeoKbHbbzDF3Vio6GPCG7v0uw097QS4b74x1wl/50mhputWkJlQzBDasn3WQKpTgLBrKGzdcwk+VSFTdSJf2/klxR5PPtzKL9/gxQfQ+JqT13KeaivYuYhN29Vvu58E0DR5RF8xA== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(4636009)(39860400002)(376002)(136003)(396003)(346002)(230922051799003)(451199024)(82310400011)(186009)(64100799003)(1800799012)(46966006)(36840700001)(40470700004)(7416002)(86362001)(5660300002)(2906002)(8676002)(8936002)(110136005)(70206006)(316002)(70586007)(40460700003)(36756003)(921008)(41300700001)(103116003)(336012)(26005)(40480700001)(16526019)(426003)(82740400003)(1076003)(2616005)(83380400001)(6666004)(81166007)(36860700001)(356005)(47076005)(478600001)(2101003)(36900700001)(83996005);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Nov 2023 05:44:11.3862 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 9bec07ce-8717-4782-5ce7-08dbeb1e0db1 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: BL02EPF0001A0FE.namprd03.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY5PR12MB6250 X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_SPF_HELO, RCVD_IN_DNSWL_BLOCKED,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Tue, 21 Nov 2023 21:44:28 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1783241779811506193 X-GMAIL-MSGID: 1783241779811506193 |
Series |
fpga: Add encrypted Bitstream loading support
|
|
Commit Message
Manne, Nava kishore
Nov. 22, 2023, 5:44 a.m. UTC
Adds ‘encrypted-key-name’ property to support user-key encrypted
bitstream loading use case.
Signed-off-by: Nava kishore Manne <nava.kishore.manne@amd.com>
---
.../devicetree/bindings/fpga/fpga-region.txt | 32 +++++++++++++++++++
1 file changed, 32 insertions(+)
Comments
On Wed, Nov 22, 2023 at 11:14:02AM +0530, Nava kishore Manne wrote: > Adds ‘encrypted-key-name’ property to support user-key encrypted > bitstream loading use case. > > Signed-off-by: Nava kishore Manne <nava.kishore.manne@amd.com> > --- > .../devicetree/bindings/fpga/fpga-region.txt | 32 +++++++++++++++++++ Is there a reason that this has not yet been converted to yaml? > 1 file changed, 32 insertions(+) > > diff --git a/Documentation/devicetree/bindings/fpga/fpga-region.txt b/Documentation/devicetree/bindings/fpga/fpga-region.txt > index 528df8a0e6d8..309334558b3f 100644 > --- a/Documentation/devicetree/bindings/fpga/fpga-region.txt > +++ b/Documentation/devicetree/bindings/fpga/fpga-region.txt > @@ -177,6 +177,9 @@ Optional properties: > it indicates that the FPGA has already been programmed with this image. > If this property is in an overlay targeting an FPGA region, it is a > request to program the FPGA with that image. > +- encrypted-key-name : should contain the name of an encrypted key file located > + on the firmware search path. It will be used to decrypt the FPGA image > + file with user-key. I might be misreading things, but your driver code seems to assume that this is an aes key. Nothing here seems to document that this is supposed to be a key of a particular type. Cheers, Conor. > - fpga-bridges : should contain a list of phandles to FPGA Bridges that must be > controlled during FPGA programming along with the parent FPGA bridge. > This property is optional if the FPGA Manager handles the bridges. > @@ -459,6 +462,35 @@ programming is the FPGA based bridge of fpga_region1. > }; > }; > > +Device Tree Example: Configure/Reconfigure Encrypted Image With User Key > +======================================================================== > + > +Users can encrypt FPGA configuration Images with their own key. While decrypting > +the configuration Image the user needs to provide the same key. > +"encrypted-key-name" Specifies the name of the FPGA image encrypted key file on > +the firmware search path. The search path is described in the firmware class > +documentation. > + > +/dts-v1/; > +/plugin/; > + > +&fpga_region0 { > + #address-cells = <1>; > + #size-cells = <1>; > + > + firmware-name = "soc_image2.rbf"; > + encrypted-key-name = "key.nky"; > + > + gpio@10040 { > + compatible = "altr,pio-1.0"; > + reg = <0x10040 0x20>; > + clocks = <0x2>; > + altr,ngpio = <0x4>; > + #gpio-cells = <0x2>; > + gpio-controller; > + }; > +}; > + > Constraints > =========== > > -- > 2.25.1 >
Hi Conor, Thanks for providing the review comments. Please find my response inline. > -----Original Message----- > From: Conor Dooley <conor@kernel.org> > Sent: Wednesday, November 22, 2023 10:21 PM > To: Manne, Nava kishore <nava.kishore.manne@amd.com> > Cc: mdf@kernel.org; hao.wu@intel.com; yilun.xu@intel.com; > trix@redhat.com; robh+dt@kernel.org; krzysztof.kozlowski+dt@linaro.org; > conor+dt@kernel.org; Simek, Michal <michal.simek@amd.com>; > mathieu.poirier@linaro.org; Levinsky, Ben <ben.levinsky@amd.com>; > Potthuri, Sai Krishna <sai.krishna.potthuri@amd.com>; Shah, Tanmay > <tanmay.shah@amd.com>; dhaval.r.shah@amd.com; arnd@arndb.de; > Datta, Shubhrajyoti <shubhrajyoti.datta@amd.com>; linux- > fpga@vger.kernel.org; devicetree@vger.kernel.org; linux- > kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org > Subject: Re: [RFC PATCH 1/3] dt-bindings: fpga: Add support for user-key > encrypted bitstream loading > > On Wed, Nov 22, 2023 at 11:14:02AM +0530, Nava kishore Manne wrote: > > Adds ‘encrypted-key-name’ property to support user-key encrypted > > bitstream loading use case. > > > > Signed-off-by: Nava kishore Manne <nava.kishore.manne@amd.com> > > --- > > .../devicetree/bindings/fpga/fpga-region.txt | 32 > > +++++++++++++++++++ > > Is there a reason that this has not yet been converted to yaml? > I am not sure about the complication involved here why it's not converted to yaml format. Due to time constraints, I couldn’t spend much time so I have used this existing legacy format to add my changes. > > 1 file changed, 32 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/fpga/fpga-region.txt > > b/Documentation/devicetree/bindings/fpga/fpga-region.txt > > index 528df8a0e6d8..309334558b3f 100644 > > --- a/Documentation/devicetree/bindings/fpga/fpga-region.txt > > +++ b/Documentation/devicetree/bindings/fpga/fpga-region.txt > > @@ -177,6 +177,9 @@ Optional properties: > > it indicates that the FPGA has already been programmed with this > image. > > If this property is in an overlay targeting an FPGA region, it is a > > request to program the FPGA with that image. > > +- encrypted-key-name : should contain the name of an encrypted key file > located > > + on the firmware search path. It will be used to decrypt the FPGA > image > > + file with user-key. > > I might be misreading things, but your driver code seems to assume that this > is an aes key. Nothing here seems to document that this is supposed to be a > key of a particular type. > Yes, these changes are intended to add the support for Aes user-key encrypted bitstream loading use case. Will fix it in v2, something like below. aes-key-file-name : Should contain the AES key file name on the firmware search path. The key file contains the AES key and it will be used to decrypt the FPGA image. Regards, Navakishore.
On Fri, Nov 24, 2023 at 06:35:19AM +0000, Manne, Nava kishore wrote: > Hi Conor, > > Thanks for providing the review comments. > Please find my response inline. > > > -----Original Message----- > > From: Conor Dooley <conor@kernel.org> > > Sent: Wednesday, November 22, 2023 10:21 PM > > To: Manne, Nava kishore <nava.kishore.manne@amd.com> > > Cc: mdf@kernel.org; hao.wu@intel.com; yilun.xu@intel.com; > > trix@redhat.com; robh+dt@kernel.org; krzysztof.kozlowski+dt@linaro.org; > > conor+dt@kernel.org; Simek, Michal <michal.simek@amd.com>; > > mathieu.poirier@linaro.org; Levinsky, Ben <ben.levinsky@amd.com>; > > Potthuri, Sai Krishna <sai.krishna.potthuri@amd.com>; Shah, Tanmay > > <tanmay.shah@amd.com>; dhaval.r.shah@amd.com; arnd@arndb.de; > > Datta, Shubhrajyoti <shubhrajyoti.datta@amd.com>; linux- > > fpga@vger.kernel.org; devicetree@vger.kernel.org; linux- > > kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org > > Subject: Re: [RFC PATCH 1/3] dt-bindings: fpga: Add support for user-key > > encrypted bitstream loading > > > > On Wed, Nov 22, 2023 at 11:14:02AM +0530, Nava kishore Manne wrote: > > > Adds ‘encrypted-key-name’ property to support user-key encrypted > > > bitstream loading use case. > > > > > > Signed-off-by: Nava kishore Manne <nava.kishore.manne@amd.com> > > > --- > > > .../devicetree/bindings/fpga/fpga-region.txt | 32 > > > +++++++++++++++++++ > > > > Is there a reason that this has not yet been converted to yaml? > > > I am not sure about the complication involved here why it's not converted to yaml format. > Due to time constraints, I couldn’t spend much time so I have used this existing legacy format > to add my changes. > > > > 1 file changed, 32 insertions(+) > > > > > > diff --git a/Documentation/devicetree/bindings/fpga/fpga-region.txt > > > b/Documentation/devicetree/bindings/fpga/fpga-region.txt > > > index 528df8a0e6d8..309334558b3f 100644 > > > --- a/Documentation/devicetree/bindings/fpga/fpga-region.txt > > > +++ b/Documentation/devicetree/bindings/fpga/fpga-region.txt > > > @@ -177,6 +177,9 @@ Optional properties: > > > it indicates that the FPGA has already been programmed with this > > image. > > > If this property is in an overlay targeting an FPGA region, it is a > > > request to program the FPGA with that image. > > > +- encrypted-key-name : should contain the name of an encrypted key file > > located > > > + on the firmware search path. It will be used to decrypt the FPGA > > image > > > + file with user-key. > > > > I might be misreading things, but your driver code seems to assume that this > > is an aes key. Nothing here seems to document that this is supposed to be a > > key of a particular type. > > > > Yes, these changes are intended to add the support for Aes user-key encrypted bitstream loading use case. > Will fix it in v2, something like below. > aes-key-file-name : Should contain the AES key file name on the firmware search path. > The key file contains the AES key and it will be used to decrypt the FPGA image. Then when someone comes along looking for a different type of encryption we will end up with national-pride-foo-file-name etc. I think I'd rather have a second property that notes what type of cipher is being used and if that property is not present default to AES.
On 24/11/2023 13:48, Conor Dooley wrote: > On Fri, Nov 24, 2023 at 06:35:19AM +0000, Manne, Nava kishore wrote: >> Hi Conor, >> >> Thanks for providing the review comments. >> Please find my response inline. >> >>> -----Original Message----- >>> From: Conor Dooley <conor@kernel.org> >>> Sent: Wednesday, November 22, 2023 10:21 PM >>> To: Manne, Nava kishore <nava.kishore.manne@amd.com> >>> Cc: mdf@kernel.org; hao.wu@intel.com; yilun.xu@intel.com; >>> trix@redhat.com; robh+dt@kernel.org; krzysztof.kozlowski+dt@linaro.org; >>> conor+dt@kernel.org; Simek, Michal <michal.simek@amd.com>; >>> mathieu.poirier@linaro.org; Levinsky, Ben <ben.levinsky@amd.com>; >>> Potthuri, Sai Krishna <sai.krishna.potthuri@amd.com>; Shah, Tanmay >>> <tanmay.shah@amd.com>; dhaval.r.shah@amd.com; arnd@arndb.de; >>> Datta, Shubhrajyoti <shubhrajyoti.datta@amd.com>; linux- >>> fpga@vger.kernel.org; devicetree@vger.kernel.org; linux- >>> kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org >>> Subject: Re: [RFC PATCH 1/3] dt-bindings: fpga: Add support for user-key >>> encrypted bitstream loading >>> >>> On Wed, Nov 22, 2023 at 11:14:02AM +0530, Nava kishore Manne wrote: >>>> Adds ‘encrypted-key-name’ property to support user-key encrypted >>>> bitstream loading use case. >>>> >>>> Signed-off-by: Nava kishore Manne <nava.kishore.manne@amd.com> >>>> --- >>>> .../devicetree/bindings/fpga/fpga-region.txt | 32 >>>> +++++++++++++++++++ >>> >>> Is there a reason that this has not yet been converted to yaml? >>> >> I am not sure about the complication involved here why it's not converted to yaml format. >> Due to time constraints, I couldn’t spend much time so I have used this existing legacy format >> to add my changes. >> >>>> 1 file changed, 32 insertions(+) >>>> >>>> diff --git a/Documentation/devicetree/bindings/fpga/fpga-region.txt >>>> b/Documentation/devicetree/bindings/fpga/fpga-region.txt >>>> index 528df8a0e6d8..309334558b3f 100644 >>>> --- a/Documentation/devicetree/bindings/fpga/fpga-region.txt >>>> +++ b/Documentation/devicetree/bindings/fpga/fpga-region.txt >>>> @@ -177,6 +177,9 @@ Optional properties: >>>> it indicates that the FPGA has already been programmed with this >>> image. >>>> If this property is in an overlay targeting an FPGA region, it is a >>>> request to program the FPGA with that image. >>>> +- encrypted-key-name : should contain the name of an encrypted key file >>> located >>>> + on the firmware search path. It will be used to decrypt the FPGA >>> image >>>> + file with user-key. >>> >>> I might be misreading things, but your driver code seems to assume that this >>> is an aes key. Nothing here seems to document that this is supposed to be a >>> key of a particular type. >>> >> >> Yes, these changes are intended to add the support for Aes user-key encrypted bitstream loading use case. >> Will fix it in v2, something like below. >> aes-key-file-name : Should contain the AES key file name on the firmware search path. >> The key file contains the AES key and it will be used to decrypt the FPGA image. > > Then when someone comes along looking for a different type of encryption > we will end up with national-pride-foo-file-name etc. I think I'd rather > have a second property that notes what type of cipher is being used and > if that property is not present default to AES. I wonder why does it need to be in DT in the first place? Why it cannot be appended to the FPGA binary image itself? Which also points to dubious security aspect of this approach... Shipping FPGA encrypted image with its decryption key sounds like marvelous idea. Even if this is suitable, why not using more arguments of firmware-name? This would scale even for multiple FPGA firmwares with different keys (although such need seems unlikely). Best regards, Krzysztof
On Fri, Nov 24, 2023 at 04:46:06PM +0100, Krzysztof Kozlowski wrote: > On 24/11/2023 13:48, Conor Dooley wrote: > > On Fri, Nov 24, 2023 at 06:35:19AM +0000, Manne, Nava kishore wrote: > >> Hi Conor, > >> > >> Thanks for providing the review comments. > >> Please find my response inline. > >> > >>> -----Original Message----- > >>> From: Conor Dooley <conor@kernel.org> > >>> Sent: Wednesday, November 22, 2023 10:21 PM > >>> To: Manne, Nava kishore <nava.kishore.manne@amd.com> > >>> Cc: mdf@kernel.org; hao.wu@intel.com; yilun.xu@intel.com; > >>> trix@redhat.com; robh+dt@kernel.org; krzysztof.kozlowski+dt@linaro.org; > >>> conor+dt@kernel.org; Simek, Michal <michal.simek@amd.com>; > >>> mathieu.poirier@linaro.org; Levinsky, Ben <ben.levinsky@amd.com>; > >>> Potthuri, Sai Krishna <sai.krishna.potthuri@amd.com>; Shah, Tanmay > >>> <tanmay.shah@amd.com>; dhaval.r.shah@amd.com; arnd@arndb.de; > >>> Datta, Shubhrajyoti <shubhrajyoti.datta@amd.com>; linux- > >>> fpga@vger.kernel.org; devicetree@vger.kernel.org; linux- > >>> kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org > >>> Subject: Re: [RFC PATCH 1/3] dt-bindings: fpga: Add support for user-key > >>> encrypted bitstream loading > >>> > >>> On Wed, Nov 22, 2023 at 11:14:02AM +0530, Nava kishore Manne wrote: > >>>> Adds ‘encrypted-key-name’ property to support user-key encrypted > >>>> bitstream loading use case. > >>>> > >>>> Signed-off-by: Nava kishore Manne <nava.kishore.manne@amd.com> > >>>> --- > >>>> .../devicetree/bindings/fpga/fpga-region.txt | 32 > >>>> +++++++++++++++++++ > >>> > >>> Is there a reason that this has not yet been converted to yaml? > >>> > >> I am not sure about the complication involved here why it's not converted to yaml format. > >> Due to time constraints, I couldn’t spend much time so I have used this existing legacy format > >> to add my changes. > >> > >>>> 1 file changed, 32 insertions(+) > >>>> > >>>> diff --git a/Documentation/devicetree/bindings/fpga/fpga-region.txt > >>>> b/Documentation/devicetree/bindings/fpga/fpga-region.txt > >>>> index 528df8a0e6d8..309334558b3f 100644 > >>>> --- a/Documentation/devicetree/bindings/fpga/fpga-region.txt > >>>> +++ b/Documentation/devicetree/bindings/fpga/fpga-region.txt > >>>> @@ -177,6 +177,9 @@ Optional properties: > >>>> it indicates that the FPGA has already been programmed with this > >>> image. > >>>> If this property is in an overlay targeting an FPGA region, it is a > >>>> request to program the FPGA with that image. > >>>> +- encrypted-key-name : should contain the name of an encrypted key file > >>> located > >>>> + on the firmware search path. It will be used to decrypt the FPGA > >>> image > >>>> + file with user-key. > >>> > >>> I might be misreading things, but your driver code seems to assume that this > >>> is an aes key. Nothing here seems to document that this is supposed to be a > >>> key of a particular type. > >>> > >> > >> Yes, these changes are intended to add the support for Aes user-key encrypted bitstream loading use case. > >> Will fix it in v2, something like below. > >> aes-key-file-name : Should contain the AES key file name on the firmware search path. > >> The key file contains the AES key and it will be used to decrypt the FPGA image. > > > > Then when someone comes along looking for a different type of encryption > > we will end up with national-pride-foo-file-name etc. I think I'd rather > > have a second property that notes what type of cipher is being used and > > if that property is not present default to AES. > > I wonder why does it need to be in DT in the first place? Why it cannot > be appended to the FPGA binary image itself? Which also points to > dubious security aspect of this approach... Shipping FPGA encrypted > image with its decryption key sounds like marvelous idea. > > Even if this is suitable, why not using more arguments of firmware-name? > This would scale even for multiple FPGA firmwares with different keys > (although such need seems unlikely). In case it is not clear (given the month's delay here), this question is for the submitter of the series to answer, not me. Cheers, Conor.
diff --git a/Documentation/devicetree/bindings/fpga/fpga-region.txt b/Documentation/devicetree/bindings/fpga/fpga-region.txt index 528df8a0e6d8..309334558b3f 100644 --- a/Documentation/devicetree/bindings/fpga/fpga-region.txt +++ b/Documentation/devicetree/bindings/fpga/fpga-region.txt @@ -177,6 +177,9 @@ Optional properties: it indicates that the FPGA has already been programmed with this image. If this property is in an overlay targeting an FPGA region, it is a request to program the FPGA with that image. +- encrypted-key-name : should contain the name of an encrypted key file located + on the firmware search path. It will be used to decrypt the FPGA image + file with user-key. - fpga-bridges : should contain a list of phandles to FPGA Bridges that must be controlled during FPGA programming along with the parent FPGA bridge. This property is optional if the FPGA Manager handles the bridges. @@ -459,6 +462,35 @@ programming is the FPGA based bridge of fpga_region1. }; }; +Device Tree Example: Configure/Reconfigure Encrypted Image With User Key +======================================================================== + +Users can encrypt FPGA configuration Images with their own key. While decrypting +the configuration Image the user needs to provide the same key. +"encrypted-key-name" Specifies the name of the FPGA image encrypted key file on +the firmware search path. The search path is described in the firmware class +documentation. + +/dts-v1/; +/plugin/; + +&fpga_region0 { + #address-cells = <1>; + #size-cells = <1>; + + firmware-name = "soc_image2.rbf"; + encrypted-key-name = "key.nky"; + + gpio@10040 { + compatible = "altr,pio-1.0"; + reg = <0x10040 0x20>; + clocks = <0x2>; + altr,ngpio = <0x4>; + #gpio-cells = <0x2>; + gpio-controller; + }; +}; + Constraints ===========