this bumps the secboot version to the one with
tpm "legacy" platform key data support, this means using the
ActivateVolumeWithKeyData APIs even with TPM but still using
the non-JSON keys
v2 sealed keys use only when strictly necessary, otherwise
v1 keys are written
to prepare for this we reapply the changes from #10715 that were reverted in #10930
Merge pull request #10930 from anonymouse64/revert-10715-bump-secboot
Reverts #10715
Sadly the new version of secboot seems to auto-upgrade v1 keys to v2, which old recovery systems and even the currently published initrds/kernels do not understand so they fail to unlock the encrypted partitions in the initrd.
This PR includes #10929 which adds the following tests:
* test from stable snapd + stable kernel refreshing to snapd from the PR
* test from stable kernel + snapd from the PR
and for each variant then do something which triggers a reseal operation and a reboot to ensure that the new snapd will not break old recovery system kernels
This will be necessary for more complicated test cases in the gadget package,
so time to rip this band-aid and get rid of the old methods.
Signed-off-by: Ian Johnson <ian.johnson@canonical.com>
Instead of simply returning a "bool" from checkEncryption() return
a new encryption type that can be: None, Cryptsetup, DeviceSetupHook.
This prepares for the case when also need to support inline crypto
hardware like the Qualcomm ICE system that uses a DeviceSetupHook
instead of cryptsetup.
Remove duplicate import, and use existing/long-standing snapcore
secboot import called sb.
Fixes: 37fc0edcdc
Signed-off-by: Dimitri John Ledkov <dimitri.ledkov@canonical.com>
* osutil: rework TotalSystemMemory to TotalUsableMemory
This commit renames total TotalSystemMemory to TotalUsableMemory
and also changes the code to take the CmaTotal into account. This
is the memory reserved by the "Contiguous Memory Allocator" and
it is not usable for normal processes. This kind of memory is
used e.g. by the framebuffer of the Raspberry Pi or by DSPs on
certain boards.
* secboot: use half the mem for KDF in AddRecoveryKey
Instead of benchmarking the KDF parameters for the recovery key
(which takes some time to run) we can also use defaults for the
KDF parameters. The defaults suggested by Chris are "4 iterations"
and half the usable memory. This commit implements the suggestions.
* secboot: update KDF memory heuristic
After discussing with Chris and Samuele we updated the KDF memory
heuristic so that it takes more parameters in mind. It now
considers the usable memory and substracts a hardcoded 384MB
that is required to have a working system (a bit of a conservative
estiamte) and then takes half of this for the KDF memory.
* osutil,secboot: fix typos
* secboot: add comment about minimum mem
The main encryption key is high entropy 256bit already so there is
no need to use a strong KDF on top of this. There was a PR already
that switched this to 32MB but it turns out that 32KB is enough.
* vendor: move to snapshot-4c814e1 branch with KDF fixes
This commit moves our secboot code to the `snapshot-4c814e1` branch
that contains fixes around the KDF benchmarking. This will improve
the install performance.
* secboot: update code to latest api
* secboot: hardcode KDFOptions to avoid benchmarking them and speed up the process
It is desired that the seal/reseal code only operates on the input provided in
modeenv rather than poking other external structures. The change decouples the
lower level code from accessing the model directly.
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
