linux-kernel - ASM flags in general

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:	Mon, 27 Jul 2015 12:04:56 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Uros Bizjak <uros_bizjak1@....net>, linux-kernel@...r.kernel.org
CC:	x86@...nel.org, Uros Bizjak <ubizjak@...il.com>,
	Ingo Molnar <mingo@...nel.org>
Subject: ASM flags in general

On 07/27/2015 10:48 AM, Uros Bizjak wrote:
> From: Uros Bizjak <ubizjak@...il.com>
> 
> This patch introduces GCC ASM flags to bitops.
> 
> The new functionality depends on __GCC_ASM_FLAG_OUTPUTS__ preprocessor
> symbol, which is automatically set by GCC version 6 or later when
> ASM flags feature is supported.
> 
> The improvement can be illustrated with following code snipped.
> Instead of:
> 

This might be a good time to bring up this proposal I made in private
recently in public:

In the next version (6.0) of gcc, there will be support for emitting
flags as outputs from inline assembly.  We obviously want to use this,
but I think it would be better to not have to have two copies for each
bit of assembly, for old and new gcc.

I have been thinking about it, and have checked with how gcc actually
handles "bool" as outputs.  It turns out that using "bool" in asm output
is perfectly well defined on x86, and is defined as a byte output which
is required to be 0 or 1.  This is consistent with how the "set"
instruction operates.

As such, I would like to propose the following:

1. We change the actual type of the output variable for these asm
statements to bool.
2. Define the following macros:

#ifdef __GCC_ASM_FLAGS_OUTPUT__

#define CC_SET(c)
#define CC_OUT(c) "=@cc" #c

#else

#define CC_SET(c) "\n\tset" #c " %[cc_" #c "]"
#define CC_OUT(c) [cc_ ## c] "=qm" (v)

#endif

A sample use would be something like this:

unsigned long x, y, z;
bool carry;

asm("add %3,%0"
    CC_SET(c)
    : "=r" (z), CC_OUT(c) (carry)
    : "0" (x), "rm" (y));

I wonder if using "set" would be a performance regression over "sbb" for
the existing bitops, in which case it would slot quite nicely into this
scheme.

I have been working in the background on a patchset for this, but as my
life is incredibly crazy at the moment progress has been slow.  However,
this is the way I'd like to see a patchset, with appropriate tests for
regression in between:

1. A patchset that uses "bool" for this type of boolean outputs.
2. A patchset to change "sbb" to "set" where appropriate.
3. Introducing the above macros.
4. Using the macros where it makes sense.

Linus also commented, quite correctly:

"That said, I think we should look at actually changing some of the
functions we use.

For example, I think cmpxchg really should use ZF once we have flag
outputs rather than comparing old and new.  That changes the whole way
we use it.

There may be other places where we might want to make those kind of
bigger changes."

Those are the kind of places where having per-site conditional code
makes sense.

	-hpa

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