Allow system-files interface for `dfx-mgr` snap

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