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 */
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
