Hi Julius,
As you were mentioning that the Linux kernel uses /proc/sysrq-trigger for a similar purpose, I was wondering whether you'd be open to a solution based on a "DebugFS" entry. As you may have seen on the mailing list, Olivier posted a proposal for introducing a firmware debug interface, which has many similarities to how /proc or /sys works in the kernel world:
https://lists.trustedfirmware.org/pipermail/tf-a/2019-October/000120.html
TF-A patches for this feature are up for review right now and Olivier has also posted some TF-A Tests patches that demonstrate how this can be used from normal world. In addition, we are also working on a Linux driver for this.
As you can imagine, DebugFS uses an SMC interface under the hood (currently allocated in the SiP range). But being an abstraction over the SMC layer, which specific SMC function ID is used does not matter so much and it does not need to be standardized by any Arm specification. You'd need to mandate all Chrome OS devices to have this DebugFS entry in the firmware but the backend could vary from platform to platform.
Would that suit your use case?
Regards, Sandrine IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hi Sandrine,
Yes, I think using debugfs on the kernel side to control this feature (and other firmware control/debug stuff) is perfectly fine and as a good a solution as any other. I am not quite sure about pulling the whole 9p interface into Trusted Firmware, though... it feels a bit "heavy" for a firmware use case (e.g. the 9p layer alone is a thousand lines of code). I'm not sure I see the benefit over using the same debugfs interface on the kernel side but backing it by a kernel driver that translates the file accesses into a simpler, record-based SMC interface (that could also avoid the shared memory requirement, at least for simple requests). Maybe this depends on what else you're planning to do with this interface.
It also seems that you're intending for this to only be used for developer builds and never make it into a production image (e.g. it's printing a warning when not building with DEBUG=1). In that case, I can see that code size and complexity may not be a big concern. However, for the use case I had in mind I'd need this to be enabled in production images (Chrome OS doesn't really distinguish between test and production images for automated testing), so I'm looking more for a lightweight API where each command can be enabled/disabled individually at compile time.
I'd have to look at and test it in more detail when it's done, but given that it will likely increase code size by quite a bit and that I'm not sure how much I can trust it to be secure for production, I don't think this would work for my use case.
tf-a@lists.trustedfirmware.org
-
Julius Werner -
Sandrine Bailleux