linux-kernel - Re: [PATCH 2/6] x86: bug: prevent gcc distortions

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: <B7EA94A4-5AFD-4ED6-BD90-9A5E417FCECB@vmware.com>
Date:   Fri, 18 May 2018 14:22:41 +0000
From:   Nadav Amit <namit@...are.com>
To:     Peter Zijlstra <peterz@...radead.org>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "x86@...nel.org" <x86@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        Josh Poimboeuf <jpoimboe@...hat.com>
Subject: Re: [PATCH 2/6] x86: bug: prevent gcc distortions

Peter Zijlstra <peterz@...radead.org> wrote:

> On Thu, May 17, 2018 at 09:13:58AM -0700, Nadav Amit wrote:
>> +asm(".macro __BUG_FLAGS ins:req file:req line:req flags:req size:req\n"
>> +    "1:\t \\ins\n\t"
>> +    ".pushsection __bug_table,\"aw\"\n"
>> +    "2:\t "__BUG_REL(1b)		"\t# bug_entry::bug_addr\n\t"
>> +    __BUG_REL(\\file)			"\t# bug_entry::file\n\t"
>> +    ".word \\line"			"\t# bug_entry::line\n\t"
>> +    ".word \\flags"			"\t# bug_entry::flags\n\t"
>> +    ".org 2b+\\size\n\t"
>> +    ".popsection\n\t"
>> +    ".endm");
>> +
>> +#define _BUG_FLAGS(ins, flags)                                          \
>> do {									\
>> +	asm volatile("__BUG_FLAGS \"" ins "\" %c0 %c1 %c2 %c3"		\
>> +		     : : "i" (__FILE__), "i" (__LINE__),                \
>> +			 "i" (flags),                                   \
>> 			 "i" (sizeof(struct bug_entry)));		\
>> } while (0)
> 
> This is an awesome hack, but is there really nothing we can do to make
> it more readable? Esp, that global asm doing the macro definition is a
> pain to read.
> 
> Also, can we pretty please used named operands in 'new' code?

It is hard to make the code readable in C, readable in the generated asm,
and to follow the coding style imposed by checkpatch (e.g., no space between
the newline and the asm argument before it).

I considered wrapping the asm macro in a C macro, but AFAIK C macros cannot
emit backslashes.

I thought of suggesting to change “ins” into a vararg and removing the
escaped double-quotes in the C macro, but you ask to use named operands.

So I am out of ideas. Do you have anything else in mind?

Thanks,
Nadav