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: <4524b1c9-3a32-8a2d-b7b8-5c4e65df017b@maciej.szmigiero.name>
Date:   Thu, 10 Feb 2022 22:00:28 +0100
From:   "Maciej S. Szmigiero" <mail@...iej.szmigiero.name>
To:     Sean Christopherson <seanjc@...gle.com>,
        Paolo Bonzini <pbonzini@...hat.com>
Cc:     Vitaly Kuznetsov <vkuznets@...hat.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Jim Mattson <jmattson@...gle.com>,
        Joerg Roedel <joro@...tes.org>, Michal Hocko <mhocko@...e.com>,
        kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
        Kees Cook <keescook@...omium.org>, Willy Tarreau <w@....eu>
Subject: Re: [PATCH] KVM: x86: Fix rmap allocation for very large memslots

On 28.01.2022 22:47, Sean Christopherson wrote:
> On Fri, Jan 28, 2022, Maciej S. Szmigiero wrote:
>> From: "Maciej S. Szmigiero" <maciej.szmigiero@...cle.com>
>>
>> Commit 7661809d493b ("mm: don't allow oversized kvmalloc() calls") has
>> forbidden using kvmalloc() to make allocations larger than INT_MAX (2 GiB).
>>
>> Unfortunately, adding a memslot exceeding 1 TiB in size will result in rmap
>> code trying to make an allocation exceeding this limit.
>> Besides failing this allocation, such operation will also trigger a
>> WARN_ON_ONCE() added by the aforementioned commit.
>>
>> Since we probably still want to use kernel slab for small rmap allocations
>> let's only redirect such oversized allocations to vmalloc.
>>
>> A possible alternative would be to add some kind of a __GFP_LARGE flag to
>> skip the INT_MAX check behind kvmalloc(), however this will impact the
>> common kernel memory allocation code, not just KVM.
> 
> Paolo has a cleaner fix for this[1][2], but it appears to have stalled out somewhere.
> 
> Paolo???
> 
> [1] https://lore.kernel.org/all/20211015165519.135670-1-pbonzini@redhat.com
> [2] https://lore.kernel.org/all/20211016064302.165220-1-pbonzini@redhat.com

So, what we do here?

Apparently the cleaner fix at [2] wasn't picked up despite Kees giving
it his "Reviewed-by".

Thanks,
Maciej

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ