Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp3810347pxu; Mon, 30 Nov 2020 10:41:44 -0800 (PST) X-Google-Smtp-Source: ABdhPJydw11t8t2N3FtZI2/rlI3qVryfANJGXcaWYi9ndeHlnehN/P9b9uzIMr6Y2I9c5hwSYdEP X-Received: by 2002:a17:906:3704:: with SMTP id d4mr22371950ejc.338.1606761704461; Mon, 30 Nov 2020 10:41:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606761704; cv=none; d=google.com; s=arc-20160816; b=09IJNzFjdLjBmV+zg3eKCf4InA/sRp0a6dhOWclc1gEKHIVqMaMX3wVpNSL1FT4yHC hsjyuD9afQb9jgWoeYxcpyUlmf9CCCJhZAOsV9TjJ7F4QKROFit4yCqN8RQvNwuaYy0U +dxCJZWwFnocQbZt0FcGS0709oC1z+aEHQZMCZ5Uklqo3qAaBRVfiT+C57hz2qD+gwOP hWkE+QWOILFYsVoKtofWfeO50bBKFV42SBhytHymWVecEaZAbLFeuN0VmY9sNPwUXlN8 +Og0ntJYgvpxnx8Epa+vgJPBC5g6MoLFz6nuo6HISxvE/IiNbqokLk94TxzAQ9xigmw3 nCxA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:ironport-sdr:ironport-sdr; bh=60oPvvTTfGpcpG5D3gPsuf1JsbUgcXrUUEqJs4Wen6M=; b=gKB7rjrJaQ5g2hZWncm0u8MWR1rNxA7SR/AkM1tlI5Wal5ijNsCLSxD2He3BfmGK9k Gj5u2CCwu+HsPzxZ3zDrrB1yQpyyRmTgaVOMi3jSCGCevyXExEpyX5tZhr1mBZYVizGw 5VfiJ1rx8dXW1zCKBEetI467YOqQJdQvMPiLC2P7YLGGx83eE1pL93AmJMadqkXUDxkN 7bUXRLS9XJSTEB2MXLGM49pGSAGxOI+KNe9sMeHpEgbgR0CZOGqVMSn1dcWECtePFUL4 tRuMtvack2e6VttALSVWnpSgGpd5m20iQfzIFdzkymnDTECv0x2E/4zvqt0Xo7QQQNxH DMyQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id x17si161224ejw.478.2020.11.30.10.41.22; Mon, 30 Nov 2020 10:41:44 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729735AbgK3Sgj (ORCPT + 99 others); Mon, 30 Nov 2020 13:36:39 -0500 Received: from mga06.intel.com ([134.134.136.31]:18345 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727952AbgK3Sgj (ORCPT ); Mon, 30 Nov 2020 13:36:39 -0500 IronPort-SDR: PWvcGSKmvorEao3Xj9sDAJn9Yf7OTM7Rd0Efl82M8axHN4WYqn/5urVdu9uLPWpOYd/b2F5cOD tQtWHNdertog== X-IronPort-AV: E=McAfee;i="6000,8403,9821"; a="234293138" X-IronPort-AV: E=Sophos;i="5.78,382,1599548400"; d="scan'208";a="234293138" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Nov 2020 10:34:58 -0800 IronPort-SDR: xX8pAokTZQ0by/OWyYuiZnRxDCsiivurak+f9Xio3lW5hHeX3PJBzd1v964Jp8IInY4mofl8d4 qRQYh4IGYIMg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.78,382,1599548400"; d="scan'208";a="537100801" Received: from marshy.an.intel.com (HELO [10.122.105.143]) ([10.122.105.143]) by fmsmga006.fm.intel.com with ESMTP; 30 Nov 2020 10:34:57 -0800 Subject: Re: [PATCHv2 1/5] firmware: stratix10-svc: add COMMAND_AUTHENTICATE_BITSTREAM flag To: Moritz Fischer Cc: gregkh@linuxfoundation.org, trix@redhat.com, linux-fpga@vger.kernel.org, linux-kernel@vger.kernel.org, dinguyen@kernel.org, sridhar.rajagopal@intel.com, richard.gong@intel.com References: <1605709753-7800-1-git-send-email-richard.gong@linux.intel.com> <1605709753-7800-2-git-send-email-richard.gong@linux.intel.com> From: Richard Gong Message-ID: <771ba4f4-59e1-74b0-ba55-3f65914e2bc7@linux.intel.com> Date: Mon, 30 Nov 2020 12:55:44 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Moritz, Sorry for late reply, I was out last week. On 11/21/20 7:10 PM, Moritz Fischer wrote: > Richard, > > On Wed, Nov 18, 2020 at 12:16:09PM -0600, Richard Gong wrote: > >>>> -#define COMMAND_RECONFIG_FLAG_PARTIAL 1 >>>> +#define COMMAND_RECONFIG_FLAG_PARTIAL 0 >>>> +#define COMMAND_AUTHENTICATE_BITSTREAM 1 >>> >>> Can you explain how this commit by itself doesn't break things? >>> >>> Before this change firmware expected BIT(0) to be set for partial >>> reconfiguration, now BIT(0) suddenly means authentication? How doest his >>> work? :) >>> > Was there a firmware version change? Did this never work before? >>> >>> If this is version depenedent for firmware, then this might need a >>> different compatible string / id / some form of probing? >>> >>> Entirely possible that I'm missing something, but it doesn't *seem* >>> right. >> >> It did work before. >> >> Before this change, firmware only checks if the received flag value is zero. >> If the value is zero, it preforms full reconfiguration. Otherwise it does >> partial reconfiguration. >> >> To support bitstream authentication feature, firmware is updated to check >> the received flag value as below: >> 0 --- full reconfiguration >> BIT(0) --- partial reconfiguration >> BIT(1) --- bitstream authentication > > So there are two different versions of firmware involved that behave > differently? > > Old firmware: > - ctype.flags = 0x0 -> Full reconfig > - ctype.flags != 0 -> Partial reconfig > > New firmware: > - ctype.flags = 0x0 -> Full reconfig > - ctype.flags = 0x1 -> Partial reconfig > - ctype.flags = 0x2 -> Authenticate > > Old software: > - Send 0x0 for Full > - Send 0x1 for Partial > > New software: > - Send 0x0 for Full > - Send 0x1 for Partial > - Send 0x2 for Auth > > If I send request for authentication BIT(1) (new software) to old > firmware it'd try and attempt a partial reconfiguration with the data I > send? Is that safe? > Yes, it is possible and it is not safe. But we will inform our customers they should update to the latest firmware (SDM firmware and ATF) if they want to have authentication feature. We are migrating boot loader boot flow to the new ATF boot flow, which is SDM firmware -> SPL -> ATF -> U-boot proper -> Linux. The new authentication feature is supported only in the new ATF boot flow. ATF communicates with SDM firmware via mailbox, and SDM firmware performs the actual full/partial reconfiguration and bitstream authentication. ATF sets up EL3 environment and initializes PSCI services. The old boot flow is SDM firmware -> SPL -> U-boot proper -> Linux, which SPL/U-boot handles PSCI services and communicates with SDM firmware via mailbox. SDM firmware performs the actual full/partial reconfiguration. ATF = Arm Trust Firmware, SDM = Secure Device Manager > Is there a way for software to figure out the firmware version and do > the right thing? It is not feasible for kernel driver to get the firmware version per current designs and implementations. I don't think there is other way around this. > >> Therefore I have updated the command flag setting at Intel service layer >> driver to align with firmware. >> >> Regards, >> Richard >> >>>> /** >>>> * Timeout settings for service clients: >>>> -- >>>> 2.7.4 >>>> >>> >>> Cheers, >>> Moritz >>> > > Thanks, > Moritz > Regards, Richard