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

[Xu Yilun]

On Fri, Sep 18, 2026 at 05:07:07PM +0200, Marco Pagani wrote:
> 
> 
> 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?

Of course. It's good to know in which case could a DTO be applied.

But to be clear, I think that only affects how we accept and apply the
image-DTO pair. For now, I basically don't want a varient selection
interface.

> 
> $ 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
>