From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A4AD6C433E7 for ; Thu, 8 Oct 2020 17:41:32 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C4A68221FE for ; Thu, 8 Oct 2020 17:41:31 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="qarES/+1" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C4A68221FE Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id F2367940007; Thu, 8 Oct 2020 13:41:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EAAF6900002; Thu, 8 Oct 2020 13:41:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D4A77940007; Thu, 8 Oct 2020 13:41:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0052.hostedemail.com [216.40.44.52]) by kanga.kvack.org (Postfix) with ESMTP id A3986900002 for ; Thu, 8 Oct 2020 13:41:30 -0400 (EDT) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 2CD768249980 for ; Thu, 8 Oct 2020 17:41:30 +0000 (UTC) X-FDA: 77349475140.09.magic47_17153bd271d9 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin09.hostedemail.com (Postfix) with ESMTP id E1C63180AD807 for ; Thu, 8 Oct 2020 17:41:29 +0000 (UTC) X-HE-Tag: magic47_17153bd271d9 X-Filterd-Recvd-Size: 3390 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf02.hostedemail.com (Postfix) with ESMTP for ; Thu, 8 Oct 2020 17:41:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=Rhut7fqpaoq3MhbllV5fKKQkrXAlHWXe1jVhLgupsFg=; b=qarES/+1XNKcQx3evKHbUX/o/2 pEemqwzwsLRa6tFhQuoQetXxyM8+ojno0EFBK4RD5V6GfxK6J9NFHuhYpKdrHuAZ3Qs9nSIms4vQD z9vcXOezBzjGYCkyfH3XAMVD7gvpjRUeCmXGNntP4tCFaYvcGyH6YLj5+1pAPB4u/Of+1oGDT94vF ZGbRTjwNiJ8Lh4Qe0zpYblKI5Q7Dek1Zd4riizFumCC+cJm+Fk0SjuizMXUojXt0giMYyxJ4EmMeN LSV/eXglJL72XqxplGsbGLyiy3+4duNvqgOR1RZcj/2vQZmpVbaiyzil14ExISXZSJdD6hfXeaECr CeZ+PHdg==; Received: from willy by casper.infradead.org with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1kQZus-00015k-VS; Thu, 08 Oct 2020 17:41:23 +0000 Date: Thu, 8 Oct 2020 18:41:22 +0100 From: Matthew Wilcox To: Jann Horn Cc: Topi Miettinen , linux-hardening@vger.kernel.org, Andrew Morton , Linux-MM , kernel list Subject: Re: [PATCH RESEND v2] mm: Optional full ASLR for mmap() and mremap() Message-ID: <20201008174122.GM20115@casper.infradead.org> References: <20201008165408.38228-1-toiwoton@gmail.com> <20201008172300.GL20115@casper.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Oct 08, 2020 at 07:26:31PM +0200, Jann Horn wrote: > On Thu, Oct 8, 2020 at 7:23 PM Matthew Wilcox wrote: > > On Thu, Oct 08, 2020 at 07:13:51PM +0200, Jann Horn wrote: > > > And for expanding stacks, it might be a good idea for other > > > reasons as well (locking consistency) to refactor them such that the > > > size in the VMA tree corresponds to the maximum expansion of the stack > > > (and if an allocation is about to fail, shrink such stack mappings). > > > > We're doing that as part of the B-tree ;-) Although not the shrink > > stack mappings part ... > > Wheee, thanks! Finally no more data races on ->vm_start? Ah, maybe still that. The B-tree records the start of the mapping in the tree, but we still keep vma->vm_start as pointing to the current top of the stack (it's still the top if it grows down ... right?) The key is that these numbers may now be different, so from the tree's point of view, the vm addresses for 1MB below the stack appear to be occupied. From the VMA's point of view, the stack finishes where it was last accessed. We also get rid of the insanity of "return the next VMA if there's no VMA at this address" which most of the callers don't want and have to check for. Again, from the tree's point of view, there is a VMA at this address, but from the VMA's point of view, it'll need to expand to reach that address. I don't think this piece is implemented yet, but it's definitely planned.