[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4D3C7C36.903@free.fr>
Date: Sun, 23 Jan 2011 20:06:30 +0100
From: matthieu castet <castet.matthieu@...e.fr>
To: Lin Ming <ming.m.lin@...el.com>
CC: Peter Zijlstra <peterz@...radead.org>,
Andi Kleen <andi@...stfloor.org>,
Siarhei Liakh <sliakh.lkml@...il.com>,
Xuxian Jiang <jiang@...ncsu.edu>, Ingo Molnar <mingo@...e.hu>,
Arjan van de Ven <arjan@...radead.org>,
lkml <linux-kernel@...r.kernel.org>, tglx <tglx@...utronix.de>
Subject: Re: -tip tree resume fail, bisect to 5bd5a45(x86: Add NX protection
for kernel data)
Lin Ming a écrit :
> On Tue, 2010-11-30 at 19:27 +0800, Peter Zijlstra wrote:
>> On Tue, 2010-11-30 at 13:00 +0800, Lin Ming wrote:
>>> echo 0 > /sys/devices/system/cpu/cpu1/online;
>>> echo 1 > /sys/devices/system/cpu/cpu1/online;
>>>
>>> then machine just reboots...
>>>
I tried to do the same thing on qemu, and the same behavior happened (ie reboot when resuming cpu1).
After enabling qemu log, I found that a triple fault was happening at the beginning of secondary_startup_64
when doing "addq phys_base(%rip), %rax".
Why ?
I suppose because we access data set to NX, but we don't have enabled yet NX in the msr. So the cpu crash due
to "reserved bit check".
If we enable NX before reading data, there is no more crash (patch attached).
Now I am not sure this is the correct fix. I think the problem is that trampoline using kernel page table
is very dangerous. The kernel can have modified them atfer booting !
May be all the paging stuff should have been done in head_64.S. A first one with identity mapping, and the second one for
the real kernel stuff.
Matthieu
View attachment "diff" of type "text/plain" (1065 bytes)
Powered by blists - more mailing lists