From: Xu Yilun <yilun.xu@linux.intel.com>
To: Marco Pagani <marco.pagani@linux.dev>
Cc: Moritz Fischer <mdf@kernel.org>, Xu Yilun <yilun.xu@intel.com>,
Tom Rix <trix@redhat.com>,
linux-fpga@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] fpga: region: Add support for FPGA region variants
Date: Tue, 7 Jul 2026 16:02:47 +0800 [thread overview]
Message-ID: <akyyp1GCecWj2Bk2@yilunxu-OptiPlex-7050> (raw)
In-Reply-To: <5dbd4ac8-a532-4889-bae1-f0bab9a99267@linux.dev>
> 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?
next prev parent reply other threads:[~2026-07-07 8:02 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-08 16:42 [RFC PATCH] fpga: region: Add support for FPGA region variants Marco Pagani
2026-06-08 16:42 ` [RFC PATCH fpga/for-next 1/2] " Marco Pagani
2026-06-08 16:42 ` [RFC PATCH fpga/for-next 2/2] fpga: of-fpga-region: Add support for " Marco Pagani
2026-06-26 12:58 ` [RFC PATCH] fpga: region: Add support for FPGA " Xu Yilun
2026-06-30 9:39 ` Marco Pagani
2026-06-30 14:58 ` Xu Yilun
2026-07-06 10:05 ` Marco Pagani
2026-07-07 8:02 ` Xu Yilun [this message]
2026-07-07 21:49 ` Marco Pagani
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=akyyp1GCecWj2Bk2@yilunxu-OptiPlex-7050 \
--to=yilun.xu@linux.intel.com \
--cc=linux-fpga@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marco.pagani@linux.dev \
--cc=mdf@kernel.org \
--cc=trix@redhat.com \
--cc=yilun.xu@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox