Upgrade to cryptsetup 2.3 and make cryptsetup1/cryptsetup2 optionals

[root-hardenedvault]

continue the work of #749 :
.la files turn out to be unnecessary for linking. They may even hinder the linking sometimes. By removing them from install, the cryptsetup finally gets built and working.

[tlaurion]

@Thrilleratplay @root-hardenedvault : Huston, We have a problem!

There is not enough space to do anything anymore without having ME cleaned and that space migrated into BIOS region of xx20 and xx30 boards. Let's remember that those x230 and t430 have lost e1000e (Ethernet) support and dropbear in master. Trying to build and integrate newer cryptsetup fails at:

t430/util/cbfstool/cbfstool t430/coreboot.pre.tmp add-payload -f ../../build/t430/bzImage -n fallback/payload  -c none  -r COREBOOT   -C "intel_iommu=igfx_off quiet" -I "../../build/t430/initrd.cpio.xz"
E: Could not add [../../build/t430/bzImage, 7109060 bytes (6942 KB)@0x0]; too big?
E: Failed to add '../../build/t430/bzImage' into ROM image.
E: Failed while operating on 'COREBOOT' region!
E: The image will be left unmodified.
make[1]: *** [Makefile.inc:920: t430/coreboot.pre] Error 1
rm t430/util/cbfstool/fmd_scanner.c t430/util/cbfstool/fmd_parser.c
make[1]: Leaving directory '/root/project/build/coreboot-4.8.1'
make: *** [Makefile:442: /root/project/build/coreboot-4.8.1/t430/.build] Error 1

#590 is now a reality. t430 and x230 won't have enough space unless #703
x220 and t420 would be able to have tools versions unless #877 and something similar to #703 is pushed to master.

[Thrilleratplay]

Let's remember that those x230 and t430 have lost e1000e (Ethernet) support and dropbear in master

[ plays Taps for fallen heroes ]

@tlaurion I am starting on IFD generation and I am not sure how long it will take. In the mean time, I would suggest adding prefigured IFD binaries under /blobs, as initially suggested here. The IFD from my x230 and T430 look identical except for the ME version, so one IFD likely be used for the X230, T430 and T530. There are a few other differences between the X220 and X230, so a separate on will likely need to be added to for the X220, T420 and T520 Lenovos.

[tlaurion]

Let's remember that those x230 and t430 have lost e1000e (Ethernet) support and dropbear in master

[ plays Taps for fallen heroes ]

@tlaurion I am starting on IFD generation and I am not sure how long it will take. In the mean time, I would suggest adding prefigured IFD binaries under /blobs, as initially suggested here. The IFD from my x230 and T430 look identical except for the ME version, so one IFD likely be used for the X230, T430 and T530. There are a few other differences between the X220 and X230, so a separate on will likely need to be added to for the X220, T420 and T520 Lenovos.

@Thrilleratplay I have no problem dumping modified IFD there, but as said under #873, the main focus would be to modify coreboot module (I think) so that bincfg and ifdtool are built and in path, while xx30_blobs module could make sure me_cleaner is downloaded and in path and finding a way to be able to call download/verify lenovo downloaded exe file and run innoextract on it, then call me_cleaner on it. Doing so would fix the stage for more xx20 and xx30 Heads inclusion.

(While #590 is still needed unless we are ready to give up on xx20 soon, this approach giving us ~7.5m of total space for xx20 where ~11.5m is available for xx30 + reproducibility)

[root-hardenedvault]

According to the test: if GPGv1 is used, 8MB flash can be fit.

[tlaurion]

According to the test: if GPGv1 is used, 8MB flash can be fit.

Unfortunately, GPGv1 doesn't support 4096 RSA keys which was the reason for the initial GPG toolstack upgrade, and where I did the maximum I could find to cut it down to the smallest possible per configure options.

[tlaurion]

@root-hardenedvault Can cryptsetup (and new dependencies) be hammered down and made smaller?

[root-hardenedvault]

GPGv1 is just unable to generate RSA4096, but it supports the usage of imported existing RSA4096 keys.

[tlaurion]

@root-hardenedvault : I will try to take a look into new added dependencies and reducing general footprint as it was done for latest GPG2 LTS toolstack upgrade.

Going back to GPG1 is not an option where key generation is kinda mandatory under Heads otherwise Heads is useable only per geeks to obtain added security.

[root-hardenedvault]

Update the title and PR due to the info by cryptsetup-2.2 don't have the size issue at #893

[tlaurion]

@root-hardenedvault : if there is any new host build requirements, please cherry-pick tlaurion@38a5fc8 and modify .circleci/config.yml apt line accordingly for easier testing and reproducibility. It should build on CircleCI and be tested (I take artifact for boards, flash on board test for regression) prior of merging.

[tlaurion]

@root-hardenedvault :
End of build log

2020-12-10 21:01:25+00:00 WGET https://www.kernel.org/pub/linux/utils/cryptsetup/v2.2/cryptsetup-.tar.xz
if ! wget -O "/root/project/packages/cryptsetup-2.2.2.tar.xz.tmp" https://www.kernel.org/pub/linux/utils/cryptsetup/v2.2/cryptsetup-.tar.xz ; then exit 1 ; fi ; mv "/root/project/packages/cryptsetup-2.2.2.tar.xz.tmp" "/root/project/packages/cryptsetup-2.2.2.tar.xz" 
--2020-12-10 21:01:25--  https://www.kernel.org/pub/linux/utils/cryptsetup/v2.2/cryptsetup-.tar.xz
Resolving www.kernel.org (www.kernel.org)... 147.75.58.133, 2604:1380:4020:600::1
Connecting to www.kernel.org (www.kernel.org)|147.75.58.133|:443... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://mirrors.edge.kernel.org/pub/linux/utils/cryptsetup/v2.2/cryptsetup-.tar.xz [following]
--2020-12-10 21:01:25--  https://mirrors.edge.kernel.org/pub/linux/utils/cryptsetup/v2.2/cryptsetup-.tar.xz
Resolving mirrors.edge.kernel.org (mirrors.edge.kernel.org)... 147.75.197.195, 2604:1380:1:3600::1
Connecting to mirrors.edge.kernel.org (mirrors.edge.kernel.org)|147.75.197.195|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2020-12-10 21:01:25 ERROR 404: Not Found.

[tlaurion]

@root-hardenedvault: Please include changes under tlaurion@53f26cd

And keep an eye on https://circleci.com/gh/tlaurion/heads/694?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link

[tlaurion]

Ommited:
cryptsetup2_url := https://www.kernel.org/pub/linux/utils/cryptsetup/v2.2/cryptsetup-$(cryptsetup_version).tar.xz ->
cryptsetup2_url := https://www.kernel.org/pub/linux/utils/cryptsetup/v2.2/cryptsetup-$(cryptsetup2_version).tar.xz

[root-hardenedvault]

moin, the updated commit seems having conflicts with tlaurion/heads@53f26cd. Can you rebase it again?

[osresearch]

If we're going to bump the crytpsetup2 option, 2.3.4 has added a resilient online re-encryption option that is nice for a recovery mode to be able to add encryption to a plaintext system, or to re-encrypt with a new key. https://okozina.fedorapeople.org/online-disk-reencryption-with-luks2-compact.pdf

Never mind, I see that this patch has already gone to the 2.3 release, but the title wasn't updated.

[tlaurion]

If we're going to bump the crytpsetup2 option, 2.3.4 has added a resilient online re-encryption option that is nice for a recovery mode to be able to add encryption to a plaintext system, or to re-encrypt with a new key. https://okozina.fedorapeople.org/online-disk-reencryption-with-luks2-compact.pdf

Never mind, I see that this patch has already gone to the 2.3 release, but the title wasn't updated.

This PR changed cryptsetup 2.3 -> 2.2.
@osresearch: You are saying that cryptsetup-reencrypt would not be freature equal to cryptsetup 1 under cryptsetup 2.2?

@MOIN @root-hardenedvault: any reason why 2.3 was downgraded to 2.2?

[qf0]

https://nvd.nist.gov/vuln/detail/CVE-2020-14382#match-5995976
Need to update to cryptsetup 2.3 due to vulnerability in cryptsetup 2.2...

[root-hardenedvault]

the reason it downgraded to v2.2 because it reduced the size. As the security issue, the current cryptsetup version changed to v2.3.3

[tlaurion]

Boards configs can now be changed to depend on cryptsetup2 if SPI flash size permits it.
Others with space constrains can still rely on unchanged cryptsetup module.

QubesOS 4.1 can now be installed. Tested from https://app.circleci.com/jobs/github/tlaurion/heads/770?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link by @blobless

[alex-nitrokey]

Boards configs can now be changed to depend on cryptsetup2 if SPI flash size permits it.
Others with space constrains can still rely on unchanged cryptsetup module.

How? I would have thought we need to declare a CONFIG here for this to work or am I misleaded? Is 2.3 used anywhere yet?

Thanks for this PR anyway!

[tlaurion]

@alex-nitrokey This whole section in Makefile is redundant if declared in modules. In this case if cryptsetup2 is declared in board config, you got it.

[tlaurion]

Is 2.3 used anywhere yet?

@alex-nitrokey It was tested here: #789 (comment) where I tested only cryptsetup1 for regression under x230-maximized.

So newer Xen patches under QubesOS 4.1 fixed real mode booting, while this cryptsetup2 was tested functional to boot installed QubesOS 4.1.

reencryption was not tested yet for regression on 1 but should not have any impact, neither on cryptsetup2.