| 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
| ||
|
Date: Wed, 22 Feb 2012 15:34:31 +0530
From: Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
To: Ingo Molnar <mingo@...e.hu>
Cc: Peter Zijlstra <peterz@...radead.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Oleg Nesterov <oleg@...hat.com>,
LKML <linux-kernel@...r.kernel.org>,
Christoph Hellwig <hch@...radead.org>,
Steven Rostedt <rostedt@...dmis.org>,
Thomas Gleixner <tglx@...utronix.de>,
Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
Anton Arapov <anton@...hat.com>,
Ananth N Mavinakayanahalli <ananth@...ibm.com>,
Jim Keniston <jkenisto@...ux.vnet.ibm.com>,
Jiri Olsa <jolsa@...hat.com>, Josh Stone <jistone@...hat.com>
Subject: Re: [PATCH 1/3] uprobes/core: Make instruction tables volatile.
> * Srikar Dronamraju <srikar@...ux.vnet.ibm.com> wrote:
>
> > From: Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
> >
> > Some versions of gcc spits a warning about the asm operand for test_bit and
> > also causes the first long of the instruction table to be output.
> >
> > Fix is similar to 7115e3fc on arch/x86/kernel/kprobes.c
> >
> > Signed-off-by: Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
> > ---
> > arch/x86/kernel/uprobes.c | 61 ++++++++++++++++++++++++---------------------
> > 1 files changed, 32 insertions(+), 29 deletions(-)
> >
> > diff --git a/arch/x86/kernel/uprobes.c b/arch/x86/kernel/uprobes.c
> > index cf2a184..13d616d 100644
> > --- a/arch/x86/kernel/uprobes.c
> > +++ b/arch/x86/kernel/uprobes.c
> > @@ -53,34 +53,12 @@
> > (bc##UL << 0xc)|(bd##UL << 0xd)|(be##UL << 0xe)|(bf##UL << 0xf)) \
> > << (row % 32))
> >
> > -#ifdef CONFIG_X86_64
> > -static u32 good_insns_64[256 / 32] = {
> > - /* 0 1 2 3 4 5 6 7 8 9 a b c d e f */
> > - /* ---------------------------------------------- */
> > - W(0x00, 1, 1, 1, 1, 1, 1, 0, 0, 1, 1, 1, 1, 1, 1, 0, 0) | /* 00 */
> > - W(0x10, 1, 1, 1, 1, 1, 1, 0, 0, 1, 1, 1, 1, 1, 1, 0, 0) , /* 10 */
> > - W(0x20, 1, 1, 1, 1, 1, 1, 0, 0, 1, 1, 1, 1, 1, 1, 0, 0) | /* 20 */
> > - W(0x30, 1, 1, 1, 1, 1, 1, 0, 0, 1, 1, 1, 1, 1, 1, 0, 0) , /* 30 */
> > - W(0x40, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0) | /* 40 */
> > - W(0x50, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1) , /* 50 */
> > - W(0x60, 0, 0, 0, 1, 1, 1, 0, 0, 1, 1, 1, 1, 0, 0, 0, 0) | /* 60 */
> > - W(0x70, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1) , /* 70 */
> > - W(0x80, 1, 1, 0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1) | /* 80 */
> > - W(0x90, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1) , /* 90 */
> > - W(0xa0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1) | /* a0 */
> > - W(0xb0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1) , /* b0 */
> > - W(0xc0, 1, 1, 1, 1, 0, 0, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0) | /* c0 */
> > - W(0xd0, 1, 1, 1, 1, 0, 0, 0, 1, 1, 1, 1, 1, 1, 1, 1, 1) , /* d0 */
> > - W(0xe0, 1, 1, 1, 1, 0, 0, 0, 0, 1, 1, 1, 1, 0, 0, 0, 0) | /* e0 */
> > - W(0xf0, 0, 0, 1, 1, 0, 1, 1, 1, 1, 1, 0, 0, 1, 1, 1, 1) /* f0 */
> > - /* ---------------------------------------------- */
> > - /* 0 1 2 3 4 5 6 7 8 9 a b c d e f */
> > -};
> > -#endif
> > -
> > -/* Good-instruction tables for 32-bit apps */
> > -
> > -static u32 good_insns_32[256 / 32] = {
> > +/*
> > + * Good-instruction tables for 32-bit apps. This is non-const and volatile
> > + * to keep gcc from statically optimizing it out, as variable_test_bit makes
> > + * some versions of gcc to think only *(unsigned long*) is used.
> > + */
> > +static volatile u32 good_insns_32[256 / 32] = {
> > /* 0 1 2 3 4 5 6 7 8 9 a b c d e f */
> > /* ---------------------------------------------- */
> > W(0x00, 1, 1, 1, 1, 1, 1, 1, 0, 1, 1, 1, 1, 1, 1, 1, 0) | /* 00 */
> > @@ -104,7 +82,7 @@ static u32 good_insns_32[256 / 32] = {
> > };
> >
> > /* Using this for both 64-bit and 32-bit apps */
> > -static u32 good_2byte_insns[256 / 32] = {
> > +static volatile u32 good_2byte_insns[256 / 32] = {
> > /* 0 1 2 3 4 5 6 7 8 9 a b c d e f */
> > /* ---------------------------------------------- */
> > W(0x00, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1) | /* 00 */
> > @@ -127,6 +105,31 @@ static u32 good_2byte_insns[256 / 32] = {
> > /* 0 1 2 3 4 5 6 7 8 9 a b c d e f */
> > };
> >
> > +#ifdef CONFIG_X86_64
> > +/* Good-instruction tables for 64-bit apps */
> > +static volatile u32 good_insns_64[256 / 32] = {
> > + /* 0 1 2 3 4 5 6 7 8 9 a b c d e f */
> > + /* ---------------------------------------------- */
> > + W(0x00, 1, 1, 1, 1, 1, 1, 0, 0, 1, 1, 1, 1, 1, 1, 0, 0) | /* 00 */
> > + W(0x10, 1, 1, 1, 1, 1, 1, 0, 0, 1, 1, 1, 1, 1, 1, 0, 0) , /* 10 */
> > + W(0x20, 1, 1, 1, 1, 1, 1, 0, 0, 1, 1, 1, 1, 1, 1, 0, 0) | /* 20 */
> > + W(0x30, 1, 1, 1, 1, 1, 1, 0, 0, 1, 1, 1, 1, 1, 1, 0, 0) , /* 30 */
> > + W(0x40, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0) | /* 40 */
> > + W(0x50, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1) , /* 50 */
> > + W(0x60, 0, 0, 0, 1, 1, 1, 0, 0, 1, 1, 1, 1, 0, 0, 0, 0) | /* 60 */
> > + W(0x70, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1) , /* 70 */
> > + W(0x80, 1, 1, 0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1) | /* 80 */
> > + W(0x90, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1) , /* 90 */
> > + W(0xa0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1) | /* a0 */
> > + W(0xb0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1) , /* b0 */
> > + W(0xc0, 1, 1, 1, 1, 0, 0, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0) | /* c0 */
> > + W(0xd0, 1, 1, 1, 1, 0, 0, 0, 1, 1, 1, 1, 1, 1, 1, 1, 1) , /* d0 */
> > + W(0xe0, 1, 1, 1, 1, 0, 0, 0, 0, 1, 1, 1, 1, 0, 0, 0, 0) | /* e0 */
> > + W(0xf0, 0, 0, 1, 1, 0, 1, 1, 1, 1, 1, 0, 0, 1, 1, 1, 1) /* f0 */
> > + /* ---------------------------------------------- */
> > + /* 0 1 2 3 4 5 6 7 8 9 a b c d e f */
> > +};
> > +#endif
>
> Hm, why was the table moved around? This makes it hard to see
> whether it's just a single volatile that is added, or something
> more.
>
Without the table moving, the volatile was first used under #ifdef
CONFIG_X86_64. I was wondering if I add a comment in #ifdef people
looking at it might assume that its a problem only on x86_64 only.
So I moved the CONFIG_X86_64 specific table down and added the comment
for volatile at the first instance its used.
--
Thanks and Regards
Srikar
--
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/
Powered by blists - more mailing lists