Re: [RFC PATCH] fpga: region: Add support for FPGA region variants

[Marco Pagani <marco.pagani@linux.dev>]

On 17/08/2026 05:06, Xu Yilun wrote:
>>> But if the no-verification-in-driver is denied, I think the thing we
>>> need to do is to verify the binding between the DT description & image.
>>> After we've verified the DTO & the image is a valid pair, they are not
>>> arbitrary, whatever the DTO does is necessary to the updated hardware.
>>
>> I think we agree on this. Ideally, we should validate the complete
>> {config, image} pair. However, I don't see how using DTO at runtime can
>> help with this goal.
> 
> Validation is not the goal. Re-enumeration is the goal. DTO is what FPGA
> is now using for re-enumeration. Validation helps DTO if you want extra
> integrity.

I would argue that validation is a requirement for any userspace
interface, while I do agree that re-enumeration is the goal. In my RFC,
re-enumeration is triggered using the DT infrastructure every time
userspace switches from one variant to another. Variants can be thought
of as pre-validated DT fragments baked into the base DT, rather than
DTOs ingested from userspace at runtime.

To clarify my position, going back to a couple of messages ago:

- As I understand it, the current upstream consensus is that hardware
  devices must be responsible for verifying their own firmware.
  So, the kernel is responsible for protecting the integrity of its
  own configuration (live DT), while the reconfiguration engine is
  responsible for validating FPGA images;

- If this is not sufficient, and there is a requirement to secure
  /lib/firmware, it should be done at the filesystem level using
  the IMA subsystem;

- However, since not all FPGA reconfiguration engines support crypto
  image verification, and not all SoCs/platforms have a TPM IP or
  support for a TEE, we might consider having a subsystem-specific and
  optional check for the {config, image} pair as a *future* extension.


>> On the contrary, it would put us in a situation
>> where neither element of the pair is guaranteed since it enables the
>> user to feed arbitrarily forged DTOs.
> 
> As you referenced, no OS component (even the kernel) could guarantee the
> functionality of the binary for a device, only the device can. So what's
> the difference who provides the pair?
> 
> The only thing matters here is integrity and authentication, which is
> totally a different thing from kernel-user privilege.
> 
> I'm also confused you keep on telling that userspace is arbitrary so no
> userspace interface, which seems to suggest kenrel should never get any
> input from user.

My concern isn't about accepting user input in general but rather about
the type and scope of that input. I think there is a huge difference in
terms of the security between:

- matching a string that userspace sent via sysfs and then applying a
  safe configuration already contained in the base DT (validated from
  a FIT image).

- having userspace directly pass the kernel DT configuration (as a DTO),
  which the kernel must then validate (both syntactically and
  semantically) and apply.

In the first scenario, userspace is like a customer selecting from a
menu of pre-approved dishes, and then the kitchen safely prepares it.

In the second scenario, userspace is like a customer stepping into the
kitchen to cook their own meal, forcing the chef to constantly supervise
them to ensure they don't burn the place down.


>>> It is possible. To be more efficient, I think we should invite
>>> boarder discussions.

Following up on what you said two messages ago, I think we should invite
the DT people and ask for their input to help move this conversation
forward.


Thanks,
Marco