Request classic confinement for xlnx-config

I’d like to request classic confinement for soon to be released xlnx-config snap. xlnx-config will be used to manage boot artifacts for Ubuntu-enabled Xilinx development boards. Users will use xlnx-config to change the bitstream (FPGA programmable logic ), device tree, boot loader, etc. to modify the functionality of the board.

The snap modifies boot assets so the system loads different HW definitions to the FPGA on boot, and for that it needs to access the system partition. That system partition is not easily available for a confined snap.

The snap also provides a content interface slot. This slot provides specific hardware description files that can be read by the consumer snaps. Consumer snaps will be confined snaps that need these description files to be able to talk to the HW defined in the FPGA, and that depend on the HW defined at that point in the platform (cannot be shipped, then, inside these application snaps).

My team has been working closely with @abeato to develop the system architecture needed to support our unique development environment.

Would it be possible to allow this configuration for the xlnx-config snap?

Thanks,
Terry

Is this for a device running Ubuntu Core? If so, it’s worth mentioning that classic Snaps are unable to be installed on Ubuntu Core devices - instead you’d want to use the system-files interface to grant read-write access to the files you need to write to (this will require approval from the Store, unless you are using a Brand Store).

No, it is just for classic and it is not meant to be run on UC in any case.

1 Like

Even though this request does not fall under the existing list of supported categories, given the sensitiveness of the request and the attack surface of granting declarations for /boot, I would like to request @pedronis opinion on this topic.

Is the snap running on a host Ubuntu classic system to which the board is attached, but the host system needs to be modified/configured to run with the board? Or is the board self-contained and the snap runs on the board?

Hi @pedronis, the snap is running directly on a Xilinx development board. It is self contained, and is only meant to run on Xilinx development boards running our certified version of Ubuntu.

Since this is a tool meant to only run on Xilinx development boards, the requirements to grant classic confinement are understood.

@Igor could you please perform publisher vetting?

Thanks,

+1 from me, I verified the publisher.

Thanks @Igor - classic confinement granted, this is now live.

@to3 As noted in the store review, this snap still fails automated review as it declares a content interface slot - but these are not supported for snaps with classic confinement so this content interface slot should be removed and then the snap should pass automated review and be able to be published in the store.

@alexmurray thanks for granting classic confinement. The original request also included the request to use a content interface slot even though it’s not typically needed for classic snaps.

@abeato can you please chime in here? Maybe there is another way to accomplish what we’re trying to do, but I know you thought a content interface slot would be the most elegant if we could get it supported.

Thanks,
Terry

@alexmurray AFAIU content slots are supported by classic snaps - what is not supported is content plugs, as those are the ones needing fiddling with the mount namespace. And, in my testing, things work this way. The idea we have for this content slot is to be able to share some data files with confined snaps from the same publisher.

@alexmurray any feedback on the comment by @abeato?

I think this is correct and content slots work with classic snaps, though it’s an unofficial feature, but I think we have a few snaps that use this, but they are probably allowed through in review-tools.

We have a backlog item about exploring which interfaces are or could be supported more generally with classic snaps, but it has not been actively worked on yet.

One other way to achieve this (as suggested privately by @ijohnson IIRC) would be to have a separate snap that is strictly confined which provides this content slot and then since xlnx-config is classic, it can just read the content directly from this other snap (via /snap/$NAME/current/$PATH_TO_CONTENT), and other strictly confined snaps can plug this content interface to read from it as well. Would that be an option since this could be achieved without granting an override and would ensure that there is no chance for a strictly confined snap which uses this content interface to escape confinement.

@alexmurray I agree that the approach you propose is viable. However, that implies maintaining two snaps, creating maintenance scripts that handle properly the copying of files and updates, etc. So it is a nuisance in maintenance terms. But if we cannot say that content slots are officially supported in classic snaps and that things might break in the future, I guess we will have to follow this route for the moment. It would be good though to come to an official statement soon-ish on whether we support or not content slots in classic snaps.

To make this support official we would need a spread test that covers the expected behavior. After that we would need to consider changing what review-tools allows.