Conversation
Thorsten Leemhuis (acct. 1/4)
kernellogger@fosstodon.org
The TPM bus encryption and integrity protection changes prepared by @jejb and @jarkko were merged for #Linux 6.10: https://git.kernel.org/torvalds/c/b19239143e393d4b52b3b9a17c7ac07138f2cfd4
"[…] The key pair on TPM side is generated from so called null random seed per power on of the machine [1]. This supports the TPM encryption of the hard drive by adding layer of protection against bus interposer attacks. […]"
1
1
1
Jarkko Sakkinen
jarkko
@kernellogger @jejb The main reason I went to the attic, wiped the dust and started cleaning up this was that I bought Mac Mini M2 Pro and was disappointed that I need to type text before the system even boots itself. So literally user experience made me work on a sec feature ;-) There was already somewhat recent support in systemd and LUKS2 for the TPM2 encrypted boot but it is not really compelling security model overall if the busses leak... So this kind of completes that work.
2
0
0
James Bottomley
jejb@mastodon.online@jarkko @kernellogger I wish I could say it's complete but now it's on to adding TPM policy use in the kernel.
1
0
1
@jejb @kernellogger true but the basic frames have been set at least and more to come.
like before this there was something in one axe and nothing in the other. now both have something so it is at minimum a complete iteration ;-)
like before this there was something in one axe and nothing in the other. now both have something so it is at minimum a complete iteration ;-)
0
0
1
Lennart Poettering
pid_eins@mastodon.social@jarkko @kernellogger @jejb systemd's disk encryption stuff actually has been using encrypted sessions for a long long time.
1
0
1
@pid_eins @kernellogger @jejb I paid attention to the state year ago or similar timeline when I bought that Mac Mini :-) it worked but i did not switch from passphrase because of the bus issue. This closed the scheme enough for me to be ready to fully switch. In that sense it is complete and along the lines of macOS (without requiring vendor lock-in chip).
1
0
0
@pid_eins @jejb @kernellogger I did now integration shenanigans and some reorg in kernel code base for James Prestwood (iwd dev). He will write RSA/ECDSA ops for asym keys and test them with iwd. It made sense because iwd being good test target and he has PoC'd the RSA part before.
The idea is to have a single key crypto primitive API in the main TPM driver (selected with TCG_TPM2_KEY) and all primitives there and none in the subsystems that call TPM. Initially it contains ASN.1 encoder/decoder relocated from trusted keys.
https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/log/?h=tpm2_key
Even if some bits are still missing, I think the topology of this code nice right for a longer period of time, and not such a sprinkled mess like it used to be.
The idea is to have a single key crypto primitive API in the main TPM driver (selected with TCG_TPM2_KEY) and all primitives there and none in the subsystems that call TPM. Initially it contains ASN.1 encoder/decoder relocated from trusted keys.
https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/log/?h=tpm2_key
Even if some bits are still missing, I think the topology of this code nice right for a longer period of time, and not such a sprinkled mess like it used to be.
1
0
0
@jejb @kernellogger @pid_eins Right to be in phase what is going on in systemd it would need to replace this multicall binary called "busybox" which is defacto for kernel testing. Otherwise I hear about features when they get enabled in stock distributions (for the most part) :-)
Nothing wrong in systemd but it just don't cut in fast-phased kernel QA cycle. If there was "microd" that would be a drop-in replacement for busybox, that would work. This a niche where systemd *does not* dominate. No time to follow every possible thing but as user I'm happy with it.
Actually it would have benefits over busybox, even if it was somewhat rigged and stripped off. The main issue with busybox is that it cannot obviously re-use unit files from upstream projects. So you need to sometimes launch daemons manually or rewrite init in sysvinit.
A topology of two multicall static binaries would not be outrageous for kernel testing: "microd" doing systemd alike stuff and busybox providing the command-line tools. It would be still pretty trivial to deploy even without a build system.
Nothing wrong in systemd but it just don't cut in fast-phased kernel QA cycle. If there was "microd" that would be a drop-in replacement for busybox, that would work. This a niche where systemd *does not* dominate. No time to follow every possible thing but as user I'm happy with it.
Actually it would have benefits over busybox, even if it was somewhat rigged and stripped off. The main issue with busybox is that it cannot obviously re-use unit files from upstream projects. So you need to sometimes launch daemons manually or rewrite init in sysvinit.
A topology of two multicall static binaries would not be outrageous for kernel testing: "microd" doing systemd alike stuff and busybox providing the command-line tools. It would be still pretty trivial to deploy even without a build system.
1
0
0
@jejb @kernellogger @pid_eins For reference this is how I test upstream: https://gitlab.com/jarkkojs/linux-tpmdd-test. I often branch this locally and then add/remove some stuff but yeah this is the context. Would be counter-productive to add systemd, even if it gave me support for unit-files.
0
0
0