Re: [PATCH v7 6/6] x86/efi: Safely enable unaccepted memory in UEFI

Dave Hansen
2023-04-05T21:23:24Z

On 4/5/23 13:11, Tom Lendacky wrote:
>>> The thing that worries me is the "Near future firmware" where someone
>>> runs a ~6.4 kernel and has a fast boot experience.  They upgrade to a
>>> newer, "dropped protocol" kernel and their boot gets slower.
>
> Right, so that is what begs the question of when to actually drop the
> call. Or does it really need to be dropped? It's a small patch to
> execute a boot services call, I guess I don't see the big deal of it
> being there.
> If the firmware still has the protocol, the call is made, if it doesn't,
> its not. In the overall support for unaccepted memory, this seems to be
> a very minor piece.

I honestly don't think it's a big deal either, at least on the kernel
side. Maybe it's a bigger deal to the firmware folks on their side.

So, the corrected table looks something like this:

| Kernel |
| |
| Unenlightened | Enlightened | Dropped UEFI |
Firmware | ~5.19?? | ~6.4?? | protocol |
|---------------+-------------+--------------|
Deployed | Slow boot | Slow boot | Slow boot |
Near future | Slow boot | Fast boot | Slow boot |
Far future | 2GB limited | Fast Boot | Fast boot |

But, honestly, I don't see much benefit to the "dropped UEFI protocol".
It adds complexity and will represent a regression either in boot
speeds, or in unenlightened kernels losing RAM when moving to newer
firmware. Neither of those is great.

Looking at this _purely_ from the kernel perspective, I think I'd prefer
this situation:

| Kernel |
| |
| Unenlightened | Enlightened |
Firmware | ~5.19?? | ~6.4?? |
|---------------+-------------+
Deployed | Slow boot | Slow boot |
Future | Slow boot | Fast boot |

and not have future firmware drop support for the handshake protocol.
That way there are no potential regressions.

Is there a compelling reason on the firmware side to drop the
ExitBootServices() protocol that I'm missing?