lists.openwall.net   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 23:31:04 +0100
From:   Borislav Petkov <bp@...e.de>
To:     "H. Peter Anvin" <hpa@...or.com>
Cc:     "Kirill A. Shutemov" <kirill@...temov.name>,
        Thomas Gleixner <tglx@...utronix.de>,
        "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        Ingo Molnar <mingo@...hat.com>, x86@...nel.org,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Andy Lutomirski <luto@...capital.net>,
        Cyrill Gorcunov <gorcunov@...nvz.org>,
        Andi Kleen <ak@...ux.intel.com>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCHv2 0/4] x86: 5-level related changes into decompression
 code

On Wed, Nov 29, 2017 at 01:33:28PM -0800, H. Peter Anvin wrote:
> 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.)

A couple of points:

* so this box here has a normal grub installation and apparently grub
jumps to some other entry point.

* I'm not convinced we need to do everything you typed because this is
only a temporary issue and once X86_5LEVEL is complete, it should work.
I mean, it needs to work otherwise forget single-system image and I
don't think we want to give that up.

> 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.

We switch to text mode and dump our message. Can we do that?

I wouldn't want to do any of this back'n'forth between kernel and boot
loader because that sounds fragile, at least to me. And again, I'm
not convinced we should spend too much energy on this as the issue is
temporary AFAICT.

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imend├Ârffer, Jane Smithard, Graham Norton, HRB 21284 (AG N├╝rnberg)
-- 

Powered by blists - more mailing lists