Bash uses .build to keep count of the build number, which conflicts
with heads build system usage of .build to keep track of built modules.
If .build already exists when bash/configure is run it will increment by 1
the build number. This is configurable on the call to the support script
support/mkversion.sh, which is called from the bash/Makefile.
Patching the Makefile template used during bash configuration allows
disabling the build number increment.
Signed-off-by: Daniel Pineda <daniel.pineda@puri.sm>
Most useful to me are:
coreboot.modify_and_save_defconfig_in_place
coreboot.modify_and_save_oldconfig_in_place
linux.modify_and_save_oldconfig_in_place
linux.modify_and_save_defconfig_in_place
Which permit to take current in tree configs and translate them into other format.
This is useful when trying to version bump and build.
Also add helpers to save in versioned version to facilitate change tracking:
linux.generate_and_save-versioned-oldconfig
linux.regenerate_and_save_versioned_defconfig
This isn't in a loop, continue makes no sense. ash had silently
ignored it. Proceeding to the do_boot below is the correct behavior.
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
For partitioned media or when more than one device is present, this
fixes a benign script error that ash had apparently ignored.
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
By default json-c builds as debug instead of release.
Adding CMAKE_BUILD_TYPE=minsizerel ensures it does not
add debug info and also optimizes for file size.
Signed-off-by: Daniel Pineda <daniel.pineda@puri.sm>
- Trace calls need to happen after sourcing /etc/functions not before
- Move sourcing of external files at beginning of file, remove /etc/functions sourcing duplicate
- gpg error redirection was sent to /dev/null where expected to be added to whiptail in case of error (2>&1 instead and redirection to file)
Problem
When using a custom password for TPM, the OEM re-ownership process is broken
Impact
The OEM re-ownership process breaks for any user setting a custom password and not just using 12345678
First appeared
6923fb5e20
Detail
on line 498, if blank, the TPM custom password is overwritten with TPM_PASS_DEF (eg, when no custom password is set by the user installing)
```
if [ "$TPM_PASS" == "" ]; then TPM_PASS=$TPM_PASS_DEF; fi
```
so far so good. $TPM_PASS should be used for all TPM interaction from this point. $TMP_PASS_DEF is now a disposed of variable.
we see that happens when resetting the TPM on line 712 (generate_checksums) is that $TPM_PASS is used (correctly)
```## reset TPM and set password
if [ "$CONFIG_TPM" = "y" ]; then
echo -e "\nResetting TPM...\n"
tpmr reset "$TPM_PASS" >/dev/null 2>/tmp/error
---SNIP
```
The TPM now has either the custom password of the user, or the default of 12345678 depending on user selection.
On line 712, we duck into the generate_checksums sub, which for some reason reverts to TPM_PASS_DEF
```
# create Heads TPM counter
if [ "$CONFIG_TPM" = "y" ];then
if [ "$CONFIG_IGNORE_ROLLBACK" != "y" ]; then
tpmr counter_create \
-pwdo "$TPM_PASS_DEF" \
--SNIP
```
This then, rightly, fails due to
```
Authentication failed (Incorrect Password) (ox1) from TPM_CreateCounter
```
This patch adds ARCH="$(LINUX_ARCH)" to Linux targets working on config
files. Without it, the architecture defaults to that of host, which for
cross-compilation isn't right.
Signed-off-by: Krystian Hebel <krystian.hebel@3mdeb.com>
