x86: remove NX from video bios area
PATCH v2 1/1 x86: remove NX from video bios area
5bd5a452662bc37c54fb6828db1a3faf87e6511c make area between BIOS_BEGIN and BIOS_END NX when boot machine with ACPI enable.
It make my machine can't boot, system hang with black screen very early.
The more detail, please see:
https://lkml.org/lkml/2011/11/16/84
This patch try to resolve it. Any comment is welcome.
--- arch/x86/include/asm/e820.h | 4 ++++ arch/x86/mm/pageattr.c | 6 ++++++ 2 files changed, 10 insertions(+), 0 deletions(-)
arch/x86/include/asm/e820.h +4 -0
@@ -72,6 +72,10 @@ struct e820map {#define BIOS_BEGIN 0x000a0000#define BIOS_END 0x00100000 +/*we hope this the right video bios range*/ +#define VIDEO_BIOS_BEGIN 0x000c0000 +#define VIDEO_BIOS_END 0x000c7fff +#define BIOS_ROM_BASE 0xffe00000#define BIOS_ROM_END 0xffffffff
arch/x86/mm/pageattr.c +6 -0
@@ -263,6 +263,12 @@ static inline pgprot_t static_protections(pgprot_t prot, unsigned long address,if (pcibios_enabled &&within (pfn,BIOS_BEGIN >>PAGE_SHIFT ,BIOS_END >>PAGE_SHIFT ))pgprot_val (forbidden) |= _PAGE_NX;#endif +/*The video bios area needs to be executable for +*some programs(like v86d for uvesafb) to execute +*video bios functions +*/ +if (!pcibios_enable &&within (pfn,VIDEO_BIOS_BEGIN >>PAGE_SHIFT ,VIDEO_BIOS_END >>PAGE_SHIFT )) +pgprot_val (forbidden) |= _PAGE_NX;/* * The kernel text needs to be executable for obvious reasons
Signature · 1 line
1.7.3.4
H. Peter Anvin
reviewerarch/x86/include/asm/e820.h struct e820map { · line 80
Quoted 7 lines · wangyanqing
arch/x86/include/asm/e820.h +4
-0+/*we hope this the right video bios range*/ +#define VIDEO_BIOS_BEGIN 0x000c0000 +#define VIDEO_BIOS_END 0x000c7fff +#define BIOS_ROM_BASE 0xffe00000#define BIOS_ROM_END 0xffffffff
Ick. This feels increasingly hacky, especially since the above is known to not be the video BIOS range on a lot of reasons.
There is something much more fundamentally wrong here, including why X permission is needed for uvesafb at all.
-hpa
Signature · 2 lines
H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.
Quoted 12 lines · H. Peter Anvin
arch/x86/include/asm/e820.h struct e820map { · line 80
Quoted 7 lines · wangyanqing
arch/x86/include/asm/e820.h +4
-0+/*we hope this the right video bios range*/ +#define VIDEO_BIOS_BEGIN 0x000c0000 +#define VIDEO_BIOS_END 0x000c7fff +#define BIOS_ROM_BASE 0xffe00000#define BIOS_ROM_END 0xffffffffIck. This feels increasingly hacky, especially since the above is known to not be the video BIOS range on a lot of reasons.
Quoted 8 lines
There is something much more fundamentally wrong here, including why X permission is needed for uvesafb at all.
-hpa
Signature · 2 lines
H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.
Sorry for my bad idea!
Indeed v86d have double backend to execute x86 video bios code, one is lrmi(linux real mode interface), another is x86emu.Yesterday, I compile the v86d with x86emu.Below is the new maps:
08048000-0805e000 r-xp 00000000 00:01 3324 /sbin/v86d
0805e000-0805f000 rw-p 00015000 00:01 3324 /sbin/v86d
0805f000-08060000 rw-p 00000000 00:00 0
b7713000-b7733000 rw-s 000e0000 00:01 3234 /dev/mem b7733000-b7742000 rw-s 000c0000 00:01 3234 /dev/mem b7742000-b7762000 rw-s 000a0000 00:01 3234 /dev/mem b7762000-b7763000 rw-s 0009c000 00:01 3234 /dev/mem b7763000-b7764000 rw-s 00000000 00:01 3234 /dev/mem b7764000-b7784000 rw-p 00000000 00:01 3230 /dev/zero b7784000-b7785000 r-xp 00000000 00:00 0 [vdso] bf98a000-bf9ab000 rw-p 00000000 00:00 0 [stack]
As you see, now v86d doesn't need the X permission.But my machine still hang very early(verbose show uvesafb some messages, then black screen, it hangs!)
But if I make the BIOS range X unconditionally, the problem is gone. So we need more hacky.Any comment is welcome.
Sorry again for the bad patch "[PATCH v2] x86: remove NX from video bios area", it even can't compile, and it also can't solve myself problem, I haven't test it before send it out, I willn't make the same mistake again.
Thanks for all you time.
H. Peter Anvin
reviewerQuoted 1 line · wangyanqing
Sorry for my bad idea!
Don't worry... the important thing is that we have a real problem and we're trying to figure it out.
Quoted 16 lines
Indeed v86d have double backend to execute x86 video bios code, one is lrmi(linux real mode interface), another is x86emu.Yesterday, I compile the v86d with x86emu.Below is the new maps:
08048000-0805e000 r-xp 00000000 00:01 3324
/sbin/v86d
0805e000-0805f000 rw-p 00015000 00:01 3324/sbin/v86d
0805f000-08060000 rw-p 00000000 00:00 0b7713000-b7733000 rw-s 000e0000 00:01 3234 /dev/mem b7733000-b7742000 rw-s 000c0000 00:01 3234 /dev/mem b7742000-b7762000 rw-s 000a0000 00:01 3234 /dev/mem b7762000-b7763000 rw-s 0009c000 00:01 3234 /dev/mem b7763000-b7764000 rw-s 00000000 00:01 3234 /dev/mem b7764000-b7784000 rw-p 00000000 00:01 3230 /dev/zero b7784000-b7785000 r-xp 00000000 00:00 0 [vdso] bf98a000-bf9ab000 rw-p 00000000 00:00 0 [stack]
Quoted 6 lines
As you see, now v86d doesn't need the X permission.But my machine still hang very
early(verbose show uvesafb some messages, then black screen, it hangs!)But if I make the BIOS range X unconditionally, the problem is gone. So we need more hacky.Any comment is welcome.
Is there any way you can hook up a serial console to your machine? I suspect that we're getting a kernel panic that we're not seeing.
-hpa
Signature · 2 lines
H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.