linux-kernel - Re: Question Regarding ERMS memcpy

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: <20170305095059.l4od2yjqm5yxx6ln@pd.tnic>
Date:   Sun, 5 Mar 2017 10:50:59 +0100
From:   Borislav Petkov <bp@...e.de>
To:     hpa@...or.com
Cc:     Logan Gunthorpe <logang@...tatee.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        Tony Luck <tony.luck@...el.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        the arch/x86 maintainers <x86@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Question Regarding ERMS memcpy

On Sat, Mar 04, 2017 at 04:56:38PM -0800, hpa@...or.com wrote:
> That's what the -march= and -mtune= option do!

How does that even help with a distro kernel built with -mtune=generic ?

gcc can't possibly know on what targets is that kernel going to be
booted on. So it probably does some universally optimal things, like in
the dmi_scan_machine() case:

	memcpy_fromio(buf, p, 32);

turns into:

        .loc 3 219 0
        movl    $8, %ecx        #, tmp79
        movq    %rax, %rsi      # p, p
        movq    %rsp, %rdi      #, tmp77
        rep movsl

Apparently it thinks it is fine to do 8*4-byte MOVS. But why not
4*8-byte MOVS?

That's half the loops.

 [ It is a whole different story what the machine actually does underneath. It
    being a half cacheline probably doesn't help and it really does the separate
    MOVs but then it would be cheaper if it did 4 8-byte ones. ]

One thing's for sure - both variants are certainly cheaper than to CALL
a memcpy variant.

What we probably should try to do, though, is simply patch in the body
of REP; MOVSQ or REP; MOVSB into the call sites and only have a call to
memcpy_orig() because that last one if fat.

I remember we did talk about it at some point but don't remember why we
didn't do it.

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--