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

[Xu Yilun]

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@xxxxxxx/
> > 
> > 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.

> 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.

> 
> 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?

> 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.