Re: [PATCHv2 0/4] x86: 5-level related changes into decompression code

[H. Peter Anvin]

On 11/29/17 11:19, Borislav Petkov wrote:
> On Wed, Nov 29, 2017 at 11:01:35AM -0800, H. Peter Anvin wrote:
>> We can hang the machine, or we can triple-fault it in the hope of
>> triggering a reset, and that way if the bootloader has been configured
>> with a backup kernel there is a hope of recovery.
> 
> Well, it triple-faults right now and that's not really user-friendly. If
> we can't dump a message than we should make X86_5LEVEL depend on BROKEN
> for the time being...
> 

You can't dump a message about *anything* if the bootloader bypasses the
checks that happen before we leave the firmware behind.  This is what
this is about.  For BIOS or EFI boot that go through the proper stub
functions we will print a message just fine, as we already validate the
"required features" structure (although please do verify that the
relevant words are indeed being checked.)

However, if the bootloader jumps straight into the code what do you
expect it to do?  We have no real concept about what we'd need to do to
issue a message as we really don't know what devices are available on
the system, etc.  If the screen_info field in struct boot_params has
been initialized then we actually *do* know how to write to the screen
-- if you are okay with including a text font etc. since modern systems
boot in graphics mode.

What else could we do?  I guess we could add a new field -- which
bootloaders would have to add support for -- for a callback to the
bootloader in case of an early-detected fatal kernel initialization
error.  This would have some... interesting(*)... issues with it, and
wouldn't resolve anything for existing bootloaders, but perhaps it is a
worthwhile extension going forward.

	-hpa

(*) The bootloader would have to be prepared for a largely undefined CPU
    state, in a rarely executed path.  However, it is arguably no worse
    than what we have now.  Current bootloaders *can* at least know all
    the memory the kernel will use before the kernel's own memory
    management takes over, so it is possible for it to allocate the
    kernel in such a way that its own code/data is preserved.

    It is at least possible to determine which major CPU mode we are
    running in when we get to that entrypoint.  The following code
    snippet will do it:

entry:
	.code16
	dec %ax
	mov $0,%ax
	jmp 16f
	nop
	nop
	jmp 32f
	.code64
	jmp code_64
	.code32
32:	jmp code_32
	.code16
16:	/* Arbitrary 16-bit code can start here */