Identify size optimizations for RT firmware

[jhand2]

Caliptra FMC+RT is currently hovering around 100KiB. This only leaves 24KiB for adding features in 1.x releases. Not high priority, but we should look for opportunities to save code space in RT.

[benjamindoron]

We've had one major idea:

The Caliptra software comprises three images - the ROM, FMC and runtime, all compiled from the same source code - but they're loaded into memory separately. This means there is a lot of code being duplicated in RAM, which consumes space that we may want for actual features in the future. Therefore, we propose to reuse some driver functions from the FMC, in the runtime.

One way to achieve this is to add a table of function pointers to the FMC at a fixed and known region. Then, instead of calling into an independent, duplicated copy of the function, the runtime should read from this table and jump back into the FMC code. The first step, of course, is to look for some large functions in the FMC that are also used and can be overridden in the runtime.

Theoretically, the FMC and runtime could jump back into the ROM, but this has some disadvantages: the ROM is burned-in once, and later, it isn't compiled from the same code anymore. It also can't be done for 1.0: because Rust has no stable ABI, and the toolchain version may change, extern "C" functions would be required; and so, changes to the ROM that is already being used in real hardware. We would also need to update the policy and keep the ROM executable during runtime.

And a minor idea: Bump the compiler version: Rust 1.77 produces smaller binaries, though we'd need to fix cargo test errors for the few cases where the ROM is too large, for some reason. Also, I've been told that some validation was performed on 1.70, so we'd need to clear that, as well as the change to the ROM hash

We've also been talking about use of CFI - potentially replacing it - together

[jhand2]

@mhatrevi @nquarton @JohnTraverAmd @varuns-nvidia Let me know your thoughts.

As we talk about adding features such as image manifest and stable identity, I think we need to look for more opportunities for size savings. Benjamin's suggestion above would be one way to achieve that.

[jhand2]

As an aside, I do believe @korran made a lot of ROM size optimizations by tweaking the rust code to get the compiler to generate something more compact. I am not super familiar with what techniques he used to do this though. @mhatrevi do you have any insight here?

[nquarton]

I was going to bring up the related ROM size issue in the Thursday meeting as well. I was trying to add some basic driver HW error checks and have been hitting the size limit.

I like the idea of updating the compiler as a partial solution.

CFI changes sound like they could potentially have a big impact. I know there has been some more question recently whether or not they are effective with the error handling flow. Is there another solution in consideration or is the ROI in general in question?

Is calling back into the FMC from runtime an idea that's been discussed before? I know doing that for the ROM was explored and rejected previously.

[benjamindoron]

I was going to bring up the related ROM size issue in the Thursday meeting as well. I was trying to add some basic driver HW error checks and have been hitting the size limit.

Well, when it comes to code or toolchain changes, improvements for the FMC/RT will likely also be benefiting the ROM.

Is calling back into the FMC from runtime an idea that's been discussed before? I know doing that for the ROM was explored and rejected previously.

I believe not. And while I'm aware that this kind of idea has been rejected for the ROM, I don't think that there were solid arguments against it - it just wasn't needed. Now that the ROM has been released though, it's too late to consider changes there.