linux-kernel - Re: [tip:efi/core] efi/libstub: Make efi_random

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: <20161204141746.GL20785@codeblueprint.co.uk>
Date:   Sun, 4 Dec 2016 14:17:46 +0000
From:   Matt Fleming <matt@...eblueprint.co.uk>
To:     tglx@...utronix.de, peterz@...radead.org, arnd@...db.de,
        mingo@...nel.org, torvalds@...ux-foundation.org,
        linux-kernel@...r.kernel.org, hpa@...or.com,
        ard.biesheuvel@...aro.org
Cc:     linux-tip-commits@...r.kernel.org
Subject: Re: [tip:efi/core] efi/libstub: Make efi_random_alloc() allocate
 below 4 GB on 32-bit

On Thu, 24 Nov, at 10:47:15PM, tip-bot for Ard Biesheuvel wrote:
> Commit-ID:  018edcfac4c3b140366ad51b0907f3becb5bb624
> Gitweb:     http://git.kernel.org/tip/018edcfac4c3b140366ad51b0907f3becb5bb624
> Author:     Ard Biesheuvel <ard.biesheuvel@...aro.org>
> AuthorDate: Thu, 24 Nov 2016 18:02:23 +0000
> Committer:  Ingo Molnar <mingo@...nel.org>
> CommitDate: Fri, 25 Nov 2016 07:15:23 +0100
> 
> efi/libstub: Make efi_random_alloc() allocate below 4 GB on 32-bit
> 
> The UEFI stub executes in the context of the firmware, which identity
> maps the available system RAM, which implies that only memory below
> 4 GB can be used for allocations on 32-bit architectures, even on [L]PAE
> capable hardware.
> 
> So ignore any reported memory above 4 GB in efi_random_alloc(). This
> also fixes a reported build problem on ARM under -Os, where the 64-bit
> logical shift relies on a software routine that the ARM decompressor does
> not provide.
> 
> A second [minor] issue is also fixed, where the '+ 1' is moved out of
> the shift, where it belongs: the reason for its presence is that a
> memory region where start == end should count as a single slot, given
> that 'end' takes the desired size and alignment of the allocation into
> account.
> 
> To clarify the code in this regard, rename start/end to 'first_slot' and
> 'last_slot', respectively, and introduce 'region_end' to describe the
> last usable address of the current region.
> 
> Reported-by: Arnd Bergmann <arnd@...db.de>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@...aro.org>
> Cc: Linus Torvalds <torvalds@...ux-foundation.org>
> Cc: Matt Fleming <matt@...eblueprint.co.uk>
> Cc: Peter Zijlstra <peterz@...radead.org>
> Cc: Thomas Gleixner <tglx@...utronix.de>
> Cc: linux-efi@...r.kernel.org
> Link: http://lkml.kernel.org/r/1480010543-25709-2-git-send-email-ard.biesheuvel@linaro.org
> Signed-off-by: Ingo Molnar <mingo@...nel.org>
> ---
>  drivers/firmware/efi/libstub/random.c | 13 +++++++------
>  1 file changed, 7 insertions(+), 6 deletions(-)

Ard, was this picked up for the correct tip branch? If it fixes a
build failure it should have gone into tip/efi/urgent, right?