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

[Marco Pagani <marco.pagani@linux.dev>]

On 30/06/2026 16:58, Xu Yilun wrote:
> On Tue, Jun 30, 2026 at 11:39:50AM +0200, Marco Pagani wrote:
>>
>>
>> On 26/06/2026 14:58, Xu Yilun wrote:
>>> On Mon, Jun 08, 2026 at 06:42:45PM +0200, Marco Pagani wrote:
>>>> This RFC proposes a proof-of-concept implementation of FPGA region
>>>> variants, a mechanism that introduces a common way to handle
>>>> dynamic partial reconfiguration from userspace. The proposed approach
>>>
>>> There are many threads talking about userspace reconfiguration, the
>>> latest one is this:
>>>
>>> https://lore.kernel.org/linux-fpga/20250519033950.2669858-1-nava.kishore.manne@amd.com/
>>>
>>> Before we dive into detail, could you help tell why the previous one
>>> won't work so we must switch to the new interface.
>>
>> I think that Nava's latest RFC and older proposals for userspace FPGA
>> configuration are in effect functionally equivalent to Antoniou's RFC
>> for runtime DT changes via ConfigFS. In other words, they get around
> 
> I think it is different. Arbitrarily changing any hardware is
> problematic, it doesn't align with how the hardware works. But changing
> the hardware inside an FPGA region is exactly the functionality of an
> FPGA. As long as we stay within the scope of fpga_region, I don't see
> the immediate problem.

I agree that changing the hardware is the normal use case for FPGA.
However, my point is that allowing userspace to arbitrarily change the
hardware configuration/topology of the kernel at runtime by loading a DT
overlay through ConfigFS opens a considerable attack vector, and this is
what led to Antoniou's RFC being rejected in the first place.

>> the limitations of the current mainline kernel by using a different
>> implementation of the same core idea behind Antoniou's RFC, but do not
>> address the fundamental concerns that led to it being NACKed.
>>
>> Concerning Nava's latest RFC, scoping the ConfigFS entry point to
>> /sys/kernel/config/fpga_region/ does not change the underlying code path
>> in the kernel and leaves the same attack vector open. Userspace can
>> still load any arbitrary hardware configuration at runtime and mess up
>> with registers, clocks, DMA mappings, etc. to attack the kernel from
>> "below" accessing potentially sensitive memory areas.
> 
> If the implementation does go outside fpga_region, fix it.

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.

>>
>> Conversely, this RFC addresses these concerns by constraining possible
>> configurations to a limited and statically-defined set that can be
>> authenticated as part of the DT at boot time to maintain the chain
>> of trust. This is in accordance with the kernel's security model
> 
> I'm not sure why a DT at boot time could be verified as trusted while a
> runtime overlay can't. Root of trust has anything to do with boot time
> or runtime?
> 
> Or do you mean a DT boot time authentication could ensure the DT
> description exactly match the content of a bin file (variant1-image.bin)
> on disk, how?

I mean, the base DT of a system can be authenticated at boot-time
using a signed FIT image. Since FPGA variants are statically defined
within the base DT, their configurations are also authenticated
(together with the kernel) to maintain a chain of trust. However, I
think the main benefit of the variants approach is that it guarantees
better security and practicality by default, even without boot image
authentication, as it leaves no doors open for userspace to modify the
kernel hardware configuration/topology.

On the contrary, while runtime DT overlays could theoretically be
secured, enforcing mandatory signature verification for every DTBO
loaded through ConfigFS at runtime is highly impractical as it
introduces key-management complexities that would make the approach
cumbersome for many use cases. Conversely, leaving the interface as
it is now in Nava's RFC fundamentally trusts userspace to dynamically
change the kernel's hardware configuration/topology, and this again
leaves the attack vector open.

>> which holds that userspace cannot be trusted to define hardware.
> 
> I'm not sure, my understanding is FPGA programing is much like firmware
> loading, whose correctness/trusty can't be ensured by kernel security
> model. Only cryptography can help. Without crypto, kernel still loads
> the selected binary, if it corrupts, let it corrupt.

It is true that the kernel allows to load arbitrary firmware blobs at
runtime. However, those are for configuring/programming only the device
hardware and not for the kernel itself. What is particularly dangerous
with runtime DT overlays is that they can change not only the device's
firmware/image but also the kernel configuration/toplogy itself.
A single malicious DT overlay can compromise the entire kernel and
hence the system, not just the FPGA fabric.


Thanks,
Marco