linux-kernel - Re: [RFC 00/15] x86_64: Optimize percpu accesses

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: <48753207.7070308@goop.org>
Date:	Wed, 09 Jul 2008 14:47:51 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Mike Travis <travis@....com>
CC:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Christoph Lameter <cl@...ux-foundation.org>,
	Jack Steiner <steiner@....com>, linux-kernel@...r.kernel.org
Subject: Re: [RFC 00/15] x86_64: Optimize percpu accesses

Mike Travis wrote:
> Eric W. Biederman wrote:
>   
>> I just took a quick look at how stack_protector works on x86_64.  Unless there is
>> some deep kernel magic that changes the segment register to %gs from the ABI specified
>> %fs CC_STACKPROTECTOR is totally broken on x86_64.  We access our pda through %gs.
>>
>> Further -fstack-protector-all only seems to detect against buffer overflows and
>> thus corruption of the stack.  Not stack overflows.  So it doesn't appear especially
>> useful.
>>
>> So we don't we kill the broken CONFIG_CC_STACKPROTECTOR.  Stop trying to figure out
>> how to use a zero based percpu area.
>>
>> That should allow us to make the current pda a per cpu variable, and use %gs with
>> a large offset to access the per cpu area.  And since it is only the per cpu accesses
>> and the pda accesses that will change we should not need to fight toolchain issues
>> and other weirdness.  The linked binary can remain the same.
>>
>> Eric
>>     
>
> Hi Eric,
>
> There is one pda op that I was not able to remove.  Most likely it can be recoded
> but it was a bit over my expertise.  Most likely the "pda_offset(field)" can be
> replaced with "per_cpu_var(field)" [per_cpu__##field], but for "_proxy_pda.field"
> I wasn't sure about.
>
> include/asm-x86/pda.h:
>
> /*
>  * This is not atomic against other CPUs -- CPU preemption needs to be off
>  * NOTE: This relies on the fact that the cpu_pda is the *first* field in
>  *       the per cpu area.  Move it and you'll need to change this.
>  */
> #define test_and_clear_bit_pda(bit, field)                              \
> ({                                                                      \
>         int old__;                                                      \
>         asm volatile("btr %2,%%gs:%c3\n\tsbbl %0,%0"                    \
>                      : "=r" (old__), "+m" (_proxy_pda.field)            \
>                      : "dIr" (bit), "i" (pda_offset(field)) : "memory");\
>   
        asm volatile("btr %2,%%gs:%1\n\tsbbl %0,%0"                    \
                     : "=r" (old__), "+m" (per_cpu_var(var))            \
                     : "dIr" (bit) : "memory");\


but it barely seems worthwhile if we really can't use test_and_clear_bit.

    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/