linux-kernel - Re: [PATCHSET linux-2.6-x86:tip] x86: make percpu offsets zero-based on SMP

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:	Tue, 13 Jan 2009 09:26:38 -0500
From:	"Brian Gerst" <brgerst@...il.com>
To:	"Tejun Heo" <tj@...nel.org>
Cc:	ebiederm@...ssion.com, cl@...ux-foundation.org,
	rusty@...tcorp.com.au, mingo@...e.hu, travis@....com,
	linux-kernel@...r.kernel.org, hpa@...or.com,
	akpm@...ux-foundation.org, steiner@....com, hugh@...itas.com
Subject: Re: [PATCHSET linux-2.6-x86:tip] x86: make percpu offsets zero-based on SMP

On Tue, Jan 13, 2009 at 9:05 AM, Tejun Heo <tj@...nel.org> wrote:
> Hello, Brian.
>
> Brian Gerst wrote:
>> I've been working on a patchset that does something similar, but
>> eliminating the PDA completely.  The start is already in tip/x86/pda.
>> The plan is to change all PDA variables to be normal per-cpu
>> variables, merging with 32-bit where possible.
>
> I think the two changes aren't exclusive at all.  The order of things
> could be different but in the end, yeah, zero-based percpu symbols w/
> mostly empty pda is the goal.
>
>> Once the PDA is empty, I'll base %gs at the start of the per-cpu
>> area.  I've been working out the bugs with the last patch
>> (zero-basing the percpu area) before submitting, but I probably
>> won't have the time until this weekend to polish it off.  I could
>> submit all but the last patch if you'd like.
>
> Any chance you can rebase those patches on top of mine?  If you don't
> have time, just send them to me, I'll try to integrate them this week.

Are your patches available via git by chance?

>> They are functionally correct, but because the per-cpu area isn't
>> zero-based yet the generated code is a bit bloated due to having to
>> calculate the delta for the %gs offset.
>
> BTW, what did you do about the dreaded stack_canary?

I put the irqstack at the start of the per-cpu area and overlaid the
canary on the bottom 48 bytes of the 16k stack.

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