linux-kernel - [tip:core/efi] acpi/apei: Use appropriate pgprot

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <tip-8ece249a811e93d3f60e3f1ebdc86c7e7a95bdbf@git.kernel.org>
Date:	Mon, 14 Sep 2015 05:18:59 -0700
From:	"tip-bot for Jonathan (Zhixiong) Zhang" <tipbot@...or.com>
To:	linux-tip-commits@...r.kernel.org
Cc:	matt.fleming@...el.com, bp@...e.de, matt@...eblueprint.co.uk,
	tglx@...utronix.de, linux-kernel@...r.kernel.org, mingo@...nel.org,
	zjzhang@...eaurora.org, peterz@...radead.org,
	torvalds@...ux-foundation.org, hpa@...or.com
Subject: [tip:core/efi] acpi/apei:
  Use appropriate pgprot_t to map GHES memory

Commit-ID:  8ece249a811e93d3f60e3f1ebdc86c7e7a95bdbf
Gitweb:     http://git.kernel.org/tip/8ece249a811e93d3f60e3f1ebdc86c7e7a95bdbf
Author:     Jonathan (Zhixiong) Zhang <zjzhang@...eaurora.org>
AuthorDate: Fri, 4 Sep 2015 14:11:42 +0100
Committer:  Ingo Molnar <mingo@...nel.org>
CommitDate: Mon, 14 Sep 2015 11:40:04 +0200

acpi/apei: Use appropriate pgprot_t to map GHES memory

If the ACPI APEI firmware handles hardware error first (called
"firmware first handling"), the firmware updates the GHES memory
region with hardware error record (called "generic hardware
error record"). Essentially the firmware writes hardware error
records in the GHES memory region, triggers an NMI/interrupt,
then the GHES driver goes off and grabs the error record from
the GHES region.

The kernel currently maps the GHES memory region as cacheable
(PAGE_KERNEL) for all architectures. However, on some arm64
platforms, there is a mismatch between how the kernel maps the
GHES region (PAGE_KERNEL) and how the firmware maps it
(EFI_MEMORY_UC, ie. uncacheable), leading to the possibility of
the kernel GHES driver reading stale data from the cache when it
receives the interrupt.

With stale data being read, the kernel is unaware there is new
hardware error to be handled when there actually is; this may
lead to further damage in various scenarios, such as error
propagation caused data corruption. If uncorrected error (such
as double bit ECC error) happened in memory operation and if the
kernel is unaware of such an event happening, errorneous data may
be propagated to the disk.

Instead GHES memory region should be mapped with page protection
type according to what is returned from arch_apei_get_mem_attribute().

Signed-off-by: Jonathan (Zhixiong) Zhang <zjzhang@...eaurora.org>
Signed-off-by: Matt Fleming <matt.fleming@...el.com>
[ Small stylistic tweaks. ]
Reviewed-by: Matt Fleming <matt@...eblueprint.co.uk>
Acked-by: Borislav Petkov <bp@...e.de>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Peter Zijlstra <peterz@...radead.org>
Cc: Thomas Gleixner <tglx@...utronix.de>
Link: http://lkml.kernel.org/r/1441372302-23242-3-git-send-email-matt@codeblueprint.co.uk
Signed-off-by: Ingo Molnar <mingo@...nel.org>
---
 drivers/acpi/apei/ghes.c | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 2bfd53c..e661695 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -161,11 +161,15 @@ static void __iomem *ghes_ioremap_pfn_nmi(u64 pfn)

 static void __iomem *ghes_ioremap_pfn_irq(u64 pfn)
 {
-	unsigned long vaddr;
+	unsigned long vaddr, paddr;
+	pgprot_t prot;

 	vaddr = (unsigned long)GHES_IOREMAP_IRQ_PAGE(ghes_ioremap_area->addr);
-	ioremap_page_range(vaddr, vaddr + PAGE_SIZE,
-			   pfn << PAGE_SHIFT, PAGE_KERNEL);
+
+	paddr = pfn << PAGE_SHIFT;
+	prot = arch_apei_get_mem_attribute(paddr);
+
+	ioremap_page_range(vaddr, vaddr + PAGE_SIZE, paddr, prot);

 	return (void __iomem *)vaddr;
 }
--
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/