From patchwork Fri Apr 1 19:10:27 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Matt Fleming X-Patchwork-Id: 64898 Delivered-To: patch@linaro.org Received: by 10.112.199.169 with SMTP id jl9csp902607lbc; Fri, 1 Apr 2016 12:10:33 -0700 (PDT) X-Received: by 10.66.244.233 with SMTP id xj9mr33312295pac.19.1459537833517; Fri, 01 Apr 2016 12:10:33 -0700 (PDT) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id yg4si10721516pab.161.2016.04.01.12.10.33; Fri, 01 Apr 2016 12:10:33 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@codeblueprint-co-uk.20150623.gappssmtp.com; spf=pass (google.com: best guess record for domain of stable-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=stable-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751539AbcDATKc (ORCPT + 3 others); Fri, 1 Apr 2016 15:10:32 -0400 Received: from mail-wm0-f42.google.com ([74.125.82.42]:33550 "EHLO mail-wm0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750938AbcDATKa (ORCPT ); Fri, 1 Apr 2016 15:10:30 -0400 Received: by mail-wm0-f42.google.com with SMTP id f198so4570920wme.0 for ; Fri, 01 Apr 2016 12:10:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codeblueprint-co-uk.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=0wjG/zod4CMzCnnqSIoPEskN72XEARTTgiZMApiRLek=; b=GK7iz9zCygQosi4vNX04oAy0y0NjfCN5qohMUYYcv9ZNBIabUmukoZe+/gVxPbyI6E IUSfy3Z1S4XTm6OApvw6JMgcmUXaBcgzcCqGPKOkiNpr56Hu6+biJVl9wsmt+vzcUw1I 9lcHJZtlvhawtJCfOjzaZpOmLj4rPUfAZIN3LzS33Z/I/ZpJ5cJd3ewgh2lSDlFimC6D J33+K6p4ZwPyZSDhZO01R+/omg8I2gdlpS11POHHgDXBaJzZ6Yn1qLMPOBdqaUriUBOD tZuoP9/nMyeAESoR6q2c2BujJqMHfOgNRfbUWPvoP+kufmSuTvSCFy/fPk3eVByBV5V/ fOkA== 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=0wjG/zod4CMzCnnqSIoPEskN72XEARTTgiZMApiRLek=; b=R5dXzUIpH2W4aAzaCzT+rOR/ohP7MUaJu064JrQPS219OqYuZ+uAXHhZaIixzbN04W ob7BnP0XVttrGfO58gL/pIwzaHtx/m++BhzbvPy47cMrZQL8dBwTIghF7Wb8p6ASvnrP ayrtUJrvPP4Gu+cOixcUqLphnmNtai407XVpoyoe+ihGkOrSaI9FaUFORZno4WdhsaM7 wD+q3mcuLB9nPveozi4PIxQVmxOP2cgOyLYXIJke8+LmqAg8uvaZ3lDZufz96jEIej0Y K2n1OZGmYUibNh4T2hstgXpAanFCFNpeey0Qr/7ZfFoGTF79SHP7zGSDIEHjkZd5mA0e QpuA== X-Gm-Message-State: AD7BkJJnpAA0/POxk1Y1EZZ+ntNTAh/thL9FiHTak8F6n97lPKz6I3UNnBlgftBB3wot7Q== X-Received: by 10.194.92.107 with SMTP id cl11mr12159884wjb.21.1459537828984; Fri, 01 Apr 2016 12:10:28 -0700 (PDT) Received: from localhost (bcdc58e5.skybroadband.com. [188.220.88.229]) by smtp.gmail.com with ESMTPSA id w8sm15358537wjf.19.2016.04.01.12.10.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Apr 2016 12:10:28 -0700 (PDT) From: Matt Fleming To: Ingo Molnar , Thomas Gleixner , "H . Peter Anvin" Cc: Ard Biesheuvel , linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org, Matt Fleming , Jeremy Linton , Leif Lindholm , Mark Langsdorf , Mark Rutland , Mark Salter , stable@vger.kernel.org, Will Deacon Subject: [PATCH] efi/arm64: Don't apply MEMBLOCK_NOMAP to UEFI memory map mapping Date: Fri, 1 Apr 2016 20:10:27 +0100 Message-Id: <1459537827-5005-1-git-send-email-matt@codeblueprint.co.uk> X-Mailer: git-send-email 2.7.3 In-Reply-To: <1459537395-4523-1-git-send-email-matt@codeblueprint.co.uk> References: <1459537395-4523-1-git-send-email-matt@codeblueprint.co.uk> Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Ard Biesheuvel Commit 4dffbfc48d65 ("arm64/efi: mark UEFI reserved regions as MEMBLOCK_NOMAP") updated the mapping logic of both the RuntimeServices regions as well as the kernel's copy of the UEFI memory map to set the MEMBLOCK_NOMAP flag, which causes these regions to be omitted from the kernel direct mapping, and from being covered by a struct page. For the RuntimeServices regions, this is an obvious win, since the contents of these regions have significance to the firmware executable code itself, and are mapped in the EFI page tables using attributes that are described in the UEFI memory map, and which may differ from the attributes we use for mapping system RAM. It also prevents the contents from being modified inadvertently, since the EFI page tables are only live during runtime service invocations. None of these concerns apply to the allocation that covers the UEFI memory map, since it is entirely owned by the kernel. Setting the MEMBLOCK_NOMAP on the region did allow us to use ioremap_cache() to map it both on arm64 and on ARM, since the latter does not allow ioremap_cache() to be used on regions that are covered by a struct page. The ioremap_cache() on ARM restriction will be lifted in the v4.7 timeframe, but in the mean time, it has been reported that commit 4dffbfc48d65 causes a regression on 64k granule kernels. This is due to the fact that, given the 64 KB page size, the region that we end up removing from the kernel direct mapping is rounded up to 64 KB, and this 64 KB page frame may be shared with the initrd when booting via GRUB (which does not align its EFI_LOADER_DATA allocations to 64 KB like the stub does). This will crash the kernel as soon as it tries to access the initrd. Since the issue is specific to arm64, revert back to memblock_reserve()'ing the UEFI memory map when running on arm64. This is a temporary fix for v4.5 and v4.6, and will be superseded in the v4.7 timeframe when we will be able to move back to memblock_reserve() unconditionally. Fixes: 4dffbfc48d65 ("arm64/efi: mark UEFI reserved regions as MEMBLOCK_NOMAP") Reported-by: Mark Salter Signed-off-by: Ard Biesheuvel Acked-by: Will Deacon Cc: Leif Lindholm Cc: Mark Rutland Cc: Jeremy Linton Cc: Mark Langsdorf Cc: # v4.5 Signed-off-by: Matt Fleming --- drivers/firmware/efi/arm-init.c | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) -- 2.7.3 -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c index aa1f743152a2..8714f8c271ba 100644 --- a/drivers/firmware/efi/arm-init.c +++ b/drivers/firmware/efi/arm-init.c @@ -203,7 +203,19 @@ void __init efi_init(void) reserve_regions(); early_memunmap(memmap.map, params.mmap_size); - memblock_mark_nomap(params.mmap & PAGE_MASK, - PAGE_ALIGN(params.mmap_size + - (params.mmap & ~PAGE_MASK))); + + if (IS_ENABLED(CONFIG_ARM)) { + /* + * ARM currently does not allow ioremap_cache() to be called on + * memory regions that are covered by struct page. So remove the + * UEFI memory map from the linear mapping. + */ + memblock_mark_nomap(params.mmap & PAGE_MASK, + PAGE_ALIGN(params.mmap_size + + (params.mmap & ~PAGE_MASK))); + } else { + memblock_reserve(params.mmap & PAGE_MASK, + PAGE_ALIGN(params.mmap_size + + (params.mmap & ~PAGE_MASK))); + } }