Hi everyone,
As you may know, console drivers in TF-A are required to provide a number of callbacks. One of them is getc() (to read a character from the console). Even though most platform ports provide a valid implementation of it, it does not seem to be called anywhere in the code base today, effectively qualifying it as dead code.
I did a bit of git history digging and from what I've seen, the very first public version of TF-A (v0.2!) already had a getc() callback in the Arm PL011 UART driver. So my guess is that all subsequent UART drivers added after that followed the same approach. When the multi-console framework was introduced, it naturally catered for this feature as well.
However, taking a step back, I wonder why we introduced getc() in the first place... Unlike other firmwares (like U-boot or EDK2), TF-A does not implement any kind of interactive user shell. And from a security point of view, getc() constitutes an attack vector into TF-A, which might allow an attacker to inject arbitrary data. So keeping this functionality without any valid use case sounds like a bad idea to me.
Now, even though getc() is not used in upstream TF-A code right now, I realize there might be downstream / internal test setups which need it. For example, for firmware recovery purposes (receiving a backup firmware over a serial interface) or automated tests setups (some script driving a test session using some communication protocol over a serial interface).
Is anyone depending on such use cases?
If not, then I suggest we consider removing getc() feature altogether. We could always bring it back when there is a real use case for it (it will survive through git history).
At the very least, I would like to disable getc() by default. Enabling it would require setting a build flag.
Any thoughts or concerns?
Best regards, Sandrine