From patchwork Thu Nov 24 18:02:23 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 83978 Delivered-To: patch@linaro.org Received: by 10.140.20.101 with SMTP id 92csp196713qgi; Thu, 24 Nov 2016 10:03:23 -0800 (PST) X-Received: by 10.98.208.70 with SMTP id p67mr3619656pfg.15.1480010603235; Thu, 24 Nov 2016 10:03:23 -0800 (PST) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b14si11810171pli.232.2016.11.24.10.03.22; Thu, 24 Nov 2016 10:03:23 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935243AbcKXSDH (ORCPT + 25 others); Thu, 24 Nov 2016 13:03:07 -0500 Received: from mail-wj0-f171.google.com ([209.85.210.171]:34063 "EHLO mail-wj0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934757AbcKXSDE (ORCPT ); Thu, 24 Nov 2016 13:03:04 -0500 Received: by mail-wj0-f171.google.com with SMTP id mp19so39455104wjc.1 for ; Thu, 24 Nov 2016 10:03:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=Pd08YEU5OLiWFzepBiuskcYt3J48sEnB/bovzVLL70I=; b=dqqPLpmCfAXTrvK4Pq1WXNPi57NqZ1mKNg7CxUtHOw0/B2tDxHjQQ5AzpgVq2oPVFk c0yPjUM9ujyoSfrQzgO1PSCBVc+gsEF8LJ1YuB4wmwe9Br7NqTH2z7NmL5mLsKQp0zLe qkWXG7TvlXgCI5x69DuLLZCNv5CG/bN/Xgh10= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=Pd08YEU5OLiWFzepBiuskcYt3J48sEnB/bovzVLL70I=; b=L9Oms/tM0+x8yoJ1NxA5Zsth95bpb9gyDb1V1y1oPvjl1o1JM4yVoX6asR8+oIl7L+ Fj1sTHvz+ZUFU4BaIG5o3+3CkcpdttBLoHZc4NHXldHLPvv7ymGcyJsoG3f5x6+NKEA8 +79JAlS1uP1uCCQkqa3qEax8yB3X9VfXts7mI4QLww1VdsBunvVRA/lASqNrmfZNDo4X 15iUAwDkiFixngDtPk7hdwycos6yH+zA5I3ii5a3eOXC0wJLD3XN/dY+QWaFE1GFoS9x zD1mhT/Prg1BMgKPAS2y3awgnsqHPNwF/xODUfNEvEtOKvUBt9Y582EEFS582kH8utH9 7mdQ== X-Gm-Message-State: AKaTC002LBw41daLoIbgJlQ9yDieWQruuilTc/yVEcJYJytiawuxcede8nG1DONu+hOVfDNe X-Received: by 10.194.200.69 with SMTP id jq5mr3421765wjc.93.1480010583050; Thu, 24 Nov 2016 10:03:03 -0800 (PST) Received: from localhost.localdomain ([160.163.23.103]) by smtp.gmail.com with ESMTPSA id js10sm42980285wjb.19.2016.11.24.10.03.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 24 Nov 2016 10:03:02 -0800 (PST) From: Ard Biesheuvel To: Ingo Molnar , Thomas Gleixner , "H . Peter Anvin" Cc: Ard Biesheuvel , linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org, Matt Fleming Subject: [PATCH] efi/libstub: Make efi_random_alloc() allocate below 4 GB on 32-bit Date: Thu, 24 Nov 2016 18:02:23 +0000 Message-Id: <1480010543-25709-2-git-send-email-ard.biesheuvel@linaro.org> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1480010543-25709-1-git-send-email-ard.biesheuvel@linaro.org> References: <1480010543-25709-1-git-send-email-ard.biesheuvel@linaro.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 Cc: Matt Fleming Signed-off-by: Ard Biesheuvel --- drivers/firmware/efi/libstub/random.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) -- 2.7.4 diff --git a/drivers/firmware/efi/libstub/random.c b/drivers/firmware/efi/libstub/random.c index 3a3feacc329f..63cd3f262b6e 100644 --- a/drivers/firmware/efi/libstub/random.c +++ b/drivers/firmware/efi/libstub/random.c @@ -45,19 +45,21 @@ static unsigned long get_entry_num_slots(efi_memory_desc_t *md, unsigned long align_shift) { unsigned long align = 1UL << align_shift; - u64 start, end; + u64 first_slot, last_slot, region_end; if (md->type != EFI_CONVENTIONAL_MEMORY) return 0; - start = round_up(md->phys_addr, align); - end = round_down(md->phys_addr + md->num_pages * EFI_PAGE_SIZE - size, - align); + region_end = min((u64)ULONG_MAX, + md->phys_addr + md->num_pages * EFI_PAGE_SIZE - 1); - if (start > end) + first_slot = round_up(md->phys_addr, align); + last_slot = round_down(region_end - size + 1, align); + + if (first_slot > last_slot) return 0; - return (end - start + 1) >> align_shift; + return ((unsigned long)(last_slot - first_slot) >> align_shift) + 1; } /*