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

On 22/07/2026 13:22, Xu Yilun wrote:
>> If I understood correctly, your main concern is that having to specify
>> all region variants at boot time is verbose and limiting. I see your
> 
> Yes, that's my concern. We are pursuing a userspace re-programming
> interface for long time. I don't want to easily switch to a whitlist
> based interface, which is as you said verbose and limiting. The DTO has
> vulnerabilities but I'm not convinced yet it can't be secured.

I think the main problem with having an "open" userspace DTO interface
is that it would force the kernel to act as a runtime DT validator,
and this goes beyond the responsibilities of a kernel.

DT validation should be done statically at compilation time (make
CHECK_DTBS=y...) and not burden the kernel at runtime in terms of
compute time and, even more importantly, security. My fundamental
concern is that such a runtime DT validator exposed to userspace
will create a weak spot that every potential attacker will aim for.

On a more subtle level, even if we had a perfect runtime DT validator,
we could still not guarantee security. A malevolent userspace component
could forge a syntactically correct but semantically malicious DTO to
mount an attack. For instance, consider a malicious DTO defining a
smaller dma-ranges (that would pass the DT validator limits check) for
the new node just to force DMA buffer allocation to fail and then mount
a side channel attack. This is really an open-ended can of worms.

In a certain sense, variants can be thought of as a statically defined
and pre-validated list of DTOs. I think this fits better the current
device tree infrastructure that has been designed to handle a static
hardware description that does not change at runtime.

Concerning the verbosity, I think in practice region variants can be
defined as DT fragments (dtsi) without burdening the main dts. These
fragments could be auto-generated by the tooling starting from a
hardware description, like what PetaLinux is already doing to a
certain extent.


>> point. However, I still think that a statically-defined whitelist of
>> variants is the most pragmatic approach, as it guarantees the best
>> security while matching the actual FPGA design phase, where
> 
> I actually still don't understand how static DT can be more secure if it
> references global resources. How could people verify a static DT is
> correctly describing a blob on disk? And the blob can be changed by
> userspace. If no, it still ends up with manipulating global resources
> without reason.

I see your point and agree that neither the variants nor the DTO
interface can prevent a malicious userspace component from swapping
a valid image/bitstream with a rogue one. However, only the variants
approach guarantees the immutability (from userspace) of the kernel's
configuration/topology:

(i) The base DT (including variant fragments) is built and global
resources are statically resolved at compile time. Then, the resulting
DTB is loaded by the kernel at boot time before userspace is loaded and
can be authenticated (as part of a FIT image) to maintain the chain of
trust.

(ii) Once the boot is completed and userspace is running, the kernel
hardware configuration/topology remains safe and locked in place since
there are no interfaces that allow userspace to change it.

So I think the main advantage of the variants compared to the open DTO
interface is limiting the "blast radius" in case things go wrong.
If the DT cannot be tampered with, the kernel can still enforce hardware
boundaries (e.g., IOMMU config) that can contain the spill to the
misbehaving region's resources. On the contrary, a single malicious DTO
can compromise the entire kernel with its memory mappings.

Ultimately, I think the responsibility of authenticating image/bitstream
is outside the scope of the kernel as they are configurations for the
hardware and not the kernel itself. It's up to the device to
authenticate its own firmware, like how reconfiguration engines of
modern FPGA families can already authenticate signed image/bitstreams.


>> reconfigurable regions are floorplanned and synthesized, naturally
>> resulting in a statically-defined set of partial images/bitstreams with
>> their corresponding kernel configurations.

Thanks,
Marco