linux-kernel - Re: [RFC] Design for flag bit outputs from asms

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:	Tue, 5 May 2015 11:01:05 +0200
From:	Gabriel Paubert <paubert@...m.es>
To:	Richard Henderson <rth@...hat.com>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Vladimir Makarov <vmakarov@...hat.com>,
	Jakub Jelinek <jakub@...hat.com>,
	Ingo Molnar <mingo@...nel.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Borislav Petkov <bp@...en8.de>,
	"gcc@....gnu.org" <gcc@....gnu.org>
Subject: Re: [RFC] Design for flag bit outputs from asms

On Mon, May 04, 2015 at 12:33:38PM -0700, Richard Henderson wrote:
[snipped]
> (3) Note that ppc is both easier and more complicated.
> 
>   There we have 8 4-bit registers, although most of the integer
>   non-comparisons only write to CR0.  And the vector non-comparisons
>   only write to CR1, though of course that's of less interest in the
>   context of kernel code.

Actually vector (Altivec) write to CR6. Standard FPU optionally write to
CR1, but the written value does not exactly depend on the result of the last
instruction; it is an instead an accrued exception status.

> 
>   For the purposes of cr0, the same scheme could certainly work, although
>   the hook would not insert a hard register use, but rather a pseudo to
>   be allocated to cr0 (constaint "x").

Yes, but we might also want to leave the choice of a cr register to the compiler.

> 
>   That said, it's my understanding that "dot insns", setting cr0 are
>   expensive in current processor generations.  

Not that much if I understand properly power7.md and power8.md: 
no (P7) or one (P8) additional clock for common instructions 
(add/sub and logical), but nothing else, so they are likely a win. 

Shift/rotate/sign extensions seem to have more decoding restrictions: 
the recording ("dot") forms are "cracked" and use 2 integer units.

>   There's also a lot less
>   of the x86-style "operate and set a flag based on something useful".
> 

But there is at least an important one, which I occasionally wished I had: 
the conditional stores. 

The overflow bit might also be useful, not really 
for the kernel, but for applications (and mfxer is slow).

    Regards,
    Gabriel
--
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/