Hello,
As part of our efforts to enable dynamic FPGA bitstream loading in snap environment, I snapped the dfx-mgr application provided by AMD. dfx-mgr is an application that loads binaries to FPGA and changes device-trees by utilizing configfs. So we need write access to configfs.
By the time of implementation of the snap application, there is no way to use a specific interface designed of this job so we need to use system-files interface with write access to /sys/kernel/config
plugs:
system-files:
write:
- /sys/kernel/config
Since the project is open-source source code can be found here
Looking forward to hear your opinions
Best Regards,
Talha
Hi Talha, this request would need to get approval according to the process.
@reviewers Could you please check and approve?
Hey @tchavadar,
Since no interface for configfs
filesystem is available, this request looks legitimate, but write access to /sys/kernel/config
is sensitive since it contains many device driver configurations, kernel modules objects and many more things. Can you limit this write access to a specific sub-dir in configfs for dfx-mgr
snap?
@0xnishit thank you very much for your input. Yes I can limit it to /sys/kernel/config/device-tree
if thats ok with you as well. dfx-mgr needs the configfs for device-tree manipulation
@reviewers note manipulation of device-tree allows full device ownership since the device tree can specify arbitrary kernel modules to be loaded. So unless something has changed siginificantly from the discussion I had back in Guidance on snap interface to load a device-tree overlay on RPi Core18 then I am not sure this is a suitable use-case for a snap at this time.
1 Like
Yes Alex that is correct, it will make dfx-mgr is a sort of god for the platform. Idea here is to enable dynamically configurable FPGA use case in Ubuntu Core. This is a requirement for AMD Xilinx platforms, to make them practical in Ubuntu Core
Maybe we can introduce some sort of sign check mechanism into dfx-mgr applications so that we can be sure that the bitstream that is being loaded is the one we allow, or the one that the system knows.
I am open for any feedbacks to improve security in that aspect.
I think this needs wider discussion with the snapd team - @pedronis can you comment?
We had this discussion in Madrid with snapd team, decision was to enable dfx-mgr so for the other use-cases people will just use dfx-mgr instead of requesting these permissions for all of the applications in FPGA that requires bitstream.
But I would like to hear from @pedronis as well to clear things here in the forum as well.
In the current absence of a design to mediate device tree loading, I think a reduced scope system-files would be acceptable given the nature of the snap but the snap would need to be published by a vetted publisher. (cc @alexmurray)
Hey @tchavadar
Would manual connection of the requested interface suffice the requirements of your use case?
Thanks
Hi @jslarraz,
It is not ideal but of course it is better than nothing. we are working on making dfx-mgr published by a vetted publisher but this is still a work in progress. Until that time we can manually connect the interface.
Thank you for the solution
Following @pedronis’s feedback, +1 from me for manual connection system-files
interface with write access on /sys/kernel/config/device-tree
Will need publisher vetting
thanks