add Nitropad NV41/NS50 TPM2 boards

[daringer]

This PR introduces two new boards: nitropad-nv41 + nitropad-ns50 with TPM2 and overall Nitrokey 3 support (hotp-verification). Re-based on the current master there is no need for gpg patches anymore.

The current state is that both boards work as expected, tpm2 works nicely, hotp-verification works using Nitrokey 3 (or others). LUKS + TPM is disabled through config, because our tests have not shown a robust behavior here.

Changes:

• kernel 6.1 with patches ported (expect winterfell)
• .npf handling (a zip + hash file) during update
• hotp-verification with Nitrokey 3 support
• added CONFIG_GPG_DEFAULT_ALGO w/o it being set, gpg defaults to create RSA-3072 keys, setting p256 leads to NIST-P256 keys during key generation on oem-factory-reset
• adds modules: iotools and nitrokey-blobs

[tlaurion]

I guess I will revisit this reply with information as I go and we can split this up in smaller discussions as well!
Will reply inline.

Changes/Commits which cannot be merged as-is:

* [86427bf](https://github.com/osresearch/heads/commit/86427bf8b3315c2cb8fa60465b7908137f805830) changes oem-factory reset to use p256 keys instead of rsa3072. I would suggest to make both variant available through a configuration setting (inside the board) defaulting to rsa3072. Any proposal for the to-be-used config name?

I think it is time that we skim the OEM Factory Reset/Re-Ownership wizard into something called Ownership plain and simple. I took the time to look at Pureboot next branch and saw that they decided to hide most of the re-ownership options under "choose defaults". I think that might address Nitrokey's concerns as well? I guess code should continue to use default while board config overrides could be implemented. CONFIG_GPG_DEFAULT_ALGO or something?

* [b428b5b](https://github.com/osresearch/heads/commit/b428b5bcf29c461026281795873dcc08a172ff6e) is an evil one. If the `-V` (verbose flag for flashrom) is not omitted, the oem-factory-reset takes ~2hours as the progress parser seems to fail. This seems to be a flashrom 1.3 issue. What should we do with that? We could introduce a config variable to change the commandline parameters for flashrom here. We have been debugging this, but with no luck yet.

This one is problematic and discussible under #1233
The short version is that we currently process textual output of -V to produce a progress output ourselves, since depending of hardware, spi read/write/speed, the end user is otherwise provided with an empty prompt, and reading/writing on some platforms actually take forever. The last thing we would want is a user doing a poweroff. So we are stuck waiting that https://ticket.coreboot.org/issues/390 is fixed and flashrom provides a --progress output of their own. Quickly checked the commit you picked, but haven't checked upstream for progress on this since forever. Maybe there is commit merged in and a switch to turn that on. If you can check and tell that there is progress bar that we can all use and test, I'm more then willing to test and push for testing for regression on all boards. Let me know maybe under #1233. When we implemented the changes for progress output under Heads, we knew that most of the processing time was in drawing in the console the progress bar, but we had to do it either way. You can track this under #1233.

Notable other changes, which might need discussion:

* [60a9034](https://github.com/osresearch/heads/commit/60a9034aad27190d9e543988a40bafc328d139d1) flashrom bump to 1.3

Same as previously discussed point. Maybe you could check for -V output under /tmp and see if there is some output that could be patched against. There was some output on the Dasharo port of flashrom that needed to be removed otherwise it was failing as well. You can check their commit log to see patch commit.

* [103d17d](https://github.com/osresearch/heads/commit/103d17d60d530f4438745dd7c1d9dfa404cf660c) kernel 6.1 with patches ported (expect winterfell)

* [cf1a217](https://github.com/osresearch/heads/commit/cf1a21745f47a667d10e28d7d475f16c9f75d961) gpg patch backported from https://dev.gnupg.org/rG3c3765405de02b9a57fdc9a3cf901f6e3aca8586 (thus should be save for inclusion)

* [dc522d1](https://github.com/osresearch/heads/commit/dc522d115b22b2c7355df493a2c16c0f25ee017f) `.npf` handling (a zip + hash file) during update

* [d676bca](https://github.com/osresearch/heads/commit/d676bca7837d2d1d2bf2a9233424043f7c277a4d) `hotp-verification` with Nitrokey 3 support

A build issue I've found, I can reliably reproduce this error: #1359 ... This happens to me every time (after a fresh checkout) locally and in our CI. To work around this I have to rm -rf build/x86/openssl-3.8 and re-build to make it work. Could this be a bad dependency ordering? Any ideas?

What OS are you building on (local and CI?)
Please reopen #1359 and detail that there. Not experimenting on CircleCI with debian-11. Maybe a race condition, not sure.

[daringer]

As this looks like this could take some more time - should I pull out the make-the-Nitrokey 3-work into a separate PR ? This would be the gpg-patch, hotp-verification to v1.4 and a config-var to define the key-generation algorithm ?

[saper]

CONFIG_GPG_DEFAULT_ALGO

We have to remember that current OEM Init/Re-ownership thing completely resets uses' cryptographic token. This would mean one token per device.

Which key needs to be an elliptic curve key? The master public key? The key signing the image?

Maybe it is just enough to have a subkey for those boards, so that the user could maintain their main long term identity keys and one or more device-specific subkeys on the token?

OpenPGP is ugly and allows only 3 keys on the token, but if we have included support for tokens like Nitrokey HSM 2/SmartCard-HSM or other PKCS#11 tokens, it would be easier to manage multiple different keys and key types.

[saper]

• cf1a217 gpg patch backported from https://dev.gnupg.org/rG3c3765405de02b9a57fdc9a3cf901f6e3aca8586 (thus should be save for inclusion)

https://dev.gnupg.org/rGf808012ac2cf67ec563da178d963f300a7f2564d should already be included in #1350 - can you try if 2.4.0 works for you?

[daringer]

Which key needs to be an elliptic curve key? The master public key? The key signing the image?

Inside oem-factory-reset the generation of a new key is currently hard-coded to be rsa3072, the change is simply changing this one to p256. It was also just one algorithm for all keys and this PR does this in a similar fashion, just changing the algorithm. Nevertheless having CONFIG_GPG_DEFAULT_ALGO available would already be a first step towards a more flexible approach here.

OpenPGP is ugly and allows only 3 keys on the token, but if we have included support for tokens like Nitrokey HSM 2/SmartCard-HSM or other PKCS#11 tokens, it would be easier to manage multiple different keys and key types.

Totally second that, the main issue is here that we would also have to replace gpg as afaik it does not support PKCS#11 tokens in general.

https://dev.gnupg.org/rGf808012ac2cf67ec563da178d963f300a7f2564d should already be included in #1350 - can you try if 2.4.0 works for you?

Didn't test within HEADS, but locally it works as expected

[saper]

the change is simply changing this one to p256

So this is from the "any other changes" category, not required to this board at all? Maybe those should go into separate PRs?

Regarding the use of the elliptic curves in general:

• yes, this is cool, for example I would like to have a possibility to WRITE DOWN the private key on paper and have it on paper "HSM" only. It is possible with EC, since they are small.

However:

• I don't see people using NIST curves with GPG often (which may or may not be a bad thing)
• Most people prefer ed25519 but this is problematic with GPG since there is an ongoing war of standards how to do it in OpenPGP, also there are some pitfalls with it, like having to specify "eddsa" flag with a private key or else it tries ECDSA(!)
• Most importantly, this would mean we would use ECDSA. I am not sure how reliable is random number generation under heads, it might be hard to guarantee the uniqueness of the k semi-private key. libgcrypt seems to have a "rfc6979" flag but I have no idea whether GnuPG uses it/can use it and how.

[tlaurion]

@daringer splitting would definitely help things merged faster

[tlaurion]

@daringer #1423 is a better approach for flashrom.

[tlaurion]

@daringer #1422 might work for you for gnupg?

[daringer]

rebased on current master so got rid of any flashrom & gpg fixes - now ready for review & merge ...

[tlaurion]

@daringer initial review!

[tlaurion]

Your hotp commit would benefit little more detail or a link to changelog?

[tlaurion]

Note that coreboot fork affected by this as all coreboot cross buildstack
https://review.coreboot.org/c/coreboot/+/76399

[tlaurion]

@daringer #1419 and #1428 merged.

if linuxconfigs saved in oldconfig in tree based on earlier linux version that in this PR, I would be ok merging once this PR is rebased on current master.

Also note that you have two boards depending on the same coreboot fork. Not sure why you do that since we build in a different difrectory what is board specific. I would advise not having two identical forks of coreboot being downloaded but reuse the same source directory, just like Heads does for a same coreboot version today used across different boards, which works correctly under CircleCI. That will permit the coreboot level cache to not explode in size either.

Now you and Purism are building from coreboot-git, so having this PR build your boards updating .circleci config will tell us if everything is fine, not creating additional problems.

So todo:

• point to newer linux version in boards

  • generate oldconfig for linux in tree ( use either make BOARD=xyz linux.save_in_oldconfig_format_in_place to validate enablement/disablement of added kernel options since kernel version bump or make BOARD=xyz linux.modify_and_save_oldconfig_in_place to just enable defconfig differences for board linux config in tree. Inspect changes and force push when satisfied. You can off course compare against other linux configs for same version if they exist and tune them accordingly).

• deduplicate coreboot fork statements under modules/coreboot so that you reuse the same fork for both boards. Its important for CI.

• add boards under .circleci/config.yaml so boards are built from this PR.

[daringer]

okay, thanks for all the inputs, the most recent push includes:

• rebased on top of master
• kernel used is now 6.1.8
• coreboot consolidated to one version called nitrokey (including a fix for the acpica-unix2 download location)
• fixed indentation fails, ooopsy
• created defconfigs for linux-config and coreboot-configs
• updated hotp-verification commit-msg to reflect the changes in version 1.4
• added both nitropads to .circleci/config.yaml - there are good chances that this is not correct, only very limited circleci-experience here

tested successfully on Nitropad NV41 + Nitropad NS50

[tlaurion]

• created defconfigs for linux-config and coreboot-configs

We are changing from defconfig to oldconfig as said under this comment

Please do:

make BOARD=nitropad-ns50 coreboot.save_in_oldconfig_format_in_place
make BOARD=nitropad-ns50 linux.save_in_oldconfig_format_in_place
make BOARD=nitropad-nv41 coreboot.save_in_oldconfig_format_in_place
make BOARD=nitropad-nv41 linux.save_in_oldconfig_format_in_place

And push result as new commit to keep configs in oldconfig, which permits to compare boards configs directly between version bump (that was a hassle before) and between boards of the same linux kernel version.

[tlaurion]

Please depend on librem_14 instead.

Logic here is that we try to only build musl-cross and tools built with musl-cross once and pass workspaces to other boards sharing the most things in common for the same architecture (x86).

That way, we don't use CircleCI to rebuild musl-cross-make nor modules that were already built (cache is used to rebuild any changes if needed) and only builds coreboot and linux.

By depending on librem_14, you will share the same cache for linux with librems, which now share the same linux kernel version.

[tlaurion]

@daringer I'm testing your config. For some reason, your fork is not built by circleci. I pushed exact for build test at https://app.circleci.com/pipelines/github/tlaurion/heads/1831/workflows/eab77bd8-f556-4927-ab4d-18e2488f8fd6

Hold on, you might have done the right thing. If save cache works, your approach might speed the builds, but I doubt save_cache can merge multiple directories that are shared across archoitectures (it should fail, we will see). Directories need to be unique, which is why save_cache only had one x86 and one ppc64 cache to merge.

[daringer]

updated based on #1417 (review)

[tlaurion]

@daringer #1462 finally resolves our problems, and under https://github.com/tlaurion/heads/tree/staging_nitrokey_git I pushed what this PR should look like so, reusing #1462 toolcain logic, for which nv41/ns50 builds locally against 4.19 toolchain. So We should be able to piggyback nv41/ns50 to x230-hotp-maximized under CircleCI cache, maining we will reuse musl-cross-make build there and also 4.19 coreboot's buildstack

[tlaurion]

Finally! Two testing CircleCI pipelines were successful building without cache and rebuilding with cache from a previous successful build:

• nv41/ns50 coreboot fork, depending on 4.19 coreboot buildstack: https://app.circleci.com/pipelines/github/tlaurion/heads?branch=staging_nitrokey_git3
• nv41/ns50 coreboot fork, depending on its own coreboot's fork buildstack: https://app.circleci.com/pipelines/github/tlaurion/heads?branch=staging_nitrokey_git4

I will update https://github.com/tlaurion/heads/tree/staging_nitrokey_git to use clevo_release buildstack (second approach above) where there will be need of improving CircleCI/coreboot module's targets to optimize rebuilds when only scripts change. As of now, a full build when modules changes takes nearly 2 hours, where a rebuild from cache takes 50 minutes.

Also to be noted that CircleCI has some instabilities where restoring workspaces and saving workspaces are sometimes failing in the past days, so wil keep an eye on that: it requires CircleCI builds to be restarted from failed step to succeed.

[tlaurion]

#1469 is ready to be used as a guideline to clean this PR to make it ready to be merged.

[tlaurion]

Superseded by #1469. Please reopen if choice is to rebase this PR and cherry-pick my commit on top of it so that present commits here are not co-authored as under #1469. Closing meanwhile.

[tlaurion]

reopen and comment doesn't work :(

[nestire]

tested ci image on nv41 and ns50:

• oem-factory-reset works
• Booting Qubes 4.1.2 and Ubuntu 22.04 works
• NK3 and NK Pro 2 works

[tlaurion]

Thanks for Nlnet for supporting this part of the work https://nlnet.nl/project/HEADS-TPM2.0/#ack