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

> (i) The base DT (including variant fragments) is built and global
> resources are statically resolved at compile time. Then, the resulting
> DTB is loaded by the kernel at boot time before userspace is loaded and
> can be authenticated (as part of a FIT image) to maintain the chain of
> trust.

That helps, thanks.

> 
> (ii) Once the boot is completed and userspace is running, the kernel
> hardware configuration/topology remains safe and locked in place since
> there are no interfaces that allow userspace to change it.
> 
> So I think the main advantage of the variants compared to the open DTO
> interface is limiting the "blast radius" in case things go wrong.

But I don't think limiting both the functionality and the blast radius can
be the target of the uAPI.

> If the DT cannot be tampered with, the kernel can still enforce hardware
> boundaries (e.g., IOMMU config) that can contain the spill to the
> misbehaving region's resources. On the contrary, a single malicious DTO
> can compromise the entire kernel with its memory mappings.
> 
> Ultimately, I think the responsibility of authenticating image/bitstream
> is outside the scope of the kernel as they are configurations for the
> hardware and not the kernel itself. It's up to the device to
> authenticate its own firmware, like how reconfiguration engines of
> modern FPGA families can already authenticate signed image/bitstreams.

No I don't think so. It's the kernel drivers decision to load the image
to HW, authenticate or not authenticate the image, via an HW engine or by
software.

Basically you are treating the HW description blob and the HW image blob
differently, but I think they are basically one thing that can't be
torn apart. If you want security, you must build trust for both the image +
the HW description before re-program and re-enumerate.

I remember there was a discussion of accepting a FIT image for
re-programming several years ago.

> 
> 
> >> reconfigurable regions are floorplanned and synthesized, naturally
> >> resulting in a statically-defined set of partial images/bitstreams with
> >> their corresponding kernel configurations.
> 
> Thanks,
> Marco
>