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: <CAMj1kXE0zyzU9=cCk6HynfvPJGmzJvRDyjvmpNTsDNeEQTwz8A@mail.gmail.com>
Date:   Fri, 13 Oct 2023 12:17:02 +0200
From:   Ard Biesheuvel <ardb@...nel.org>
To:     Nikolay Borisov <nik.borisov@...e.com>,
        Matthew Garrett <mjg59@...f.ucam.org>
Cc:     linux-efi@...r.kernel.org, linux-kernel@...r.kernel.org,
        "kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>
Subject: Re: [PATCH] x86/efistub: Don't try to print after ExitBootService()

(cc Matthew)

On Thu, 12 Oct 2023 at 13:28, Nikolay Borisov <nik.borisov@...e.com> wrote:
>
>
>
> On 12.10.23 г. 13:14 ч., kirill.shutemov@...ux.intel.com wrote:
> > On Wed, Oct 11, 2023 at 10:25:28PM +0300, Nikolay Borisov wrote:
> >> setup_e820() is executed after UEFI's ExitBootService has been called.
> >> This causes the firmware to throw an exception because Console IO
> >> protocol handler is supposed to work only during boot service
> >> environment. As per UEFI 2.9, section 12.1:
> >>
> >>   "This protocol isused to handle input and output of text-based
> >>   information intended for the system user during the operation of code
> >>   in the boot services environment."
> >>
> >> Running a TDX guest with TDVF with unaccepted memory disabled results in
> >> the following output:
> >
> > Oh. My bad.
> >
> > But there's other codepath that does the same. If setup_e820() fails with
> > EFI_BUFFER_TOO_SMALL, efi_stub_entry() would try to print "exit_boot()
> > failed\n".
> >
> > I wouldner if it is feasible to hook up earlyprintk console into
> > efi_printk() machinery for after ExitBootService() case? Silent boot
> > failure is not the best UX.
> >
>
> So looking at the code the only thing which would prevent refactoring to
> exit logic to directly call exit_boot_func etc and setup_e820 before
> calling efi_exit_boot_services is if the memory map changes. The current
> code ensures that we really have the latest memory map version and so
> setup_e820 is called with the latest version.
>
> Ard, how likely it is that the memory map can indeed change between the
> calls to getmemorymap and exitbootservice?

Very likely. Matthew mentioned this to me not too long ago, i.e., that
on real-world platforms, ExitBootServices() typically fails the first
time because of this, and only succeeds the second time (note that the
first call disables async event delivery so the second call is
guaranteed to succeed unless the caller modifies the memory map
themselves)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ