HFS+ driver redesign

[vit9696]

Currently we recommend using Apple HfsPlus.efi driver to enable HFS+ file system support for the following tasks:

• Loading DMG recovery images in all operating systems up to 10.15 inclusive.
• Loading macOS on HFS+ up to 10.13 inclusive (I believe there is no legit way to install macOS on HFS+ otherwise).
• Loading macOS installers up to 10.14 or even 10.15 inclusive (they still use HFS+).

The issue with this driver is that:

• We have no control on this driver and cannot track its security issues. While we can try to keep it up to date, we know that different firmwares have different implementations of this driver. For example, older CPUs without RDRAND support cannot run the driver from newer Mac models due to stack canary requirements, and we do not know how up to date are drivers from legacy platforms.
• We cannot influence ScanPolicy compatibility with this driver, and thus avoid connecting the driver to potentially risky drives (e.g. USB).
• It is closed-source, and while it not particularly a problem, we cannot distribute it or even detect any problems with it.

As an alternative we have VBoxHfs.efi driver in AppleSupportPkg, but it has no less issues:

• It is GPLv2, so we cannot distribute it with OpenCore, and that license is just project cancer no matter how you look at it.
• It is extremely slow as mentioned in https://github.com/acidanthera/bugtracker/issues/399.
• It did not undergo any security review and also does not support ScanPolicy logic.

Taking all things into consideration, I believe we need to invest in the development of a new performant and secure HFS+ driver with a friendly license. There are several routes for this, and I am not sure which one we can take.

• Adopt fsw code from rEFIt before VirtualBox contributed to it[1] and perhaps use J.Somlo's driver as a base[2]. This variant is very similar to VBoxHfs, and its only benefit is BSD-style license. I do not believe it is more performant and it is likely even less stable.
• Adopt NetBSD driver from NetBSD kernel[3] or some adopted project like hfsfuse[4]. It is unknown how fast it is.
• Reverse-engineer HfsPlus driver and use it or implement our own driver. I am not positive it is worth it, but it can be based on official Apple sources[5]

There may be some other option I am unaware of.

[1] https://sourceforge.net/p/refit/code/HEAD/tree/trunk/refit/fsw/ [2] https://github.com/gsomlo/edk2/tree/gls-miscopt/OvmfPkg/FswHfsPlus [3] https://github.com/NetBSD/src/tree/trunk/sys/fs/hfs [4] https://github.com/0x09/hfsfuse [5] https://opensource.apple.com/tarballs/hfs/

[shchuko]

Hi. I'm updating series of these OVMF patches to provide booting macOS under QEMU/KVM and QEMU/HVF and same as you met the licensing problem (linking VBoxHfs). My choice was to update this [2] driver.

Here I've already fixed main issues that made macOS stuck on bootloader launch stage: https://github.com/shchuko/OvmfDarwinPkg/tree/master/FswHfsPlus

Now it seems able to boot macOS recovery images (basesystem DMGs) using updated driver. To my mind these fixes can be also useful for your project

[vit9696]

That's great to hear, but you will still need to adopt gAppleBlessed GUID retrieval through the INFO method to let OpenCore properly function with your driver. I guess you can take our fsw_efi_bless_info as a reference (since it is ours, you may use it freely).

[shchuko]

Ok, I'll try to add handling the required GUIDes ASAP