[PATCH v2] x86: remove NX from video bios area

[PATCH v2] x86: remove NX from video bios area

[wangyanqing]

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.
Signed-off-by: Wang YanQing <Udknight@gmail.com>
---
 arch/x86/include/asm/e820.h |    4 ++++
 arch/x86/mm/pageattr.c      |    6 ++++++
 2 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/arch/x86/include/asm/e820.h b/arch/x86/include/asm/e820.h
index 908b969..1adc26e 100644
--- a/arch/x86/include/asm/e820.h
+++ b/arch/x86/include/asm/e820.h
@@ -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
 
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index f9e5267..c4e5100 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -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
-- 
1.7.3.4

Re: [PATCH v2] x86: remove NX from video bios area

[H. Peter Anvin]

On 11/17/2011 12:26 AM, wangyanqing wrote:
>  
> +/*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

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: [PATCH v2] x86: remove NX from video bios area

[wangyanqing]

On Thu, Nov 17, 2011 at 06:56:46AM -0800, H. Peter Anvin wrote:
> On 11/17/2011 12:26 AM, wangyanqing wrote:
> >  
> > +/*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
> 
> -- 
> 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.

Re: [PATCH v2] x86: remove NX from video bios area

[H. Peter Anvin]

On 11/17/2011 08:45 PM, wangyanqing wrote:
> 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.

> 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.

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

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.