linux-kernel - Re: [crash, bisected] Re: [PATCH 3/4] x86

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <485BF8F5.6010802@goop.org>
Date:	Fri, 20 Jun 2008 11:37:41 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Christoph Lameter <clameter@....com>
CC:	Mike Travis <travis@....com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re: [crash, bisected] Re: [PATCH 3/4] x86_64: Fold pda into per cpu
 area

Christoph Lameter wrote:
> On Fri, 20 Jun 2008, Jeremy Fitzhardinge wrote:
>
>   
>> So it seems the problem is that the pre-initialized gdt_page is being lost and
>> replaced with zero.  Linker script bug?
>>     
>
> Is the pre initialized gdt page in the per cpu area? Does not look like 
> it. 

Yes, it should be.  arch/x86/kernel/setup_64.c:

DEFINE_PER_CPU(struct gdt_page, gdt_page) = { .gdt = {
	[GDT_ENTRY_KERNEL32_CS] = { { { 0x0000ffff, 0x00cf9b00 } } },
	[GDT_ENTRY_KERNEL_CS] = { { { 0x0000ffff, 0x00af9b00 } } },
	[GDT_ENTRY_KERNEL_DS] = { { { 0x0000ffff, 0x00cf9300 } } },
	[GDT_ENTRY_DEFAULT_USER32_CS] = { { { 0x0000ffff, 0x00cffb00 } } },
	[GDT_ENTRY_DEFAULT_USER_DS] = { { { 0x0000ffff, 0x00cff300 } } },
	[GDT_ENTRY_DEFAULT_USER_CS] = { { { 0x0000ffff, 0x00affb00 } } },
} };


> The loader setup for the percpu section changes with zero basing. 
> Maybe that has bad side effects

How does it work?  The symbols in the percpu segment are 0-based, but 
where does the data for the sections which correspond to that segment go?

The vmlinux looks like it has the gdt_page data in it.  
per_cpu__gdt_page is 0x5000, and offset 0x5000 in .data.percpu has the 
right stuff:

 5000 00000000 00000000 ffff0000 009bcf00  ................
 5010 ffff0000 009baf00 ffff0000 0093cf00  ................
 5020 ffff0000 00fbcf00 ffff0000 00f3cf00  ................
 5030 ffff0000 00fbaf00 00000000 00000000  ................
 5040 00000000 00000000 00000000 00000000  ................
 5050 00000000 00000000 00000000 00000000  ................
 5060 00000000 00000000 00000000 00000000  ................


So the question is what kernel virtual address is it being loaded to?  
__per_cpu_load is ffffffff808d1000, so ffffffff808d6000 is what you'd 
expect...

Hm, but what happens when this gets converted to bzImage?  Hm, looks OK, 
I think.

BTW, I think __per_cpu_load will cause trouble if you make a relocatable 
kernel, being an absolute symbol.  But I have relocation off at the moment.

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