Hw IDs and re-purposing of FPGA silicon, Security

Hello,
hope you the experts may advise on this question.

A customer has a system with expensive FPGA silicon in it, connected via PCIe, and it is set up as

VEN_nnnn DEV_001 SUBSYS_0001mmmm REV_01
Class code=0x11 - Signal Processing Controller
Subclass=0x80 - Other
Prog IF=0
Revision ID=1

and there is a driver for it installed and running.

Now customer says they want some AI support and no longer benefit from DSP much. So customer asks if we can re-configure existing FPGA silicon as AI accelerator. Sure, new synthesis and customer now has powerful AI accelerator using the same hw.
There will be a different driver for the same FPGA as its function changed from DSP to AI accelerator.

We then need to change PCIe configuration space from DSP case to AI accelerator case, for the same FPGA silicon, so that different PCIe driver will load. I can do it, but asking what to choose with minimum disruption of customer.

Customer has Windows 10 secure system - secure boot, bitlocker, and FIPS enabled.

Am I changing hw or not? Yes and no.
YES: The FPGA silicon will now behave very different, so yes I change hw. As if I unplug DSP PCIe card and insert another PCIe card.
NO: No I do not unplug and plug anything, it is the same enclosure and the very same FPGA silicon soldered permanently onto main board.

If I change hw then Windows security will trigger and will ask for bitlocker key. Customer needs to know it, and ideally we want to avoid this situation.

Q: what parameter combination in PCIe config space is captured by Windows 10 secruity to watch for HW changes ?

Examples in my case

VEN_nnnn DEV_001 SUBSYS_0001mmmm REV_01
Class code=0x11 - Signal Processing Controller
Subclass=0x80 - Other
Prog IF
Revision ID=1
→ will load driver_M

if changed to

VEN_nnnn DEV_003 SUBSYS_0001mmmm REV_01 (changed DEV and class code)
Class code=0x12 - Processing Accelerator
Subclass=0x80 - Other
Prog IF
Revision ID=1
→ will load driver_A

or if changed to

VEN_nnnn DEV_001 SUBSYS_0003mmmm REV_01 (changed SUBSYS and class code)
Class code=0x12 - Processing Accelerator
Subclass=0x80 - Other
Prog IF
Revision ID=1
→ will load driver_A

or if changed to

VEN_nnnn DEV_001 SUBSYS_0001mmmm REV_03 (changed REV and class code)
Class code=0x12 - Processing Accelerator
Subclass=0x80 - Other
Prog IF
Revision ID=1
→ will load driver_A

Thanks,
Sergey

I though secure boot only measured boot path devices. Is your fpga part of a boot device?

No, this FPGA is not in boot path.
But I am not clear on this. If I enter UEFI and modify hw list, say disable PCIe port 2, is it a hw change, and then as I recall upon saving UEFI and into Windows 10 boot there will be bitlocker key request? Is it because any change in UEFI is considered be in a boot path?

Sure but you modified the boot firmware by doing that.

Yes, by disabling PCIE port 2 I modified platform hw configuration and that is treated as change of boot firmware. But PCIe port 2 is not in boot bath for this system. In fact there is no bootable device connected to PICe port 2.

So, if my FPGA is connected to PCIe port 3. I do not change any PCIe settings in UEFI.
But I change FPGA PCIe configuration space so that the same end point attached to port 3 will now appear as different end point (to UEFI and to Windows).
Am I modifying boot firmware or not ?

The firmware was modified in your first example and the firmware is part of the measured boot. In your second example, basically a new non-boot device was plugged into the system. I do not think that will cause a secure boot recovery. As I said to begin with only the firmware itself and the boot path device(s) are measured. If adding a new pcie device to a system forced a SB recovery it would be essentially a useless feature and nobody would be using it. But really a simple experiment out to settle this, right?

The experiment is planned, yes. It is simple in nature but may take a while to acquire one actual system from customer back to us to play with it.
The device in question is a specialized secure system which is designed to be protected from hw change, as such hw change would point to an intrusion attempt. Conceptually similar to an alarm on server triggered when its case was opened (as let open server case would allow intruder to plug in any untrusted PCIe card and then compromise system). I hope it is not the case but will see.
Thank you

So what you described is somewhat different. Your system may have its own
custom firmware that might in fact consider non-boot hw changes as
‘insecure’. You ought to conduct your experiment ASAP.

Mark Roddy