linux-kernel - Re: [PATCH 5/7] Use %gs for per-cpu sections in kernel

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]

Date:	Mon, 25 Sep 2006 12:51:16 +1000
From:	Rusty Russell <rusty@...tcorp.com.au>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
Cc:	Andi Kleen <ak@....de>,
	lkml - Kernel Mailing List <linux-kernel@...r.kernel.org>,
	virtualization <virtualization@...ts.osdl.org>
Subject: Re: [PATCH 5/7] Use %gs for per-cpu sections in kernel

On Sun, 2006-09-24 at 18:36 -0700, Jeremy Fitzhardinge wrote:
> Rusty Russell wrote:
> > 	You're thinking of it in a convoluted way, by converting to offsets
> > from the per-cpu section, then converting it back.  How about this
> > explanation: the local cpu's versions are offset from where the compiler
> > thinks they are by __per_cpu_offset[cpu].  We set the segment base to
> > __per_cpu_offset[cpu], so "%gs:per_cpu__foo" gets us straight to the
> > local cpu version.  __per_cpu_offset[cpu] is always positive (kernel
> > image sits at bottom of kernel address space).
> >   
> 
> We're talking kernel virtual addresses, so the physical load address 
> doesn't matter, of course.
> 
> So, take this kernel I have here as an explicit example:
> 
> $ nm -n vmlinux
> [...]
> c0431100 A __per_cpu_start
> [...]
> c0433800 D per_cpu__cpu_gdt_descr
> c0433880 D per_cpu__cpu_tlbstate
> 
> 
> And say that this CPU has its percpu data allocated at 0xc100000.

That can't happen, since 0xc100000 is not in the kernel address space.
0xc1000000 is though, perhaps that's what you meant?

> So, in this case the %gs base will be loaded with 0xc100000-0xc0431100 = 
> 0x4bccef00

A negative offset, exactly, which can't happen, as I said.

Hope that clarifies?

Confused,
Rusty.
-- 
Help! Save Australia from the worst of the DMCA: http://linux.org.au/law

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