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: <f7a36237052f4c09ad101431653038a5@AcuMS.aculab.com>
Date:   Fri, 19 Mar 2021 17:18:14 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Peter Zijlstra' <peterz@...radead.org>,
        "x86@...nel.org" <x86@...nel.org>,
        "jpoimboe@...hat.com" <jpoimboe@...hat.com>,
        "jgross@...e.com" <jgross@...e.com>,
        "mbenes@...e.com" <mbenes@...e.com>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v2 03/14] x86/retpoline: Simplify retpolines

From: Peter Zijlstra
> Sent: 18 March 2021 17:11
> 
> Due to commit c9c324dc22aa ("objtool: Support stack layout changes
> in alternatives"), it is possible to simplify the retpolines.
> 
...
> Notice that since the longest alternative sequence is now:
> 
>    0:   e8 07 00 00 00          callq  c <.altinstr_replacement+0xc>
>    5:   f3 90                   pause
>    7:   0f ae e8                lfence
>    a:   eb f9                   jmp    5 <.altinstr_replacement+0x5>
>    c:   48 89 04 24             mov    %rax,(%rsp)
>   10:   c3                      retq
> 
> 17 bytes, we have 15 bytes NOP at the end of our 32 byte slot. (IOW,
> if we can shrink the retpoline by 1 byte we can pack it more dense)

I'm intrigued about the lfence after the pause.
Clearly this is for very warped cpu behaviour.
To get to the pause you have to be speculating past an
unconditional call.

To get to the lfence you have to (mostly) have ignored the pause.
Which is commented:
	_mm_pause(); /* Abort speculation */
in a couple of examples in 248966-033.

I wonder what effect replacing the lfence with hlt would have?
It would certainly save 2 bytes and allow the entire retpoline
be put into a single 16byte code fetch block.

248966-033 also contains a note that the instruction(s) after
an indirect jump may get executed.
It suggests adding a pause (or illegal instruction) to stop
anything odd happening (they knew it could be horrid in June 2016.
But then go on to say the adding pause may be a performance issue.
(Presumably because if it is speculatively executed it takes ages.)

I do remember something from even longer ago about trying to never
speculate any of the trig opcodes - because at last some cpu couldn't
abort the instruction.

This may also mean that a big pile of 0x90 nops after the jmp (%eax)
is actually better than 2 or 3 'big' nops.
Of course, if you execute the nops you always want the big ones.

	David

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ