Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::3:1 as permitted sender) client-ip=2620:137:e000::3:1;
Message-ID: <b003c0ca-b5c7-4082-a391-aeb04ccc33ca@amd.com>
Date:   Tue, 10 Oct 2023 15:07:41 +1100
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH 00/12] PCI device authentication
Content-Language: en-US
To:     Lukas Wunner <lukas@wunner.de>,
        Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc:     Dan Williams <dan.j.williams@intel.com>,
        Bjorn Helgaas <helgaas@kernel.org>,
        David Howells <dhowells@redhat.com>,
        David Woodhouse <dwmw2@infradead.org>,
        Herbert Xu <herbert@gondor.apana.org.au>,
        "David S. Miller" <davem@davemloft.net>,
        Alex Williamson <alex.williamson@redhat.com>,
        linux-pci@vger.kernel.org, linux-cxl@vger.kernel.org,
        linux-coco@lists.linux.dev, keyrings@vger.kernel.org,
        linux-crypto@vger.kernel.org, kvm@vger.kernel.org,
        linuxarm@huawei.com, David Box <david.e.box@intel.com>,
        Dave Jiang <dave.jiang@intel.com>,
        "Li, Ming" <ming4.li@intel.com>, Zhi Wang <zhi.a.wang@intel.com>,
        Alistair Francis <alistair.francis@wdc.com>,
        Wilfred Mallawa <wilfred.mallawa@wdc.com>,
        Tom Lendacky <thomas.lendacky@amd.com>,
        Sean Christopherson <seanjc@google.com>,
        Alexander Graf <graf@amazon.com>
References: <cover.1695921656.git.lukas@wunner.de>
 <652030759e42d_ae7e72946@dwillia2-xfh.jf.intel.com.notmuch>
 <20231007100433.GA7596@wunner.de> <20231009123335.00006d3d@Huawei.com>
 <20231009134950.GA7097@wunner.de>
From:   Alexey Kardashevskiy <aik@amd.com>
In-Reply-To: <20231009134950.GA7097@wunner.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TTFscXh3OW1JbVYwWm1RQTB0VzQ5dkVvR2hDa0N0dHRwWS9Jbkh2MWtiRjl2?=
 =?utf-8?B?NVp6N2JaR2RSK1ZoL3Nad1p2eERJU2RRaWdGTy9KdjVtbWpqL0RTWlpDZEZU?=
 =?utf-8?B?dm9HN2dCR1liaHRIR1lwSnZvbXordHphQUZhSUcvcENVdWp5VTViQXhDTlh1?=
 =?utf-8?B?aE13dG5IQmlOS2J3UDZtRjBhcE4ySm5HLzVPcnZaT1RwT0RoVlNTS0FzSjRK?=
 =?utf-8?B?VU1iTHh0TStsbzQ4WVl5amtiMGNTN0ZhWTUxeGFJOVhLYUpNeEd2eUIxTEhI?=
 =?utf-8?B?VnFpNklOUDZPQUJ3TUlhWFZyTWhjMlhyVTd3eVlwaFZPR2tUMHZJL1BJektL?=
 =?utf-8?B?MHoxL0V3U1liZGc4RmNZa0JrQlFhM3doeEJ1c3M2em95RVJzbkJwSlhLQVRH?=
 =?utf-8?B?OTR1MjdlamZEeW8wWTVHandCUnRMMjkvTk5Cclg1UEpMbFBGbGxWMnhXMTg1?=
 =?utf-8?B?bGhrVVJTNEhybThHL1BzUWVVUWNUMmg0cFc2cHVsY1Uza0Y4a1FQdWQxbXlm?=
 =?utf-8?B?ZWwzM1hFeVB1SnNmRGh1anRqWEl0L3gyR2lPdU52aWJIUnVKTHRjdWt2dGp0?=
 =?utf-8?B?RFhqMjlrTlo0dmRuQlYvMXNXN1RoYXZNcnBjSDhHeWp1OWNMV01SeVZIdk80?=
 =?utf-8?B?UzVpUkIvZTZrUWJJOVd4dCtnUmdzaDVTZ2dPTWwra1IwK1dYejB5WVNDNVpF?=
 =?utf-8?B?Y1JJMVE0eWJNei9pSzJzbzF6YWZvTlhJTURnOUEyeGZvbTBDWWQzSzdSZ1hN?=
 =?utf-8?B?bFlMZmZzQ1IvblFOT2Q0Y29lUmdnZUU2eE8xN2diYUhmeFJYclFhSk8xMUND?=
 =?utf-8?B?Ym0wTmhpQVhNYUYvS0F2TTNITFRRZHozaTdEY3UrMmZWUHpIM0xUVGpjSHNu?=
 =?utf-8?B?YnlUYWNXR3J2VjdyYkxHalhjL0EycUtkNU5HY2wyRjFDdml5TUh1THVRSTFD?=
 =?utf-8?B?OXA3aHU2eHdhMng2WHJPeTlnVzdYcUZEYnhPazFJSXVjYzFGUllMVGl2WmZI?=
 =?utf-8?B?bHd4amRpMkRFTTJKRWJ4THdobEg5a2dNemg4TGlSTjBYUXNMZGlKRzM2U0RX?=
 =?utf-8?B?N3RjN0NnQWxtbE1ZMU5DVVhSMWM3dEdkNktldDdGN1lCS1FzbWZOV1lubzZT?=
 =?utf-8?B?VlBUbE9NVjNuT1hCdFQxSHF5Zm5IbVRDUmRXUFpmZDZ2RENXS0QvN2NGakVV?=
 =?utf-8?B?NFVGaXo1R2JheU1yOTV5YitlMGFOKy9XaGNkS2FsMHk3Q0s1bWlMSmpXdHYr?=
 =?utf-8?B?dlFSSzhhcHdDSm5xQ3dGNFIvQllGbHdQY1dYdFI4ZXc1MFZvZlpNRVJTSm50?=
 =?utf-8?B?OVpIODQ1NGx2K0V3UGs5YUl5YlRGVkhEdkhlTzRSLzVkZ0VaU1VIUGFIbjl3?=
 =?utf-8?B?MmNUUlA5bHpvUmg5bnRiNVJmaGIzMmFvTlMxMHZveGdkVmp5eXVOYWdKMGhQ?=
 =?utf-8?B?Y0c3YTU2TXFiRXgvSko1ZzVudjdOSmJsZDRpTnNDamYyVGdESEdhWTdrRVNO?=
 =?utf-8?B?eEtRRnpkTHJrd0Z0dWNPNEpyZjN1M3lNR20vdlpRUTlIanJ5RTNEb2ZYZGJM?=
 =?utf-8?B?dHMrayttN1VndXV1Tlhqd2JXbWkzMVFSTmRvVlNadXd1eXNWWmE4SE5RdHJI?=
 =?utf-8?B?TS9sL0tETzJ3UFcxZ3hPWS9ZVTZ0RGdpZjJJSEFXKzF4L3JmbGpqRXNWcnQx?=
 =?utf-8?B?bFFPRmc1QnowKzhjS1BETVVvRElYazhoem9EV0dTdWR2YytLVnZuWGlOLzRJ?=
 =?utf-8?B?M1g5L1E1REpzRWs4d2YrbSt4c24vYlI2a21BRU9IRXJoSGg2dXpjMmlYeHR4?=
 =?utf-8?B?dy9VMXhiK1NsQjlIc2NsWGpiTjhSM0dDL29qN1p6UWhMVnJXQjcya1B6UVRE?=
 =?utf-8?B?S0tTQms5ZkVXWjNydG9BbzJ6akR5UXBWNElXMTAyZWV1cnpmNlYya2ErUmgv?=
 =?utf-8?B?T0FraC91Z2IvOHdkUkR6bG5pRmhnQTE4VnVuNDhJMFdjNElGeURiN2ZWdmtu?=
 =?utf-8?B?MlFaMjZMbG5YU2F1dC83VGV4V0h0ck1MQUdHT2laNXlZNnNZOEpCc1hxUERq?=
 =?utf-8?B?VFVNV0wzeDhGLzlDTTJxUURVTC91OXdVdFhiZHdTV2dnTTRsYWJSVm0zQXNM?=
 =?utf-8?Q?2sXJaay40Xbo3z+uTMLc/kIXp?=
X-OriginatorOrg: amd.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0841404f-5fde-437f-801b-08dbc9467c94
X-MS-Exchange-CrossTenant-AuthSource: CH3PR12MB9194.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Oct 2023 04:07:58.2609
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: aF9yNIV4yXER+Zr8s1GApZAZ2PeGjHELtyqfXCC8tILrwU1Zdz0mzbo5Wsu7Yg0/QyQ+Boo5W4yKDJxrTAjvyQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR12MB4591
X-Spam-Status: No, score=2.7 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,RCVD_IN_SBL_CSS,SPF_HELO_NONE,SPF_PASS autolearn=no
	autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on morse.vger.email
Precedence: bulk
List-ID: <linux-crypto.vger.kernel.org>
X-Mailing-List: linux-crypto@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (morse.vger.email [0.0.0.0]); Mon, 09 Oct 2023 21:08:16 -0700 (PDT)
X-Spam-Level: **

On 10/10/23 00:49, Lukas Wunner wrote:
> On Mon, Oct 09, 2023 at 12:33:35PM +0100, Jonathan Cameron wrote:
>> On Sat, 7 Oct 2023 12:04:33 +0200 Lukas Wunner <lukas@wunner.de> wrote:
>>> On Fri, Oct 06, 2023 at 09:06:13AM -0700, Dan Williams wrote:
>>>> Linux also has an interest in accommodating opt-in to using platform
>>>> managed keys, so the design requires that key management and session
>>>> ownership is a system owner policy choice.
>>>
>>> You're pointing out a gap in the specification:
>>>
>>> There's an existing mechanism to negotiate which PCI features are
>>> handled natively by the OS and which by platform firmware and that's
>>> the _OSC Control Field (PCI Firmware Spec r3.3 table 4-5 and 4-6).
>>>
>>> There are currently 10 features whose ownership is negotiated with _OSC,
>>> examples are Hotplug control and DPC configuration control.
>>>
>>> I propose adding an 11th bit to negotiate ownership of the CMA-SPDM
>>> session.
>>>
>>> Once that's added to the PCI Firmware Spec, amending the implementation
>>> to honor it is trivial:  Just check for platform ownership at the top
>>> of pci_cma_init() and return.
>>
>> This might want to be a control over the specific DOE instance instead
>> of a general purpose CMA control (or maybe we want both).
>>
>> There is no safe way to access a DOE to find out if it supports CMA
>> that doesn't potentially break another entity using the mailbox.
>> Given the DOE instances might be for something entirely different we
>> can't just decide not to use them at all based on a global control.
> 
> Per PCIe r6.1 sec 6.31.3, the DOE instance used for CMA-SPDM must support
> "no other data object protocol(s)" besides DOE discovery, CMA-SPDM and
> Secured CMA-SPDM.
> 
> So if the platform doesn't grant the OS control over that DOE instance,
> unrelated DOE instances and protocols (such as CDAT retrieval) are not
> affected.
> 
> E.g. PCI Firmware Spec r3.3 table 4-5 could be amended with something
> along the lines of:
> 
>    Control Field Bit Offset: 11
> 
>    Interpretation: PCI Express Component Measurement and Authentication control
> 
>    The operating system sets this bit to 1 to request control over the
>    DOE instance supporting the CMA-SPDM feature.
> 
> You're right that to discover the DOE instance for CMA-SPDM in the
> first place, it needs to be accessed, which might interfere with the
> firmware using it.  Perhaps this can be solved with the DOE Busy bit.
> 
> 
>> Any such control becomes messy when hotplug is taken into account.
>> I suppose we could do a _DSM based on BDF / path to device (to remain
>> stable across reenumeration) and config space offset to allow the OS
>> to say 'Hi other entity / firmware are you using this DOE instance?"
>> Kind of an OSC with parameters.  Also includes the other way around that
>> the question tells the firmware that if it says "no you can't" the OS
>> will leave it alone until a reboot or similar - that potentially avoids
>> the problem that we access DOE instances already without taking care
>> about this
> 
> PCI Firmware Spec r3.3 table 4-7 lists a number of _DSM Definitions for
> PCI.  Indeed that could be another solution.  E.g. a newly defined _DSM
> might return the offset in config space of DOE instance(s) which the OS
> is not permitted to use.
> 
> 
>> (I dropped ball on this having raised it way back near start
>> of us adding DOE support.)
> 
> Not your fault.  I think the industry got a bit ahead of itself in
> its "confidential computing" frenzy and forgot to specify these very
> basic things.
> 
> 
>> If we do want to do any of these, which spec is appropriate?  Link it to PCI
>> and propose a PCI firmware spec update? (not sure they have a code
>> first process available) or make it somewhat generic and propose an
>> ACPI Code first change?
> 
> PCI Firmware Spec would seem to be appropriate.  However this can't
> be solved by the kernel community.

How so? It is up to the user to decide whether it is SPDM/CMA in the 
kernel   or   the firmware + coco, both are quite possible (it is IDE 
which is not possible without the firmware on AMD but we are not there yet).

But the way SPDM is done now is that if the user (as myself) wants to 
let the firmware run SPDM - the only choice is disabling CONFIG_CMA 
completely as CMA is not a (un)loadable module or built-in (with some 
"blacklist" parameters), and does not provide a sysfs knob to control 
its tentacles. Kinda harsh.

Note, this PSP firmware is not BIOS (which runs on the same core and has 
same access to PCI as the host OS), it is a separate platform processor 
which only programs IDE keys to the PCI RC (via some some internal bus 
mechanism) but does not do anything on the bus itself and relies on the 
host OS proxying DOE, and there is no APCI between the core and the psp.


>  We need to talk to our confidential
> computing architects and our representatives at the PCISIG to get the
> spec amended.
> 
> Thanks,
> 
> Lukas

-- 
Alexey