Join GitHub today
Add support for SLB9760 Iridium / LetsTrust TPM boards #2585
This patchset adds support for the SLB9670 based TPM2.0 eval boards which can be used as a secure key storage and hwrng.
Signed-off-by: Peter Huewe email@example.com
Although I don't have a TPM to test I did build a kernel with the updated configuration. Even though the new settings are all
@PeterHuewe @PaulKissinger Have you looked at the impact on the memory footprint for non-users of the TPM? Does my figure of 7MB sound right to you? How do you feel about such an increase, @popcornmix?
Thanks for your response - to be honest I did not have a look at the decrease in free memory, as I did not really expect it, since the TPM drivers are not that big, so this was quite suprising.
So by enabling TCG_TIS_SPI the resulting config changes with regard to:
I will try to find out what increases the RAM usage.
@pelwell I tried to understand what's going on, but I could not reproduce the issue.
I also did a code review on securityfs and the tpm code, and nothing justified a 7MB increase (no big mallocs or huge arrays). (which would have come to a suprise to me as the (former) tpm subsys maintainer)
Can you help me reproduce the issue / retest on your side?
I see the same what @PeterHuewe describes.
I hope the images are a little usefull for you.
Thanks in advance!
Building my own kernels with and without those patches I get:
which shows 1.1MB more memory used (but only 320KB less "available"). That may not sound much on a Pi 3 but it is on a Model B with only 256MB to start with.
This currently sounds like a very niche application
320kb sounds much nicer than the original 7MB :) - and 320kb does not sound too bad.
The 256mb limit only affects "Pi 1 Model B" before produced before October 2012 - I'm not sure how many of them will upgrade to recent kernels.
If you really think this is a big blocking point - what do you think if we atleast enable TPM support for 2B/3B/3B+ (bcm2709_defconfig + bcmrpi3_defconfig) and leave it deactivated for (Zero/Zero WH/ Pi 1) (bcmrpi_defconfig) ?
Hi @pelwell - thanks for your honest feedback. I share your concerns about ram usage, so I sat down the last few days to debug the issue. The topic really caught my attention.
All following tests were done on
I was following the guidelines from the former Linux Tiny Project: https://elinux.org/Kernel_Size_Tuning_Guide
The two kernels differ in the following CONFIG options:
As the modules are not loaded by non-users, we can concentrate on the vmlinux / zImage and its built-ins only.
which is basically a
The symbols above all come from
Since some parts of it might be stripped out again after linking we have to look at the diff of
Since I don't know what the
Now it comes to dynamic memory usage - which is of course much harder - so I had a look at the involved kernel code.
The assumption is still that non-users do not load the modules, and since they don't care also do not mount securityfs.
This function does exactly two things:
So adding static + dynamic usage does get us in the range of maybe 2k.
This also matches with our test-series we conducted over the last few days.
If you are still concerned, I can also look into removing the securityfs dependency, thus resulting in zero changes to the vmlinux binary (i.e. only new modules).
You've changed KConfig which is an upstream file, you should submit this change upstream first and if it is accepted then we'll take it. We're continuously trying to reduce our differences to the upstream kernel.
Have you discussed the change to a module with the maintainer of the security? I'm guessing the correct person to contact is Chris Wright
Of course it would be easier to accept the max. 2k ram increase of securityfs than to change upstream - but nevertheless I will try it.
Both, changing the TPM Kconfig and converting securityfs to a module are upstream changes - so it will take a while to adresss either of them / have them upstream.
2 times, most recently
Jul 20, 2018
@pelwell @ghollingworth : how shall we proceed here? Do we have to wait for the next merge window / next kernel version with the patch, or can I create an updated pull request (including the patch) now? Which kernel versions should we target for backporting?
I would propose the same approach as with stable commits, thus including the upstream commit id in the backport.
Congratulations on getting your patch accepted - it always feels like such a mission.
I'm happy (in principle) to take a Pull Request now. We've already moved on to rpi-4.18.y, with rpi-4.19.y gradually coming online; I'd target 4.18 for now and we'll cherry-pick as necessary. Please do include the "commit upstream." line at the start of the commit message.
@pelwell Ready to merge :)