In accordance with issue #53, we must only use the PartUUID for root=
entries when we *know* that the partition definitely resides on a GPT
disk.
Whilst an EFI System Partition must live on a GPT disk to be considered
a valid ESP, there is no such constraint on the rootfs itself. Cases
emerged during testing of an MBR rootfs partition, with a GPT disk used
to house the ESP itself.
This change ensures we only ever write a root=PARTUUID if we're fully
certain of the topology, otherwise all bootloaders will automatically
fall back to root=UUID entries.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
Previously the modify_bootloader invocation would attempt to reinit itself
with the abs_bootdir. However, in the instance of a native image, we've
had no reason to set a new boot_dir, thus this value is now NULL, leading
to set_boot_dir to fail for the first time.
Once this is set here, i.e. because we're looking at a real root, we
fire off the reinspection and everything "just works".
This change helps, in part, issue #54.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
In the event that the boot dir exists, we can realpath it to collapse our
returned path to remove any double slashes which in turn would've stopped
the lookup function working for cbm_is_mounted, when determining if the ESP
is already mounted or not.
This helps, in part, issue #54.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
The logic is now changed per issue #54 to properly isolate each image
configuration, and to make the previously added selection test suite,
actually pass.
When we can get_legacy_boot_device, we know we have GPT|UEFI, and hand
off immediately with this device. Likewise, when we can locate the ESP
readily (booted native) with get_boot_device, we can hand off immediately
with this device too.
When we do NOT have a boot device, things get a bit trickier. Previously
we would incorrectly fallback to GRUB2. Now, we check whether we're in image
mode or not, which allows us to directly inspect our host system for further
hints. When in native (!image) mode, we can determine immediately whether it
is a UEFI or Legacy Boot system, by checking for the presence of the vfs
path /sys/firmware/efi.
If we've got this far, and haven't been able to isolate native UEFI/Legacy,
or find them on the GPT disk, we throw caution to the wind and assume we
must be dealing with a UEFI device.
In terms of restrictions, this change mandates that the user only try to
repair and interact with their system via clr-boot-manager using the *same*
boot method as they used to install it, i.e. if it is a UEFI installation
you must also be booted using UEFI.
This is not an insane restriction, as we'll be adding EFI variables support
in future, which will *mandate* the existence of /sys/firmware/efi/efivars
to be able to register.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
This test exposes bugs within the core cbm_inspect_root function, by
validating exactly *which* bootloader we select depending on the system
topology.
The tests show that the majority of cases are handled properly, however
when encountering a UEFI system, and we have not been able to explicitly
find the ESP (which is allowed to be mounted already), we fail to select
the UEFI capability, and *very* incorrectly fallback to GRUB2.
Obviously this is highly broken but the test suite is required to develop
the correct functionality, whilst being able to validate changes for *all*
of the possible configurations.
This test is required for issue #54.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
The README now indicates that the project isn't UEFI-specific anymore,
and shows (briefly) how a vendor would integrate clr-boot-manager into
their OS/distro.
Notably we actually now talk about the kernel management benefits, which
are actually far more interesting than the bootloader management parts.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
Many distributions permit building out of tree modules against the headers
for each kernel. To allow this to happen in a safely managed fashion, CBM
must be able to remove these paths from disk and allow the software
deployment mechanism to mark these paths as resident.
The net effect is that one can roll back to an older kernel, and still have
the correct headers available for kernel module compilation.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
These are "permanent" paths in the existing implementations of CBM
compatible distros, so they should be removed from the /usr/lib/kernel
tree when removing any of the managed kernels.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
This mechanism is used as a fallback when all other methods are unavailable,
i.e. a non GPT non UEFI disk. The basic workflow is as follows:
- Create /etc/grub.d/10_* files containing our wanted boot configuration
- Add necessary shell script glue for grub-mkconfig environment
- Remove any default /vmlinuz /initrd.img symlinks for "default" detection
- Invoke "grub-mkconfig" to cause the grub.d files to be executed
- Restore default /vmlinuz /initrd.img symlinks for dual boot compatibility
The separate namespacing ensures GRUB can never *natively* detect the CBM
managed kernels, and we're free to integrate in this fashion. Due to a number
of severe limitations in the GRUB2 machinery & tooling, we do NOT manage the
actual bootloader itself, rather, the entries for boot.
The GRUB2 bootloader should be installed by the operating system installer and
managed outside the domain of CBM. In the world of UEFI we're able to provide
automatic bootloader updates due to enforced sanity in the protocols and
specifications available to us. In the legacy world, we'd have to consider
a plethora of locations for, and versions of, GRUB2, to provide the binary
management. Thus, it is considered out of scope.
Another key limitation to this approach is that CBM should really be invoked
in "native" mode, that is to say, with chroot from installer or on the native
host. This is due to grub-mkconfig hardcoding the locations of the script
assets to host-side only. An OS installer should chroot into the environment
before invoking "clr-boot-manager update".
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
The primary difference between our "core" bootloaders and the upcoming GRUB2
support, is that in terms of legacy, syslinux is only used to support a GPT
disk.
As such our inspection of the root checks if one of the boot-grab methods
actually succeeded, and if so, enforce the GPT mask. This is because both
of the probe methods are GPT-specific, with the legacy method erroring out
in the absence of a proper PTUUID, and our UEFI method checking the XDG
bootloader protocol, before using /dev/disk/by-partuuid. This is only
supported on GPT.
This change unlocks the addition of a simplistic GRUB2 implementation because
it will have the LEGACY flags but not the GPT flags, thus the syslinux loader
will never be selected, as long as the GRUB loader is placed *first* in the
array. Likewise, the GRUB loader will never be able to be loaded for the
other configurations because it will never have the GPT flag set.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
In order to meet full UEFI compliance, and to enable secure boot, we must
now install our kernel/initrd assets within the /EFI directory on the ESP.
Additionally, we must maintain our unique namespace within this tree to
avoid collisions and allow sane dual boot strategies.
This change moves kernels + initrds to /EFI/$NAMESPACE, i.e.
/EFI/org.clearlinux. To ensure a sane upgrade experiene, we'll now attempt
to non-fatally remove the *old* kernel bits once we've successfully
installed or removed a given kernel.
To better match the use of the 'initrd-' prefix, the new kernels are
prefixed with 'kernel-' but retain much of the name structure. A full test
is also introduced for this UEFI-specific change, which first performs a
simulated install to the legacy paths, and then attempts an upgrade to the
new namespace, while ensuring retention policies. Care is taken within the
test to ensure old files *are* removed.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
This completely broke the condition to effectively return true == true.
Luckily our *current* tests still pass with this change, however it was
discovered when introducing namespacing.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
We now use a new target anonymous struct within the kernel to define the
final basename paths, to avoid each use of them having to reconstruct the
paths.
Additionally, the initrd logic was fixed to use the *current* kernel, not
the *default kernel* initrd path. As this code was hard to follow due to
the naming of the variables, the code was clarified to distinguish the
default_kernel from the current kernel (k).
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
This change introduces some namespacing within the Kernel struct itself
so that members are now accessed by "->source." and "->meta." to keep them
organised. This makes it far simpler to see *what* is being manipulated as
well as the intent.
This will be followed up with some more changes to include the target fields
as an anonymous struct too, which will help in reducing the duplication in
the various basename/copy/ approaches seen throughout the codebase.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
Though we init with built-in defaults, later in our lifetime we may be
presented with a different looking ESP. This change addresses the test
suite failures I introduced in the last commit, by forcing clr-boot-manager
to re-evaluate the ESP immediately prior to commit operations.
To achieve this, we reinit with either the new ESP mountpoint tree, or with
our existing tree, which will in turn make the specific bootloader recompute
the target paths. As an example, the systemd-class bootloaders will now
be able to cope with "/efi/BOOT" and correctly build the case path for it
on a newly mounted ESP, when internally we expect "/EFI/Boot".
This change is critical in allowing clr-boot-manager to fully respect the
ESP and cope in all dual boot scenarios (i.e dated/lazy installs with the
old "/EFI/BOOT" or "/efi/boot" directories.). In short, this results in a
more robust CBM.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
We may, in certain dual boot scenarios, encounter paths on the ESP that
we don't expect. Previously the use of nc_build_case_correct_path was
relied upon for this, to ensure that even if a directory "EFI" is called
"efi" on the FAT32 ESP, we use the "efi" name, to satisfy both the FAT32
case ignorance, and Linux case sensitive, requirements.
However testing shows that we only actually init the paths *before* mounting
any ESP, meaning we are case sensitive. This test suite change then forces
deliberately case-incorrect paths, and forces clr-boot-manager to compensate
by building the case correct paths.
The next change will change clr-boot-manager to correctly reinit the bootloader
with the newly available paths post-mount stages to ensure we fix this newly
introduced test failure.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
Our log levels are an unsigned enum, so mixing those lead to redundant
checks, i.e. <= 0 when it could never be less than 0. This change forces
a more obvious use of unsigned numbers so we know it's never less than 0.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
The signedness issue was found when compiling with clang, by forcing the
unsigned enum. Also notable was the lack of absolute mask check with the
flags, which is also now corrected.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
Clang recently does support zero initialisation of structs, but even to this
day it continues to complain about them. Unfortunately that makes the code
very ugly and non-obvious. Thus, we silence this warning entirely and rely
on good C initialisation.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
This issue was flagged by clang as GCC seems to be skipping the more obvious
compilation warnings.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
We now make the bootloader management somewhat more intelligent by
selecting them based on a boot *mask*. Instead of limiting conditionals
to one or two more branching conditions, we build a mask from what we
need from a bootloader, to dynamically locate the *most appropriate*
bootloader.
This will help to simplify further bootloader additions (such as GRUB2)
by finetuning the difference between the legacy implementations.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
This is used to describe in an obvious sense the purpose and application
for a given bootloader implementation. For now we'll use this to determine
whether a selected bootloader is being used in UEFI mode or not, and in the
future we can expand on this to dynamically select the correct bootloader
based on the system topology.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
This will help in recovering the coverage numbers that have been lost to
untestable malloc-failure codepaths, by continuing to do exactly the same
thing as before: if malloc-fail, abort().
This also makes the code far simpler and more pleasant to navigate and
removes a huge number of the abort calls from the codebase. Some still
exist but they are both minimal and obvious.
This small, seemingly trivial change, restores almost 2% coverage in the
codebase testing.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
This function will, from the perspective of the client code, *always*
return something. There is no need to check for returns, because if for
any reason clr-boot-manager cannot allocate the memory, it will abort on
the spot.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
This is a very large function and shouldn't be rlined at all, reduce the
overall weight of the os-release parser by making this a shared function.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
This change unblocks distcheck again by adding the new gptmbr faux file
to the EXTRA_DIST set.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
Due to some design enhancements along the way and a shedding of unnecessary
weight, these functions are no longer referenced anywhere in the codebase.
Drop them, as they negatively impact coverage for no good reason.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
We now just leverage the existing defines at build time due to our
new-lack of architecture-size specific support, making the codebase
significantly less complicated.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
This has failed to appear in any version of systemd-boot or derivatives,
and is uncommon enough for CBM's target to not warrant holding onto the
code within our codebase, as it's completely useless without support
being added at the bootloader level for the EFI handover protocol.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
To ensure that new tests are less complex, and that there are no unknown
parameters in the test system, we move all initial bootloader setup to
the test harness.
Additionally, we now ensure we setup the bootloader based on whether the
UEFI configuration is selected, and fallback to syslinux propagation when
this isn't the case. Now all tests are tailored explicitly to use UEFI
or syslinux legacy, leaving less room for error/guesswork.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
This test ensures that the UEFI-specific bootloader removal functionality
does as advertised, and truly does remove all of our "bits" from the
target system when requested.
This test is distinctly more messy than the current tests as it has to
know exactly which files should be gone due to the opaque bootloader
system.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
These tests verify the basic install & update functionality for the
bootloaders, not the kernels. It should be noted that in the case of
syslinux, we have a restricted feature-set. As such we *always* report
that syslinux needs an update when the source file changes, because
it's far cheaper than actually reading the block device itself.
This change also addresses the gptmbr bin file being 1 byte too long,
which was revealed during the development of this test.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
The new testing revealed that when updating from a non CBM managed system
to a CBM managed one, i.e. the running or default kernel is unknown, then
we previously assumed it was always set. This small fix addresses the crash
and unbreaks initrd bits in syslinux.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
This test enables us to mock the upgrade process going from a non CBM
managed system to a CBM managed one, for the first update. Importantly,
it ensures that the kernel transition itself works fine.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
This test checks the basic kernel install functionality in native mode
for both legacy & UEFI boot systems. It is not a comprehensive policy
test.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
This mimics the check-legacy test almost identically, but taking the
inverse road in certain areas to cater specifically for UEFI. Notably,
it also ensures that Legacy Boot is not detected.
This change will allow us to begin fleshing the main test suites out
in parallel to ensure they do not drift.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
This allows humans to look at the generate files during test suite
creation and actually understand what is happening, instead of dealing
with arbitrary version numbers.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
This test adds very basic coverage for doing a basic image installation,
using the syslinux legacy path.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
We now create the relevant GPT structure to allow CBM to detect a legacy
boot device. Currently this is only used for the syslinux bootloader, but
in future will be extended to permit GRUB too.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
This change adds a new skeletal test designed specifically for the
legacy boot codepath. It deliberately fails right now as it constructs
a mocking environment whereby CBM cannot find UEFI *or* legacy boot.
Thus, the following changes will focus on adding the relevant mocking
support for legacy boot, i.e. via syslinux.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
This modifies the harness to initialise UEFI mocking only when specified
in the PlaygroundConfig. As such this now allows us to introduce some
deliberately failing test to allow construction of a legacy mocking codepath.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
All of these tests are actually duplicated in the core of any other
install/remove/update tests we'll define now in our replacement tests.
Thus, by themselves, are completely pointless.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
This test suite asks all the wrong questions and is very much tied
to the old architecture. Thus, we remove it, to pave the way for some
better, more specific, test suites, using full mocking.
Signed-off-by: Ikey Doherty <michael.i.doherty@intel.com>
Ikey Doherty