linux-kernel - Re: [PATCH] ksm: Fix unlocked iteration over vmas in cmp_and_merge

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] [day] [month] [year] [list]

Message-ID: <20170913134632.GB12833@redhat.com>
Date:   Wed, 13 Sep 2017 15:46:32 +0200
From:   Andrea Arcangeli <aarcange@...hat.com>
To:     Michal Hocko <mhocko@...nel.org>
Cc:     Kirill Tkhai <ktkhai@...tuozzo.com>, akpm@...ux-foundation.org,
        minchan@...nel.org, zhongjiang@...wei.com, mingo@...nel.org,
        imbrenda@...ux.vnet.ibm.com, kirill.shutemov@...ux.intel.com,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        Hugh Dickins <hughd@...gle.com>,
        sioh Lee <solee@...korea.ac.kr>
Subject: Re: [PATCH] ksm: Fix unlocked iteration over vmas in
 cmp_and_merge_page()

On Wed, Sep 13, 2017 at 01:25:09PM +0200, Michal Hocko wrote:
> [CC Claudio and Hugh]

Cc'ed Sioh as well.

> 
> On Mon 11-09-17 14:05:05, Kirill Tkhai wrote:
> > In this place mm is unlocked, so vmas or list may change.
> > Down read mmap_sem to protect them from modifications.
> > 
> > Signed-off-by: Kirill Tkhai <ktkhai@...tuozzo.com>
> > (and compile-tested-by)
> 
> Fixes: e86c59b1b12d ("mm/ksm: improve deduplication of zero pages with colouring")
> AFAICS. Maybe even CC: stable as unstable vma can cause large variety of
> issues including memory corruption.
> 
> The fix lookds good to me
> Acked-by: Michal Hocko <mhocko@...e.com>

Reviewed-by: Andrea Arcangeli <aarcange@...hat.com>

ksm_use_zero_pages is off by default, this is probably why it went
unnoticed.

Wondering if we should consider enabling ksm_use_zero_pages by default
on those arches that have few physical cache colors.

If we change the jhash2 to crc32c-intel like Sioh suggested (to
speedup the background scan), the chance of false positive and waste
of try_to_merge_one_page here will increase to one every 100k or so if
comparing random data against the zeropage (instead of the current
insignificant amount of false positives provided by jhash2 great
random uniformity).

So the ksm_use_zero_pages branch is currently missing a memcmp against
the ZERO_PAGE zeroes before calling write_protect_page. It's not a
functional bug because there's one last memcmp mandatory to run after
write protection, so this isn't destabilizing anything, but especially
if using crc32c (I suppose crc32cbe-vx is going to be much faster for
the background scan on s390 too) it would be a potential inefficiency
that wrprotects non zero pages by mistake once every 100k or more.

We never care about the cksum actual value, we only care if it changed
since the last pass, this is why ultimately I believe crc32c would
suffice for this purpose, it's extremely unlikely it won't change over
a data change. But it's definitely not suitable to find equality
across million of pages on large systems because it has a not suitable
random uniformity.

In short the "zero_checksum" variable should be dropped and the memcmp
will then materialize naturally after removing it.

Thanks,
Andrea