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

Xu Yilun <[email protected]> Tue, 7 Jul 2026 16:02:47 +0800
Newsgroups org.kernel.vger.linux-fpga,org.kernel.vger.linux-kernel
Message-ID <akyyp1GCecWj2Bk2@yilunxu-OptiPlex-7050>
> 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 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.

How do you think?