linux-kernel - Re: [PATCH] lib/string: Bring optimized memcmp from glibc

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:   Wed, 21 Jul 2021 22:10:29 +0200
From:   David Sterba <dsterba@...e.cz>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Nikolay Borisov <nborisov@...e.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        Dave Chinner <david@...morbit.com>
Subject: Re: [PATCH] lib/string: Bring optimized memcmp from glibc

On Wed, Jul 21, 2021 at 11:00:59AM -0700, Linus Torvalds wrote:
> On Wed, Jul 21, 2021 at 6:59 AM Nikolay Borisov <nborisov@...e.com> wrote:
> >
> > This is glibc's memcmp version. The upside is that for architectures
> > which don't have an optimized version the kernel can provide some
> > solace in the form of a generic, word-sized optimized memcmp. I tested
> > this with a heavy IOCTL_FIDEDUPERANGE(2) workload and here are the
> > results I got:
> 
> Hmm. I suspect the usual kernel use of memcmp() is _very_ skewed to
> very small memcmp calls, and I don't think I've ever seen that
> (horribly bad) byte-wise default memcmp in most profiles.
> 
> I suspect that FIDEDUPERANGE thing is most likely a very special case.
> 
> So I don't think you're wrong to look at this, but I think you've gone
> from our old "spend no effort at all" to "look at one special case".

The memcmp in question is fs/remap_range.c:vfs_dedupe_file_range_compare

   253                  src_addr = kmap_atomic(src_page);
   254                  dest_addr = kmap_atomic(dest_page);
   ...
   259                  if (memcmp(src_addr + src_poff, dest_addr + dest_poff, cmp_len))
   260                          same = false;
   261  
   262                  kunmap_atomic(dest_addr);
   263                  kunmap_atomic(src_addr);

so adding a memcmp_large that compares by native words or u64 could be
the best option. There's some alignment of the starting offset and
length but that can be special cased and fall back to standard memcmp.
The dedupe ioctl is typically called on ranges spanning many pages so
the overhead of the non-paged portions should be insignificant.