linux-kernel - Re: current_thread_info() not respecting program order with gcc 4.8.x

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>] [day] [month] [year] [list]

Message-ID: <CAHNPk65U3gaNGs74VGpiOJCaR_n0mdj53LLe=M-6cVnoKRHK5w@mail.gmail.com>
Date:	Wed, 20 Nov 2013 17:52:52 -0800
From:	Luis Lozano <llozano@...omium.org>
To:	linux-kernel@...r.kernel.org,
	Bhaskar Janakiraman <bjanakiraman@...omium.org>,
	Han Shen <shenhan@...omium.org>
Subject: Re: current_thread_info() not respecting program order with gcc 4.8.x

I have been monitoring this thread and trying to understand how could
this happen.

I noticed that the definition for ARM of current_thread_info looks like this:

/*
 * how to get the thread information struct from C
 */
static inline struct thread_info *current_thread_info(void) __attribute_const__;

static inline struct thread_info *current_thread_info(void)
{
register unsigned long sp asm ("sp");
return (struct thread_info *)(sp & ~(THREAD_SIZE - 1));
}

Notice this has the __attribute_const__ marking which corresponds to
the __const__ gcc attribute described in:

http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html

This attribute marking seems wrong to me. This function depends on
global state (depends on SP).
This seems to go against the definition of what a "const" function is
(according to GCC)
I noticed this attribute marking is not set for the x86 definition.

Could this be confusing the compiler and causing the problem?
Can you try this?

It would be nice if you could point to the exact location in the code
where one could see the reordering happening. I tried to reproduce
with a small test case and I couldn't. Do you have a small test case?

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