lkml.org 
[lkml]   [2008]   [Oct]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
Subject[PATCH -tip] kmemcheck: fix crash in PnP BIOS calls
From
From 251667c0cd0bc9d3d3e32ae137f49e51c0bb062c Mon Sep 17 00:00:00 2001
From: Vegard Nossum <vegard.nossum@gmail.com>
Date: Sun, 5 Oct 2008 15:46:30 +0200
Subject: [PATCH] kmemcheck: fix crash in PnP BIOS calls

Ingo Molnar reported this crash:
> PnPBIOS: Scanning system for PnP BIOS support...
> PnPBIOS: Found PnP BIOS installation structure at 0xc00fc550
> PnPBIOS: PnP BIOS version 1.0, entry 0xf0000:0xc580, dseg 0xf0000
> BUG: unable to handle kernel paging request at 0000c6ef

It turns out that BIOS calls are made with a different code segment. So
when kmemcheck tries to dereference the EIP/RIP (using the kernel data
segment register), we get the unhandled page fault.

I think we can solve this by verifying (in the page fault handler) that
the faulting code is using the kernel CS.

Signed-off-by: Vegard Nossum <vegard.nossum@gmail.com>
---
arch/x86/mm/kmemcheck/kmemcheck.c | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/arch/x86/mm/kmemcheck/kmemcheck.c b/arch/x86/mm/kmemcheck/kmemcheck.c
index d649aa7..bd739a4 100644
--- a/arch/x86/mm/kmemcheck/kmemcheck.c
+++ b/arch/x86/mm/kmemcheck/kmemcheck.c
@@ -666,6 +666,17 @@ bool kmemcheck_fault(struct pt_regs *regs, unsigned long address,
pte_t *pte;
unsigned int level;

+ /*
+ * XXX: Is it safe to assume that memory accesses from virtual 86
+ * mode or non-kernel code segments will _never_ access kernel
+ * memory (e.g. tracked pages)? For now, we need this to avoid
+ * invoking kmemcheck for PnP BIOS calls.
+ */
+ if (regs->flags & X86_VM_MASK)
+ return false;
+ if (regs->cs != __KERNEL_CS)
+ return false;
+
pte = lookup_address(address, &level);
if (!pte)
return false;
--
1.5.5.1


\
 
 \ /
  Last update: 2008-10-05 19:27    [W:0.028 / U:4.148 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site