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

[Marco Pagani]

On 17/08/2026 18:14, Marco Pagani wrote:
> 
> 
> 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.

Hi Yilun,

Is it okay with you if I CC the DT people to ask for an opinion?

$ scripts/get_maintainer.pl drivers/of
Rob Herring <robh@xxxxxxxxxx> (maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE)
Saravana Kannan <saravanak@xxxxxxxxxx> (maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE)
devicetree@xxxxxxxxxxxxxxx (open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE)
linux-kernel@xxxxxxxxxxxxxxx (open list)


Thanks,
Marco