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

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 linux-hardening linux-cve-announce 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 20:27:05 -0500
From:   Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To:     "H. Peter Anvin" <hpa@...or.com>, daniel.kiper@...cle.com
Cc:     Borislav Petkov <bp@...e.de>,
        "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 03:24:53PM -0800, H. Peter Anvin wrote:
> On 11/29/17 14:31, Borislav Petkov wrote:
> > 
> > A couple of points:
> > 
> > * so this box here has a normal grub installation and apparently grub
> > jumps to some other entry point.

Ouch. Perhaps you can report this on grub-devel mailing list? And also
what version, since I am not sure if this is a distro-specific version?

> > 
> 
> Yes, Grub as a matter of policy(!) does everything in the most braindead

There is a policy on this? Could you point me out to it - it would
be enlightening to read it :-)

> way possible.  You have to use "linux16" or "linuxefi" to make it do
> something sane.

The Linux bootparams structure is _only_ for Linux. Or are there other
OSes that use the same structure to pass information?

AFAICT the linuxefi does not exist upstream.
> 
> > * 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?
> 
> What is text mode?  It is hardware that is going away(*), and you don't
> even know if you have a display screen on your system at all, or how
> you'd have to configure your display hardware even if it is "mostly" VGA.
> 
> > 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.
> 
> Well, it's not just limited to 5-level mode; it's kind a general issue.
> We have had this issue for a very, very long time -- all the way back to
> i386 PAE at the very least.  I'm personally OK with triple-faulting the
> CPU in this case.
> 
> 	-hpa
> 
> 
> (*) And for good reason -- it is completely memory-latency-bound as you
>     have an indirect reference for every byte you fetch.  In a UMA
>     system this sucks up an insane amount of system bandwidth, unless
>     you are willing to burn the area of having a 16K SRAM cache.
> 
>     VGA hardware, additionally, has a bunch of insane operations that
>     have to be memory-mapped.  The resulting hardware screws with
>     pretty much any sane GPU implementation, so I'm fully expecting that
>     as soon as GPUs no longer come with a CBIOS option ROM VGA hardware
>     will be dropped more or less immediately.

Woot! RIP VGA..