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

On 07/07/2026 10:02, Xu Yilun wrote:
>> My understanding is that Nava's RFC already scopes the configuration to
>> /sys/kernel/config/fpga_region/. However, that would still leave the
>> attack vector open. A malevolent userspace component could still load a
>> malicious DT overlay with a rogue "ranges" property to access kernel
>> memory or a rouge "dma-ranges" property to hijack a legitimate IP for
>> the same purpose, or it can mess with the clock configuration. It also
>> worth considering that DT changes are applied to the global kernel
>> hardware configuration and cannot be sandboxed to the specific FPGA
>> region. The root of the problem is that we cannot check and guarantee
>> at runtime that an arbitrary DT overlay is sane and affects only its
>> specific FPGA region.
> 
> I see. So your concern is the DT overlay can impact the outside world by
> referencing global nodes. My idea is, if we could statically specify the
> fpga-region with these assigned resources, no updating of these static
> properties, and don't allow global referencing phandle, we are good?

I think I see what you mean: since the hardware interface of the region
is fixed and defined during the design phase, we could enforce the
resource boundaries (e.g., ranges, dma-ranges, interrupts, clocks, etc.)
defined in the base DT. This is certainly true. However, I think the
fundamental problem is that safely enforcing these boundaries in-kernel
at runtime remains very challenging.

As far as I know, there isn't a way to sandbox changes made by
of_overlay_fdt_apply(), as it simply digests what it is fed and applies
it globally against the live tree. Therefore, we would need to add a
runtime DT verifier that parses and validates DTO blobs, before calling
of_overlay_fdt_apply(), to ensure that they don't contain rogue global
phandles, and touch only nodes defined in the region. Adding such a
runtime DT verifier seems to me an over-complicated and inherently
fragile approach. Moreover, it can add a weak spot that attackers might
constantly attempt to exploit. Ultimately, I think that a static
whitelisting approach carries many benefits in security, simplicity, and
maintainability over building and maintaining a runtime verifier directly
exposed to userspace.

> I mean we don't have to verbose on every combination of hardware that a
> user might load. We harden the boundaries of the resources (ranges,
> dma-ranges, ...) that are initially designed for the fpga-region in base
> DT. To me, this seems to be more aligned to "DT describes the HW" and
> how the FPGA works.

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


Thanks,
Marco