lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 29 Nov 2017 13:33:28 -0800
From:   "H. Peter Anvin" <>
To:     Borislav Petkov <>
Cc:     "Kirill A. Shutemov" <>,
        Thomas Gleixner <>,
        "Kirill A. Shutemov" <>,
        Ingo Molnar <>,,
        Linus Torvalds <>,
        Andy Lutomirski <>,
        Cyrill Gorcunov <>,
        Andi Kleen <>,,
Subject: Re: [PATCHv2 0/4] x86: 5-level related changes into decompression

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.


(*) 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:

	dec %ax
	mov $0,%ax
	jmp 16f
	jmp 32f
	jmp code_64
32:	jmp code_32
16:	/* Arbitrary 16-bit code can start here */

Powered by blists - more mailing lists