Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1290909 > unrolled thread

4.4-rc5: ugly warn on: 5 W+X pages found

Started byPavel Machek <pavel@ucw.cz>
First post2015-12-14 09:10 +0100
Last post2015-12-14 13:40 +0100
Articles 12 on this page of 32 — 8 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  4.4-rc5: ugly warn on: 5 W+X pages found Pavel Machek <pavel@ucw.cz> - 2015-12-14 09:10 +0100
    Re: 4.4-rc5: ugly warn on: 5 W+X pages found Borislav Petkov <bp@alien8.de> - 2015-12-14 10:00 +0100
      Re: 4.4-rc5: ugly warn on: 5 W+X pages found Pavel Machek <pavel@ucw.cz> - 2015-12-14 10:10 +0100
        Re: 4.4-rc5: ugly warn on: 5 W+X pages found Borislav Petkov <bp@alien8.de> - 2015-12-14 10:20 +0100
        Re: 4.4-rc5: ugly warn on: 5 W+X pages found Linus Torvalds <torvalds@linux-foundation.org> - 2015-12-14 20:20 +0100
          Re: 4.4-rc5: ugly warn on: 5 W+X pages found Pavel Machek <pavel@ucw.cz> - 2015-12-14 21:30 +0100
            Re: 4.4-rc5: ugly warn on: 5 W+X pages found Andy Lutomirski <luto@amacapital.net> - 2015-12-14 22:10 +0100
              Re: 4.4-rc5: ugly warn on: 5 W+X pages found Arjan van de Ven <arjan@linux.intel.com> - 2015-12-14 22:30 +0100
                Re: 4.4-rc5: ugly warn on: 5 W+X pages found Andy Lutomirski <luto@amacapital.net> - 2015-12-14 23:30 +0100
                  Re: 4.4-rc5: ugly warn on: 5 W+X pages found Pavel Machek <pavel@ucw.cz> - 2015-12-15 10:50 +0100
                    Re: 4.4-rc5: ugly warn on: 5 W+X pages found Linus Torvalds <torvalds@linux-foundation.org> - 2015-12-15 18:50 +0100
                      Re: 4.4-rc5: ugly warn on: 5 W+X pages found Borislav Petkov <bp@alien8.de> - 2015-12-15 19:40 +0100
                        Re: 4.4-rc5: ugly warn on: 5 W+X pages found Linus Torvalds <torvalds@linux-foundation.org> - 2015-12-15 20:10 +0100
                          Re: 4.4-rc5: ugly warn on: 5 W+X pages found Borislav Petkov <bp@alien8.de> - 2015-12-15 20:20 +0100
                      Re: 4.4-rc5: ugly warn on: 5 W+X pages found Andy Lutomirski <luto@amacapital.net> - 2015-12-15 19:50 +0100
                        Re: 4.4-rc5: ugly warn on: 5 W+X pages found Linus Torvalds <torvalds@linux-foundation.org> - 2015-12-15 20:10 +0100
                      Re: 4.4-rc5: ugly warn on: 5 W+X pages found Pavel Machek <pavel@ucw.cz> - 2015-12-15 22:00 +0100
                        4.4.-rc5: lguest causes ugly warn on: 5 W+X pages found Pavel Machek <pavel@ucw.cz> - 2015-12-15 22:20 +0100
                          Re: 4.4.-rc5: lguest causes ugly warn on: 5 W+X pages found Rusty Russell <rusty@rustcorp.com.au> - 2015-12-16 03:30 +0100
                            Re: 4.4.-rc5: lguest causes ugly warn on: 5 W+X pages found Pavel Machek <pavel@ucw.cz> - 2015-12-16 09:20 +0100
                        Re: 4.4-rc5: ugly warn on: 5 W+X pages found Borislav Petkov <bp@alien8.de> - 2015-12-15 22:40 +0100
                          Re: 4.4-rc5: ugly warn on: 5 W+X pages found Pavel Machek <pavel@ucw.cz> - 2015-12-15 23:10 +0100
                            Re: 4.4-rc5: ugly warn on: 5 W+X pages found Borislav Petkov <bp@alien8.de> - 2015-12-15 23:20 +0100
                Re: 4.4-rc5: ugly warn on: 5 W+X pages found Pavel Machek <pavel@ucw.cz> - 2015-12-15 09:00 +0100
                  [PATCH 1/2] x86_32/mm: Set NX in __supported_pte_mask before enabling paging Andy Lutomirski <luto@kernel.org> - 2015-12-15 09:10 +0100
                  [PATCH 2/2] x86/mm: Make kmap_prot into a #define Andy Lutomirski <luto@kernel.org> - 2015-12-15 09:10 +0100
                  [PATCH 0/2] x86/mm: A _PAGE_NX fixlet and a kmap cleanup Andy Lutomirski <luto@kernel.org> - 2015-12-15 09:10 +0100
                  Re: 4.4-rc5: ugly warn on: 5 W+X pages found Arjan van de Ven <arjan@linux.intel.com> - 2015-12-15 14:40 +0100
                    Re: 4.4-rc5: ugly warn on: 5 W+X pages found Pavel Machek <pavel@ucw.cz> - 2015-12-15 15:10 +0100
                      Re: 4.4-rc5: ugly warn on: 5 W+X pages found "H. Peter Anvin" <hpa@zytor.com> - 2015-12-15 17:30 +0100
                        Re: 4.4-rc5: ugly warn on: 5 W+X pages found Pavel Machek <pavel@ucw.cz> - 2015-12-15 18:50 +0100
    Re: 4.4-rc5: ugly warn on: 5 W+X pages found Pavel Machek <pavel@ucw.cz> - 2015-12-14 13:40 +0100

Page 2 of 2 — ← Prev page 1 [2]

#1292554

FromBorislav Petkov <bp@alien8.de>
Date2015-12-15 22:40 +0100
Message-ID<qG5ua-1f9-13@gated-at.bofh.it>
In reply to#1292543
On Tue, Dec 15, 2015 at 09:58:35PM +0100, Pavel Machek wrote:
> [    0.000000] Base memory trampoline at [c009b000] 9b000 size 16384
> [    0.000000] ------------[ cut here ]------------
> [    0.000000] WARNING: CPU: 0 PID: 0 at
> ./arch/x86/include/asm/pgtable.h:357 kernel_physical_mapping_init+0x
> 256/0x395()
> [    0.000000] Modules linked in:
> [    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.4.0-rc5+ #137
> [    0.000000] Hardware name: LENOVO 17097HU/17097HU, BIOS 7BETD8WW
> (2.19 ) 03/31/2011
> [    0.000000]  00000000 00000000 c4e63e90 c42baaf8 00000000 c4e63eac
> c404066b 00000165
> [    0.000000]  c4f134da 00000000 00000000 00000000 c4e63ebc c404070f
> 00000009 00000000
> [    0.000000]  c4e63f18 c4f134da c4e63f00 00000000 00000000 00000000
> 00000000 00000000
> [    0.000000] Call Trace:
> [    0.000000]  [<c42baaf8>] dump_stack+0x41/0x59
> [    0.000000]  [<c404066b>] warn_slowpath_common+0x6b/0xa0
> [    0.000000]  [<c4f134da>] ?
> kernel_physical_mapping_init+0x256/0x395
> [    0.000000]  [<c404070f>] warn_slowpath_null+0xf/0x20
> [    0.000000]  [<c4f134da>] kernel_physical_mapping_init+0x256/0x395
> [    0.000000]  [<c4a4de21>] init_memory_mapping+0x191/0x300
> [    0.000000]  [<c4f12d96>] init_mem_mapping+0xe7/0x1f3

Looks like the ISA range to me:

init_mem_mapping:

	...

        /* the ISA range is always mapped regardless of memory holes */
        init_memory_mapping(0, ISA_END_ADDRESS);

Does that kernel_physical_mapping_init() even pay attention to
__supported_pte_mask and thus _PAGE_NX? I don't see it.

Hmm, not really:

	pgprot_t init_prot = __pgprot(PTE_IDENT_ATTR | _PAGE_PSE);

	...

	prot = PAGE_KERNEL_LARGE_EXEC;

	...

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1292586

FromPavel Machek <pavel@ucw.cz>
Date2015-12-15 23:10 +0100
Message-ID<qG5Xc-1EX-9@gated-at.bofh.it>
In reply to#1292554
On Tue 2015-12-15 22:33:59, Borislav Petkov wrote:
> On Tue, Dec 15, 2015 at 09:58:35PM +0100, Pavel Machek wrote:
> > [    0.000000] Base memory trampoline at [c009b000] 9b000 size 16384
> > [    0.000000] ------------[ cut here ]------------
> > [    0.000000] WARNING: CPU: 0 PID: 0 at
> > ./arch/x86/include/asm/pgtable.h:357 kernel_physical_mapping_init+0x
> > 256/0x395()
> > [    0.000000] Modules linked in:
> > [    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.4.0-rc5+ #137
> > [    0.000000] Hardware name: LENOVO 17097HU/17097HU, BIOS 7BETD8WW
> > (2.19 ) 03/31/2011
> > [    0.000000]  00000000 00000000 c4e63e90 c42baaf8 00000000 c4e63eac
> > c404066b 00000165
> > [    0.000000]  c4f134da 00000000 00000000 00000000 c4e63ebc c404070f
> > 00000009 00000000
> > [    0.000000]  c4e63f18 c4f134da c4e63f00 00000000 00000000 00000000
> > 00000000 00000000
> > [    0.000000] Call Trace:
> > [    0.000000]  [<c42baaf8>] dump_stack+0x41/0x59
> > [    0.000000]  [<c404066b>] warn_slowpath_common+0x6b/0xa0
> > [    0.000000]  [<c4f134da>] ?
> > kernel_physical_mapping_init+0x256/0x395
> > [    0.000000]  [<c404070f>] warn_slowpath_null+0xf/0x20
> > [    0.000000]  [<c4f134da>] kernel_physical_mapping_init+0x256/0x395
> > [    0.000000]  [<c4a4de21>] init_memory_mapping+0x191/0x300
> > [    0.000000]  [<c4f12d96>] init_mem_mapping+0xe7/0x1f3
> 
> Looks like the ISA range to me:
> 
> init_mem_mapping:
> 
> 	...
> 
>         /* the ISA range is always mapped regardless of memory holes */
>         init_memory_mapping(0, ISA_END_ADDRESS);
> 
> Does that kernel_physical_mapping_init() even pay attention to
> __supported_pte_mask and thus _PAGE_NX? I don't see it.

Mystery solved, and prize goes to the lguest.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1292596

FromBorislav Petkov <bp@alien8.de>
Date2015-12-15 23:20 +0100
Message-ID<qG66S-1Iz-23@gated-at.bofh.it>
In reply to#1292586
On Tue, Dec 15, 2015 at 11:07:09PM +0100, Pavel Machek wrote:
> Mystery solved, and prize goes to the lguest.

But that splat has nowhere lguest in it. Are you saying, you don't see
any more splats if you disable lguest?

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1291910

FromPavel Machek <pavel@ucw.cz>
Date2015-12-15 09:00 +0100
Message-ID<qFSGD-14V-13@gated-at.bofh.it>
In reply to#1291588
On Mon 2015-12-14 13:24:08, Arjan van de Ven wrote:
> 
> >That's weird.  The only API to do that seems to be manually setting
> >kmap_prot to _PAGE_KERNEL_EXEC, and nothing does that.  (Why is
> >kmap_prot a variable on x86 at all?  It has exactly one writer, and
> >that's the code that initializes it in the first place.  Shouldn't we
> >#define kmap_prot _PAGE_KERNEL?
> 
> iirc it changes based on runtime detection of NX capability

Huh. Is it possible that core duo is so old that it has no NX?

processor  : 1
vendor_id  : GenuineIntel
cpu family : 6
model	     : 14
model name   : Genuine Intel(R) CPU           T2400  @ 1.83GHz
stepping     : 8
microcode    : 0x39
...
wp    		 : yes
flags		   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr
pge mca cmov clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx
constant_tsc arch_perfmon bts aperfmperf pni monitor vmx est tm2 xtpr
pdcm dtherm

No, it lists nx in flags. Linus asked me about trying without
CONFIG_EFI. I should have no EFI here, but I'll try it.

I turned off CONFIG_EFI, but CONFIG_UEFI_CPER can't seem to be
disabled easily.

Still:

[    3.269750] WARNING: CPU: 1 PID: 1 at
arch/x86/mm/dump_pagetables.c:225 note_page+0x5ec/0x790()
[    3.271999] x86/mm: Found insecure W+X mapping at address
ffe69000/0xffe69000

pavel@duo:~$ zcat /proc/config.gz  | grep EFI
# CONFIG_EFI_PARTITION is not set
# CONFIG_EFI is not set
CONFIG_DMI_SCAN_MACHINE_NON_EFI_FALLBACK=y
CONFIG_UEFI_CPER=y
pavel@duo:~$

Ok, I managed to turn off even CONFIG_UEFI_CPER after some fight, but
result is the same.

(Hmm... I'll probably regret it, but... I guess config.gz does contain
some information useful for the attacker. How long till some "hardened
distro" chmods it to 600?)

Best regards,

							Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1291914 — [PATCH 1/2] x86_32/mm: Set NX in __supported_pte_mask before enabling paging

FromAndy Lutomirski <luto@kernel.org>
Date2015-12-15 09:10 +0100
Subject[PATCH 1/2] x86_32/mm: Set NX in __supported_pte_mask before enabling paging
Message-ID<qFSQj-1nP-15@gated-at.bofh.it>
In reply to#1291910
There's a short window in which very early mappings can end up with
NX clear because they are created before we've noticed that we have
NX.

It turns out that we detect NX very early, so there's no need to
defer __supported_pte_mask setup.

Signed-off-by: Andy Lutomirski <luto@kernel.org>
---
 arch/x86/kernel/head_32.S | 6 ++++++
 arch/x86/mm/setup_nx.c    | 5 ++---
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S
index 6bc9ae24b6d2..57fc3f8c85fd 100644
--- a/arch/x86/kernel/head_32.S
+++ b/arch/x86/kernel/head_32.S
@@ -389,6 +389,12 @@ default_entry:
 	/* Make changes effective */
 	wrmsr
 
+	/*
+	 * And make sure that all the mappings we set up have NX set from
+	 * the beginning.
+	 */
+	orl $(1 << (_PAGE_BIT_NX - 32)), pa(__supported_pte_mask + 4)
+
 enable_paging:
 
 /*
diff --git a/arch/x86/mm/setup_nx.c b/arch/x86/mm/setup_nx.c
index 90555bf60aa4..5095ecb0719c 100644
--- a/arch/x86/mm/setup_nx.c
+++ b/arch/x86/mm/setup_nx.c
@@ -31,9 +31,8 @@ early_param("noexec", noexec_setup);
 
 void x86_configure_nx(void)
 {
-	if (cpu_has_nx && !disable_nx)
-		__supported_pte_mask |= _PAGE_NX;
-	else
+	/* If disable_nx is set, clear NX on all new mappings going forward. */
+	if (disable_nx)
 		__supported_pte_mask &= ~_PAGE_NX;
 }
 
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1291915 — [PATCH 2/2] x86/mm: Make kmap_prot into a #define

FromAndy Lutomirski <luto@kernel.org>
Date2015-12-15 09:10 +0100
Subject[PATCH 2/2] x86/mm: Make kmap_prot into a #define
Message-ID<qFSQj-1nP-21@gated-at.bofh.it>
In reply to#1291910
The value (once we initialize it) is a foregone conclusion.  Make it
a #define to save a tiny amount of text and data size and to make it
more comprehensible.

Signed-off-by: Andy Lutomirski <luto@kernel.org>
---
 arch/x86/include/asm/fixmap.h | 2 +-
 arch/x86/mm/init_32.c         | 3 ---
 2 files changed, 1 insertion(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/fixmap.h b/arch/x86/include/asm/fixmap.h
index 32c60a02ec80..ce941b7e7900 100644
--- a/arch/x86/include/asm/fixmap.h
+++ b/arch/x86/include/asm/fixmap.h
@@ -142,7 +142,7 @@ extern void reserve_top_address(unsigned long reserve);
 extern int fixmaps_set;
 
 extern pte_t *kmap_pte;
-extern pgprot_t kmap_prot;
+#define kmap_prot PAGE_KERNEL
 extern pte_t *pkmap_page_table;
 
 void __native_set_fixmap(enum fixed_addresses idx, pte_t pte);
diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
index cb4ef3de61f9..a4bb1c7ab65e 100644
--- a/arch/x86/mm/init_32.c
+++ b/arch/x86/mm/init_32.c
@@ -388,7 +388,6 @@ repeat:
 }
 
 pte_t *kmap_pte;
-pgprot_t kmap_prot;
 
 static inline pte_t *kmap_get_fixmap_pte(unsigned long vaddr)
 {
@@ -405,8 +404,6 @@ static void __init kmap_init(void)
 	 */
 	kmap_vstart = __fix_to_virt(FIX_KMAP_BEGIN);
 	kmap_pte = kmap_get_fixmap_pte(kmap_vstart);
-
-	kmap_prot = PAGE_KERNEL;
 }
 
 #ifdef CONFIG_HIGHMEM
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1291917 — [PATCH 0/2] x86/mm: A _PAGE_NX fixlet and a kmap cleanup

FromAndy Lutomirski <luto@kernel.org>
Date2015-12-15 09:10 +0100
Subject[PATCH 0/2] x86/mm: A _PAGE_NX fixlet and a kmap cleanup
Message-ID<qFSQj-1nP-17@gated-at.bofh.it>
In reply to#1291910
The fixlet might help with some WX warnings.  The kmap cleanup is
just a cleanup.

This is very lightly tested.

Andy Lutomirski (2):
  x86_32/mm: Set NX in __supported_pte_mask before enabling paging
  x86/mm: Make kmap_prot into a #define

 arch/x86/include/asm/fixmap.h | 2 +-
 arch/x86/kernel/head_32.S     | 6 ++++++
 arch/x86/mm/init_32.c         | 3 ---
 arch/x86/mm/setup_nx.c        | 5 ++---
 4 files changed, 9 insertions(+), 7 deletions(-)

-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1292185

FromArjan van de Ven <arjan@linux.intel.com>
Date2015-12-15 14:40 +0100
Message-ID<qFXZE-4IZ-13@gated-at.bofh.it>
In reply to#1291910
On 12/14/2015 11:56 PM, Pavel Machek wrote:
> On Mon 2015-12-14 13:24:08, Arjan van de Ven wrote:
>>
>>> That's weird.  The only API to do that seems to be manually setting
>>> kmap_prot to _PAGE_KERNEL_EXEC, and nothing does that.  (Why is
>>> kmap_prot a variable on x86 at all?  It has exactly one writer, and
>>> that's the code that initializes it in the first place.  Shouldn't we
>>> #define kmap_prot _PAGE_KERNEL?
>>
>> iirc it changes based on runtime detection of NX capability
>
> Huh. Is it possible that core duo is so old that it has no NX?

really stupid question I guess, but is PAE on ?
(64 bit pagetables are required for NX)


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1292209

FromPavel Machek <pavel@ucw.cz>
Date2015-12-15 15:10 +0100
Message-ID<qFYsF-58o-1@gated-at.bofh.it>
In reply to#1292185

[Multipart message — attachments visible in raw view] — view raw

On Tue 2015-12-15 05:26:00, Arjan van de Ven wrote:
> On 12/14/2015 11:56 PM, Pavel Machek wrote:
> >On Mon 2015-12-14 13:24:08, Arjan van de Ven wrote:
> >>
> >>>That's weird.  The only API to do that seems to be manually setting
> >>>kmap_prot to _PAGE_KERNEL_EXEC, and nothing does that.  (Why is
> >>>kmap_prot a variable on x86 at all?  It has exactly one writer, and
> >>>that's the code that initializes it in the first place.  Shouldn't we
> >>>#define kmap_prot _PAGE_KERNEL?
> >>
> >>iirc it changes based on runtime detection of NX capability
> >
> >Huh. Is it possible that core duo is so old that it has no NX?
> 
> really stupid question I guess, but is PAE on ?
> (64 bit pagetables are required for NX)
>

CONFIG_X86_PAE=y

pavel@duo:/data/l/linux$ cat /proc/cpuinfo  | grep pae
flags			     : fpu vme de pse tsc msr pae mce cx8 apic
sep mtrr pge mca cmov clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
nx constant_tsc arch_perfmon bts aperfmperf pni monitor vmx est tm2
xtpr pdcm dtherm

But it still says:

address sizes	: 32 bits physical, 32 bits virtual

I thought pae would be 36bit virtual?

I'm attaching /proc/config.gz..
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [prev] | [next] | [standalone]

#1292326

From"H. Peter Anvin" <hpa@zytor.com>
Date2015-12-15 17:30 +0100
Message-ID<qG0E9-6Cw-1@gated-at.bofh.it>
In reply to#1292209
On 12/15/15 06:08, Pavel Machek wrote:
> 
> But it still says:
> 
> address sizes	: 32 bits physical, 32 bits virtual
> 
> I thought pae would be 36bit virtual?
> 

It should be unless the CPU reports otherwise, which your CPU probably
does (a CPUID dump might be useful.)

	-hpa


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1292411

FromPavel Machek <pavel@ucw.cz>
Date2015-12-15 18:50 +0100
Message-ID<qG1TA-7mv-25@gated-at.bofh.it>
In reply to#1292326

[Multipart message — attachments visible in raw view] — view raw

On Tue 2015-12-15 08:28:12, H. Peter Anvin wrote:
> On 12/15/15 06:08, Pavel Machek wrote:
> > 
> > But it still says:
> > 
> > address sizes	: 32 bits physical, 32 bits virtual
> > 
> > I thought pae would be 36bit virtual?
> > 
> 
> It should be unless the CPU reports otherwise, which your CPU probably
> does (a CPUID dump might be useful.)

Ok, here you go :-).
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [prev] | [next] | [standalone]

#1291154

FromPavel Machek <pavel@ucw.cz>
Date2015-12-14 13:40 +0100
Message-ID<qFAA3-69m-23@gated-at.bofh.it>
In reply to#1290909
On Mon 2015-12-14 09:04:03, Pavel Machek wrote:
> Hi!
> 
> > Kernel complains:
> 
> And now, we are at -rc5, and kernel still complains...
> 
> ...with a back trace, which is clearly completely useless, and just
> there to make it scary and make people report.
> 
> Problem is... noone cares for the reports. (-rc0 version below).
> 
> Can we get rid of that WARN_ON? If you do care about reports, please
> add email address those can be reported to. If you don't... just drop
> it.
> 
> Hardware is thinkpad x60.

> [    3.285993] x86/mm: Found insecure W+X mapping at address
> ffe69000/0xffe69000


---[ Persisent kmap() Area ]---
0xffc00000-0xffd28000        1184K                               pte
0xffd28000-0xffddd000         724K     RW                 GLB NX pte
0xffddd000-0xffe69000         560K                               pte
0xffe69000-0xffe6e000          20K     RW                 GLB x  pte
0xffe6e000-0xffe6f000           4K                               pte
---[ Fixmap Area ]---

Any other info that would be useful?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web