linux-kernel - RE: [PATCH] Kconfig: Explicitly disable asm goto w/ outputs on gcc-11 (and earlier)

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <9ba89b70e48143a69f76f6e0f276f149@AcuMS.aculab.com>
Date: Sat, 10 Feb 2024 17:21:45 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Sean Christopherson' <seanjc@...gle.com>, Linus Torvalds
	<torvalds@...ux-foundation.org>
CC: Nick Desaulniers <ndesaulniers@...gle.com>, Uros Bizjak
	<ubizjak@...il.com>, Jakub Jelinek <jakub@...hat.com>, "Andrew Pinski (QUIC)"
	<quic_apinski@...cinc.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, Masahiro Yamada <masahiroy@...nel.org>,
	"Peter Zijlstra" <peterz@...radead.org>, "kvm@...r.kernel.org"
	<kvm@...r.kernel.org>
Subject: RE: [PATCH] Kconfig: Explicitly disable asm goto w/ outputs on gcc-11
 (and earlier)

From: Sean Christopherson
> Sent: 09 February 2024 21:47
> 
> On Fri, Feb 09, 2024, Linus Torvalds wrote:
> > Sean? Does this work for the case you noticed?
> 
> Yep.  You can quite literally see the effect of the asm("").  A "good" sequence
> directly propagates the result from the VMREAD's destination register to its
> final destination
> 
>   <+1756>:  mov    $0x280e,%r13d
>   <+1762>:  vmread %r13,%r13
>   <+1766>:  jbe    0x209fa <sync_vmcs02_to_vmcs12+1834>
>   <+1768>:  mov    %r13,0xe8(%rbx)
> 
> whereas the "bad" sequence bounces through a different register.
> 
>   <+1780>:  mov    $0x2810,%eax
>   <+1785>:  vmread %rax,%rax
>   <+1788>:  jbe    0x209e4 <sync_vmcs02_to_vmcs12+1812>
>   <+1790>:  mov    %rax,%r12
>   <+1793>:  mov    %r12,0xf0(%rbx)
..

Annoying, but I doubt it is measurable in this case.
Firstly it could easily be a 'free' register rename.
Secondly isn't vmread horribly slow anyway, so an extra
clock or two won't matter?

The double register move that OPTIMER_HIDE_VAR() often
generates is another matter entirely :-)
In the old days the peephole optimiser would (should?)
have removed most of these.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)