Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTDEV

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

Hw IDs and re-purposing of FPGA silicon, Security

rusakov2rusakov2 Member Posts: 24

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

Comments

  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,426

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

  • rusakov2rusakov2 Member Posts: 24

    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?

  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,426

    Sure but you modified the boot firmware by doing that.

  • rusakov2rusakov2 Member Posts: 24

    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 ?

  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,426

    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?

  • rusakov2rusakov2 Member Posts: 24

    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

  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,426
    via Email
    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
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Developing Minifilters 24 May 2021 Live, Online
Writing WDF Drivers 14 June 2021 Live, Online
Internals & Software Drivers 2 August 2021 Live, Online
Kernel Debugging 27 Sept 2021 Live, Online