Re: [PATCH 1/5] clean up checks against "high_memory" variable

[Borislav Petkov]

On Wed, Apr 10, 2013 at 04:32:50PM -0700, Dave Hansen wrote:
> 
> We have a new debugging check on x86 that has caught a number
> of long-standing bugs.  However, there is a _bit_ of collateral
> damage with things that call __pa(high_memory).
> 
> We are now checking that any addresses passed to __pa() are
> *valid* and can be dereferenced.
> 
> "high_memory", however, is not valid.  It marks the start of
> highmem, and isn't itself a valid pointer.  But, those users
> are really just asking "is this vaddr mapped"?  So, give them
> a helper that does that, plus is also kind to our new
> debugging check.
> 
> Signed-off-by: Dave Hansen <dave@xxxxxxxxxxxxxxxxxx>
> Signed-off-by: Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>

FWIW,

this one already fixes the BUG below I'm seeing when booting 32-bit
Atom guests in qemu.

Tested-by: Borislav Petkov <bp@xxxxxxx>

More testing tomorrow.

[   57.035880] ------------[ cut here ]------------
[   57.036190] kernel BUG at arch/x86/mm/physaddr.c:79!
[   57.036190] invalid opcode: 0000 [#1] PREEMPT SMP 
[   57.036190] Modules linked in:
[   57.036190] Pid: 2555, comm: wdm Tainted: G S      W    3.9.0-rc6+ #5 Bochs Bochs
[   57.036190] EIP: 0060:[<c10321b1>] EFLAGS: 00010206 CPU: 56
[   57.036190] EIP is at __phys_addr+0x71/0x80
[   57.036190] EAX: 00000000 EBX: 373fe000 ECX: 0000000c EDX: 00000000
[   57.036190] ESI: 00000000 EDI: 00002000 EBP: ec509f40 ESP: ec509f3c
[   57.036190]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[   57.036190] CR0: 8005003b CR2: b7620b48 CR3: 2f5b5000 CR4: 000006d0
[   57.036190] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
[   57.036190] DR6: ffff0ff0 DR7: 00000400
[   57.036190] Process wdm (pid: 2555, ti=ec508000 task=ec500000 task.ti=ec508000)
[   57.036190] Stack:
[   57.036190]  00002000 ec509f64 c1304268 ec570000 ec50e300 bf87299c 00002000 ec50e300
[   57.036190]  c1304240 00002000 ec509f8c c1120276 ec509f98 00000000 ed540314 c1304240
[   57.036190]  ec570000 ec50e300 00000000 08065294 ec509fac c1120488 ec509f98 00000000
[   57.036190] Call Trace:
[   57.036190]  [<c1304268>] read_mem+0x28/0xf0
[   57.036190]  [<c1304240>] ? write_mem+0xf0/0xf0
[   57.036190]  [<c1120276>] vfs_read+0x86/0x140
[   57.036190]  [<c1304240>] ? write_mem+0xf0/0xf0
[   57.036190]  [<c1120488>] sys_read+0x48/0x90
[   57.036190]  [<c15231fe>] sysenter_do_call+0x12/0x36
[   57.036190] Code: 39 0b c2 81 c2 00 00 80 00 39 d0 72 cc 8b 15 2c 4c 74 c1 81 ea 00 a0 a4 00 81 e2 00 00 c0 ff 81 ea 00 20 00 00 39 d0 73 b0 0f 0b <0f> 0b 0f 0b 8d 74 26 00 8d bc 27 00 00 00 00 55 89 e5 53 3e 8d
[   57.036190] EIP: [<c10321b1>] __phys_addr+0x71/0x80 SS:ESP 0068:ec509f3c
[   57.619214] ---[ end trace 4e05f3724c460358 ]---

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/