linux-kernel - Re: [PATCH v2 00/14] efi/gop: Refactoring + mode-setting feature

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]

Message-ID: <20200325221315.GB290267@rani.riverdale.lan>
Date:   Wed, 25 Mar 2020 18:13:15 -0400
From:   Arvind Sankar <nivedita@...m.mit.edu>
To:     Hans de Goede <hdegoede@...hat.com>
Cc:     Arvind Sankar <nivedita@...m.mit.edu>,
        Ard Biesheuvel <ardb@...nel.org>, linux-efi@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 00/14] efi/gop: Refactoring + mode-setting feature

On Wed, Mar 25, 2020 at 05:50:19PM +0100, Hans de Goede wrote:
> Hi,
> 
> On 3/20/20 3:00 AM, Arvind Sankar wrote:
> > This series is against tip:efi/core.
> > 
> > Patches 1-9 are small cleanups and refactoring of the code in
> > libstub/gop.c.
> > 
> > The rest of the patches add the ability to use a command-line option to
> > switch the gop's display mode.
> > 
> > The options supported are:
> > video=efifb:mode=n
> >          Choose a specific mode number
> > video=efifb:<xres>x<yres>[-(rgb|bgr|<bpp>)]
> >          Specify mode by resolution and optionally color depth
> > video=efifb:auto
> >          Let the EFI stub choose the highest resolution mode available.
> > 
> > The mode-setting additions increase code size of gop.o by about 3k on
> > x86-64 with EFI_MIXED enabled.
> 
> Thank you for adding me to the Cc. I will add these to my personal
> tree, which I test semi-regular on various hardware.
> 
> I've only looked at patches 10 - 14 and a quick glance these look
> good to me.
> 
> I was worried that you would maybe always enumerate the modes or
> some such, but I see that you have structured things in such a way
> that if the new kernel cmdline options are not used no extra EFI
> calls are made, which make me very happy!
> 
> This way we do not need to worry about this patch-set tripping up
> buggy firmware (which is quite likely to be out there somewhere)
> by making new, previously unused, EFI calls.
> 

Yep. Also, if the option is specified, it does enumerate the modes, but
if the currently set mode matches what the cmdline option wants, it
won't reset the mode, so it shouldn't interfere with seamless boot as
long as the mode doesn't have to be changed.