OcLoadConsoleFont currently loads the specified console path from
Resources\Font\\, which can cause vault failures if vault.plist doesn't
include the duplicate path separator. Remove it to match other paths.
Mach-O uses "indirect symbol" ambiguously. The first kind are "indirect
symbols" indicated by their type. They are located in the regular symbol
table, possibly outside the local, external and undefined ranges. Their
value is an index into the string table, which indicates the name of
another symbol they alias. We assume these to only be used by KPIs,
mostly as symbol aliases for deprecated symbol names.
The second kind is the "indirect symbol table", which is merely a flat
list of 32-bit indices into the symbol table.
When the handling code was written, the incorrect assumption was made
that the "indirect symbol table" is a range of "indirect symbols", much
like how local, external and undefined symbols are explicitly indexed.
However, this is not true and causes bugs in handling indirect symbols.
This patch drops this incorrect (and dangerous) assumption and strictly
separates the two concepts. As OpenCore does not inject KPIs, ignore
indirect symbols entirely.
This quirk is needed to boot macOS 10.7 and older when using a 32-bit kernel on a 64-bit UEFI firmware that makes uses of FPU or SSE instructions in runtime services (such as Hyper-V).
Without this flag MSVC produces spurious warning C4324 when the macro is
working as intended.
Add static assert to OcBlitLib.c which fails without this support.
Fix operation of `sign.command` when printable characters occur
immediately before `=BEGIN OC VAULT=`. `strings` finds the location of
the first printable character in such a sequence. `hexdump` automatically
works on 16 byte boundaries, so still finds the correct offset.
Use `BASE_ALIGNAS` to enforce the required alignment, which will not be
correct on all builds unless enforced (note alignment is required purely
for locating the structure correctly from external script as above, not
for reading in C).
Remove struct packing, since structs had better be naturally packed anyway
(if not, reading from them without arbitrary-alignment-safe code, as we
do, would be undefined behaviour). Add static asserts to confirm expected
size as required by `sign.command`.
Update the docs to refer to `sign.command` rather than to include the
signing commands explicitly - otherwise we have two places that need to
be kept in sync for signing commands, and note that the commands in the
two places were already out of sync.
Signed-off-by: Mike Beaton <mjsbeaton@gmail.com>
In GRUB2+blscfg mode:
- Allow grub vars in 'initrd' as well as in 'options'
- Allow multiple initrd files on one 'initrd' line
- Initialise empty $tuned_params and $tuned_initrd grub vars if no
values present, on an optional flag enabled by default (since
we want to make booting major distros easy)
In GRUB2+blscfg mode (seem to be allowed now, not required for fix):
- Allow multiple 'initrd' lines
- Allow multiple 'options' lines
Add variant of OcParseVars which can parse as value-only tokens.
Signed-off-by: Mike Beaton <mjsbeaton@gmail.com>
Note: EFI_SUCCESS does not always mean a signature was found and
verified (which never existed and therefore is not expected to
happen, for a fat slice), but simply that no further verification
of SB status is required and OC image loader should be used.
Resolves: https://github.com/acidanthera/bugtracker/issues/2414
This quirk is needed to boot macOS 10.6 (and probably older) with 32-bit
kernel in 32-bit OVMF. Similar to 64-bit mode, hibernation wake is not
compatible with this quirk.
This change also partially fixes compatibility with a few other quirks
(e.g. AvoidRuntimeDefrag), but they are not really tested.
apfs.efi has W^X errors which require fixup for strict loaders, however
we were only passing the post-sanitised image to OC-wrapped
platform loader, therefore the wrapper in ImageLoader.c cannot
detect that it is an Apple signed binary which should be fixed up.
Which was designed to avoid warnings caused by apparently unused
variables when DEBUG statements are compiled with MDEPKG_NDEBUG
defined, but which is actually causing compilation errors with
improved DEBUG macro.
