sapi: allow for per-function configuration #2369
Conversation
log strings should be scoped to where its used for clarity on use but it also reduces the object code size by not needing the log string table always included. Signed-off-by: William Roberts <william.c.roberts@intel.com>
If disabling loging, don't compile in backend logging support which bloats the object code. Signed-off-by: William Roberts <william.c.roberts@intel.com>
Scope command handles to where they are used. Signed-off-by: William Roberts <william.c.roberts@intel.com>
Don't provide empty functions when disabling validation fuinctionality, just provide the RC success value. This reduces object code by about 2k. Signed-off-by: William Roberts <william.c.roberts@intel.com>
Its just needs log.c, so just bring that in. This saves about 1.5k in dead object code due to all the socket and write_all, read_all, etc functionality. Not all linkers support dead code stripping, or do a good job, so lets just avoid it. Signed-off-by: William Roberts <william.c.roberts@intel.com>
williamcroberts
force-pushed
the
sapi-configure
branch
2 times, most recently
from
9c73227
to
479785b
Compare
To reduce the size of the system API, allow for a KConfig like system where one can select required functionality. The selected functionality can be included through a YAML list file of the functions needed. The build tooling, scripts/tssconf.py is smart enough to look through and find all the leaf functions for internal tpm2-tss calls that we care about, like MU calls. For instance with a config file of: - Tss2_Sys_GetRandom The functions to enable are: - Tss2_Sys_GetRandom - Tss2_Sys_GetRandom_Prepare - Tss2_Sys_GetRandom_Complete It will also output the required MU function defines, but libMU is currently not instrumented to handle that. For instance, I was able to build a SAPI as small as 6k with very limited functionality and 10k with the required functionality for my environment. The original SAPI object code for functions was 98k. Signed-off-by: William Roberts <william.c.roberts@intel.com>
williamcroberts
force-pushed
the
sapi-configure
branch
from
479785b
to
4d25152
Compare
Codecov Report
@@ Coverage Diff @@
## master #2369 +/- ##
==========================================
+ Coverage 83.41% 83.66% +0.24%
==========================================
Files 352 351 -1
Lines 37900 37773 -127
==========================================
- Hits 31614 31601 -13
+ Misses 6286 6172 -114
📣 Codecov can now indicate which changes are the most critical in Pull Requests. Learn more |
|
I'm not quite sure, whether this is overkill. |
Yes, sigh, but sadly not all linkers in every environment can and do strip dead code. |
You're joking, right ? April fools or something ? Still, are such linkers common enough for us to maintain this chunk of code instead of telling people to include the needed C-Files one-by-one as needed ? If you say "yes", I'll be happy to review though. |
I really wish I was.
You could, and I thought about that approach. The problem is when you enable ESAPI, you don't need the oneshot variants, just the prepare and complete SAPI calls, which consumes about 500 bytes per oneshot call on average. I figured if a semi-intelligent KConfig system was hard, i'd abandon it but its simple enough.
I'd like to, because then updates are as easy as copy+paste+build. Given that in constrained environments updates are slow because of the pain of updating, I'd like to keep this as streamlined as possible rather than having folks have a pile of merge conflicts or other issues. I need to #ifdef ESAPI and MU still. But I figured i'd post his early for feedback. |
|
|
||
| #if !defined(CONFIGURATOR) || defined(ENABLE_TSS2_SYS_ACT_SETTIMEOUT_COMPLETE) |
There was a problem hiding this comment.
I think I'd be more happy with a
#if !defined(DISABLE_TSS2_SYS_ACT_SETTIMEOUT_COMPLETE)
and similarly for the rest.
The configurator.h could include said macros then.
| @@ -12,6 +12,11 @@ | |||
| #include "tss2_mu.h" | |||
| #include "sysapi_util.h" | |||
|
|
|||
| #ifdef CONFIGURATOR | |||
| #include "configurator.h" | |||
There was a problem hiding this comment.
I don't really like this new include. It's a bit unintuitive.
Could we maybe instead get this into config.h somehow ?
Or maybe add the include on configurator.h into config.h ?
There was a problem hiding this comment.
I don't really like this new include. It's a bit unintuitive. Could we maybe instead get this into config.h somehow ? Or maybe add the include on configurator.h into config.h ?
I've tried to figure out how to add things into config.h and it doesn't like my attempts to modify config.h since it takes control of it through autoconf magic.
The name does suck, I was going to rename everything. I was going to call everything BUILD_CONFIG and use that namespace everywhere as well as name the heade build_config.h.
There was a problem hiding this comment.
I think I found something:
Macro: AH_TOP (text)
Include text at the top of the header template file.
Macro: AH_BOTTOM (text)
Include text at the bottom of the header template file.
So
AS_IF(...
AH_BOTTOM(#include "configurator.h")
)
|
Example config file: - Tss2_Sys_GetRandom
- Esys_TR_FromPublic |
|
Closing, I think an easier way is to remove API files from the build, libmu being complete doesn't seem like too much. If that granularity is needed I will reopen. |
|
@williamcroberts is there a better way than manually editing makefiles for doing this? |
No, but my specific use case has it's own build system so I cannot re-use the makefiles. Do you have a specific use case for this feature? |
Embedded Systems where we need to fit in a memory constrained environment. |
I've got 256kb to fit my code and everyone else's into and just picking and choosing which API files seems to be fine at the moment. The only thing this really provides is being able to break up libmu which is pretty tiny (i don't have hard numbers offhand). We just pulled in the SPI TCTI driver skeleton and those folks haven't needed any mods in this area. If someone was actually up against a real limitation i'd be willing to dust this off. |
|
@williamcroberts could you share your build setup/makefile for this 256kB version? In some cases, we have MCU with RTOS and 256kB total flash memory :) Of course, nowadays, we see more often 1MB total flash, but split this for rollback update, leaves us just 512kb. 50% for tpm2-tss is a lot. |
I can't share the Makefiles but I configure out a lot of things like logging, tctildr, all tctis (we have a custom one),
We're bare metal with a 256kb slot.
Yeah. I'll implement the feature if folks actually say, "I can't get this to work in my environment". But I've never had anyone say that yet. |
|
This is okay, Bill. Could you please share your configure line then? How to reproduce your 256kB build 😃 |
It's all custom. I don't use auto tools for it so their is no configure line. I took a generated config.h and modified it to disable things I didn't want. Then I just added the src files I needed to the build. For src/tss2-sys you need sysapi_util.c and then pick whatever api file you need for interfaces. For src/tss2-esys you need esys_context.c. esys_crypto.c esys_free.c esys_iutil.c esys_mu.c esys_tr.c and your choice of backend for crypto esys_crypto_mbed.c OR esys_crypto_ossl.c. I don't use a crypto back-end, ours is implementation specific and plugged in at run time using the new Esys_SetCryptoCallbacks. for src/tpm2-mu I just build all the c files. I build with these flags: And the config.h is just hand modified generated one... |
|
Thank you for the detailed instructions, Bill. What you described is one of the main reasons we do not use this stack in embedded systems. I do not want to review this PR, just sharing my experience. If it is not too much bother, please pack a ZIP with this custom build and upload it somewhere :) |
You use autotools to build? I know lot's of folks that use this in embedded systems. But almost every embedded system has it's own build system that folks integrate into.
I can't :-p |
To reduce the size of the system API, allow for a KConfig like system
where one can select required functionality.
The selected functionality can be included through a YAML list file of
the functions needed. The build tooling, scripts/tssconf.py is smart
enough to look through and find all the leaf functions for internal
tpm2-tss calls that we care about, like MU calls. For instance with a
config file of:
The functions to enable are:
It will also output the required MU function defines, but libMU is
currently not instrumented to handle that.
For instance, I was able to build a SAPI as small as 6k with very
limited functionality and 10k with the required functionality for my
environment. The original SAPI object code for functions was 98k.