linux-kernel - RE: [PATCH] x86, efi: retry ExitBootServices() on failure

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: <51C068C1020000780009C995@nat28.tlf.novell.com>
Date:	Tue, 18 Jun 2013 14:03:45 +0100
From:	"Jan Beulich" <jbeulich@...e.com>
To:	<zacharyb@....com>, <matt@...sole-pimps.org>
Cc:	<matt.fleming@...el.com>, <mjg59@...f.ucam.org>,
	"Joey Lee" <JLee@...e.com>, <linux-efi@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <stable@...r.kernel.org>
Subject: RE: [PATCH] x86, efi: retry ExitBootServices() on failure

>>> Zachary Bobroff <zacharyb@....com> 06/18/13 2:25 AM >>>
> We only need to retry once because of what is in the UEFI specification 2.3.1 Errata
> C.  The exact verbiage is as follows:
>
> The ExitBootServices() function is called by the currently executing EFI OS loader
> image to terminate all boot services. On success, the loader becomes responsible for
> the continued operation of the system. All events of type EVT_SIGNAL_EXIT_BOOT_SERVICES
> must be signaled before ExitBootServices() returns EFI_SUCCESS. The events are
> only signaled once even if ExitBootServices() is called multiple times.
>
> Since the firmware will only signal the ExitBootServices event once, the code that
> has the potential to change the memory map will only be signaled on the first call to
> exit boot services.

Okay, I'm fine with that aspect then. Let's hope everyone plays by that rule.

> Here is the logic for why we need space for the two additional Efi Memory Map
> Descriptors is as follows:
> First, we should think of the size that is returned from the GetMemoryMap as being
> the number of bytes to contain the current memory map.  Once we have the size of
> the current memory map, we, the kernel, have to perform an allocation of memory
> so that we can store the current memory map into some memory that will not be
> overwritten. That allocation has the possibility of increasing the current memory
> map count by one efi_memory_desc_t structure.

Why by one? Splitting some 'free memory' block may result in an increase by more
then one afaict. Assuming the increment can only be one is implying you having
knowledge of the allocator implementation and behavior, which shouldn't be made
use of in kernel code.

Jan

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/