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?