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: <aca58942b1424f83a0673318dc42c1f8@AcuMS.aculab.com>
Date:   Sat, 10 Feb 2018 15:41:06 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Linus Torvalds' <torvalds@...ux-foundation.org>,
        Joerg Roedel <jroedel@...e.de>
CC:     Joerg Roedel <joro@...tes.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        "Ingo Molnar" <mingo@...nel.org>,
        "H . Peter Anvin" <hpa@...or.com>,
        "the arch/x86 maintainers" <x86@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-mm <linux-mm@...ck.org>,
        "Andy Lutomirski" <luto@...nel.org>,
        Dave Hansen <dave.hansen@...el.com>,
        "Josh Poimboeuf" <jpoimboe@...hat.com>,
        Juergen Gross <jgross@...e.com>,
        "Peter Zijlstra" <peterz@...radead.org>,
        Borislav Petkov <bp@...en8.de>, Jiri Kosina <jkosina@...e.cz>,
        Boris Ostrovsky <boris.ostrovsky@...cle.com>,
        Brian Gerst <brgerst@...il.com>,
        Denys Vlasenko <dvlasenk@...hat.com>,
        Eduardo Valentin <eduval@...zon.com>,
        Greg KH <gregkh@...uxfoundation.org>,
        Will Deacon <will.deacon@....com>,
        "Liguori, Anthony" <aliguori@...zon.com>,
        Daniel Gruss <daniel.gruss@...k.tugraz.at>,
        Hugh Dickins <hughd@...gle.com>,
        Kees Cook <keescook@...gle.com>,
        Andrea Arcangeli <aarcange@...hat.com>,
        Waiman Long <llong@...hat.com>, Pavel Machek <pavel@....cz>
Subject: RE: [PATCH 09/31] x86/entry/32: Leave the kernel via trampoline stack

From: Linus Torvalds
> Sent: 09 February 2018 19:49
...
> I think the instruction scheduling ends up basically breaking around
> microcoded instructions, which is why you'll get something like 12+n
> cycles for "rep movs" on some uarchs, but at that point it's probably
> mostly in the noise compared to all the other nasty PTI things.

Or 48+n on P4

> You won't see any of the _real_ advantages (which are about moving
> cachelines at a time), so with smallish copies you really only see the
> downsides of "rep movs", which is mainly that instruction scheduling
> hickup with any miocrocode.

I thought that the hardware optimisation for 'rep movsb' on recent
Intel cpus generated word sized memory accesses even for misaligned
short transfers.
My thoughts were that they'd implemented a cache line sized barrel
shift register.
If that isn't true then using it for all memcpy() is probably stupid
(but not as stupid as doing all memcpy backwards!)

	David


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ