Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add Nitropad NV41/NS50 TPM2 boards #1417

Closed
wants to merge 13 commits into from

Conversation

daringer
Copy link
Collaborator

@daringer daringer commented Jun 13, 2023

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

@daringer daringer marked this pull request as draft June 13, 2023 10:53
@tlaurion
Copy link
Collaborator

tlaurion commented Jun 13, 2023

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
Copy link
Collaborator Author

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
Copy link
Contributor

saper commented Jun 21, 2023

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
Copy link
Contributor

saper commented Jun 21, 2023

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

@daringer
Copy link
Collaborator Author

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
Copy link
Contributor

saper commented Jun 22, 2023

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
Copy link
Collaborator

@daringer splitting would definitely help things merged faster

@tlaurion
Copy link
Collaborator

@daringer #1423 is a better approach for flashrom.

@tlaurion
Copy link
Collaborator

@daringer #1422 might work for you for gnupg?

@daringer daringer changed the title add Nitropad NV41/NS50 boards; update various modules add Nitropad NV41/NS50 TPM2 boards / NK3 support Jul 7, 2023
@daringer daringer marked this pull request as ready for review July 7, 2023 14:15
@daringer
Copy link
Collaborator Author

daringer commented Jul 7, 2023

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

initrd/bin/flash-gui.sh Outdated Show resolved Hide resolved
initrd/bin/flash-gui.sh Outdated Show resolved Hide resolved
@tlaurion
Copy link
Collaborator

tlaurion commented Jul 7, 2023

@daringer initial review!

@tlaurion
Copy link
Collaborator

tlaurion commented Jul 7, 2023

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

modules/linux Outdated Show resolved Hide resolved
@tlaurion
Copy link
Collaborator

tlaurion commented Jul 11, 2023

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

@tlaurion
Copy link
Collaborator

tlaurion commented Jul 13, 2023

@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
Copy link
Collaborator Author

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
Copy link
Collaborator

tlaurion commented Jul 20, 2023

  • 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.

initrd/bin/flash-gui.sh Outdated Show resolved Hide resolved
target: nitropad-nv41
subcommand: ""
requires:
- prep_env
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

updated based on #1417 (review)

tlaurion and others added 2 commits August 7, 2023 08:34
CircleCI: depend on NV41 for save_cache
Makefile: consider that coreboot-git is now shared between forks on x86 (Nitrokey/Purism share build/x86/coreboot-git now)

Addressesses requested change at linuxboot#1417 (review)
Another approach at linuxboot#1449

Signed-off-by: Krystian Hebel <[email protected]>
tlaurion added a commit to tlaurion/heads that referenced this pull request Aug 8, 2023
TODO: revert circleci config after making sure rebuilding from cache from CI works

CircleCI: depend on NV41 for save_cache
Makefile: consider that coreboot-git is now shared between forks on x86 (Nitrokey/Purism share build/x86/coreboot-git now)
modules/coreboot: have clevo/nv boards based on dasharo fork and apply clevo_patches

Addressesses requested change at linuxboot#1417 (review)

co-Signed-off-by: Krystian Hebel <[email protected]> and [email protected]
tlaurion added a commit to tlaurion/heads that referenced this pull request Aug 8, 2023
TODO: revert circleci config after making sure rebuilding from cache from CI works

CircleCI: depend on NV41 for save_cache
Makefile: consider that coreboot-git is now shared between forks on x86 (Nitrokey/Purism share build/x86/coreboot-git now)
modules/coreboot: have clevo/nv boards based on dasharo fork and apply clevo_patches

Addressesses requested change at linuxboot#1417 (review)

co-Signed-off-by: Krystian Hebel <[email protected]> and [email protected]
krystian-hebel pushed a commit to Dasharo/heads that referenced this pull request Aug 8, 2023
CircleCI: depend on NV41 for save_cache
Makefile: consider that coreboot-git is now shared between forks on x86 (Nitrokey/Purism share build/x86/coreboot-git now)

Addressesses requested change at linuxboot#1417 (review)
tlaurion added a commit to tlaurion/heads that referenced this pull request Aug 11, 2023
@tlaurion
Copy link
Collaborator

@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 added a commit to tlaurion/heads that referenced this pull request Aug 14, 2023
…reboot module, patch and circleci fix
@tlaurion
Copy link
Collaborator

tlaurion commented Aug 15, 2023

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

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 added a commit to tlaurion/heads that referenced this pull request Aug 15, 2023
tlaurion added a commit to tlaurion/heads that referenced this pull request Aug 15, 2023
…d on top of linuxboot#1417 and linuxboot#1462

PoC: reuse 4.19 buildstack to make clear if there is a gain or not, since nv41/ns50 are based on x230-hotp-maximized which wil be cached after clean build
tlaurion added a commit to tlaurion/heads that referenced this pull request Aug 15, 2023
CircleCI: depend on NV41 for save_cache
Makefile: consider that coreboot-git is now shared between forks on x86 (Nitrokey/Purism share build/x86/coreboot-git now)

Addressesses requested change at linuxboot#1417 (review)
tlaurion added a commit to tlaurion/heads that referenced this pull request Aug 15, 2023
@tlaurion tlaurion mentioned this pull request Aug 15, 2023
@tlaurion
Copy link
Collaborator

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

tlaurion added a commit to tlaurion/heads that referenced this pull request Aug 18, 2023
@tlaurion
Copy link
Collaborator

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 tlaurion closed this Aug 18, 2023
daringer pushed a commit to Nitrokey/heads that referenced this pull request Aug 30, 2023
@daringer daringer mentioned this pull request Aug 30, 2023
@tlaurion tlaurion changed the title add Nitropad NV41/NS50 TPM2 boards / NK3 support add Nitropad NV41/NS50 TPM2 boards Aug 30, 2023
@tlaurion
Copy link
Collaborator

reopen and comment doesn't work :(
2023-08-30-105512

daringer pushed a commit to Nitrokey/heads that referenced this pull request Sep 5, 2023
@nestire
Copy link
Contributor

nestire commented Sep 6, 2023

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
Copy link
Collaborator

tlaurion commented Nov 1, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants