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=-11.4 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL 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 CBFDDC04EBE for ; Thu, 8 Oct 2020 17:14:23 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2B966221FD for ; Thu, 8 Oct 2020 17:14:23 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="klLxhSd3" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2B966221FD Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 79ED86B0068; Thu, 8 Oct 2020 13:14:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 74D9B6B0070; Thu, 8 Oct 2020 13:14:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 63D5A6B0071; Thu, 8 Oct 2020 13:14:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0117.hostedemail.com [216.40.44.117]) by kanga.kvack.org (Postfix) with ESMTP id 350156B0068 for ; Thu, 8 Oct 2020 13:14:22 -0400 (EDT) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id BA7FC181AE86B for ; Thu, 8 Oct 2020 17:14:21 +0000 (UTC) X-FDA: 77349406722.08.sock19_1a05cbb271d9 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin08.hostedemail.com (Postfix) with ESMTP id 9BC101819E766 for ; Thu, 8 Oct 2020 17:14:21 +0000 (UTC) X-HE-Tag: sock19_1a05cbb271d9 X-Filterd-Recvd-Size: 5128 Received: from mail-ed1-f66.google.com (mail-ed1-f66.google.com [209.85.208.66]) by imf19.hostedemail.com (Postfix) with ESMTP for ; Thu, 8 Oct 2020 17:14:21 +0000 (UTC) Received: by mail-ed1-f66.google.com with SMTP id t21so6605799eds.6 for ; Thu, 08 Oct 2020 10:14:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MjSvq6hWT8/96s0xDFZsUEstTcT5YR2t+LBbq3YVkao=; b=klLxhSd3oAlnTsYIcjtHGEZXhchm33gVu8+7BSp8Hb2U1bPvJY+LcC8B79kTzmBMBz dtKWJgMataIg1aB0r0un6QWDh+uyjnuBYe9cCDNHvi6sFoheCWes8NdS1RNx0pEMl3g3 lodEjtS/qN+lj9ujZpYEejIQKI0tMBgcQKBc6aLcC2pN6yYoDpmicgZms4TRF2aS0YYv im6YWnuBFVCc6c8CPgDMSEe9/4GLkYonngLUcDq21g6CHt3SsdQ4lCo/FY0Zb2WwiV0T +Ix6lKC1MUkRXzn/ncyr4YBTkYUc8f14Qs1LbSB0cdAnTo1FQTRtI6pLBmGzBYcJnT1e 8qVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MjSvq6hWT8/96s0xDFZsUEstTcT5YR2t+LBbq3YVkao=; b=HUd2Htj6IPkLtfRJesP6sKiLG5XcSnuw8lwFFF/U3EwaCzN9iJPiZszS1NpeGcjFZ4 pj37UWY8wggjaex6Pzbepdj8i1Mm40OjugVZh9B7yEGwQNdH+HFhsj374IrmdGVAD0yg +unsT/EI/LxchYjhRd+kBPRh7thsCYFZ+2RjTP4dXqArBWgP1UhWbIaqs0zuCeDb+HEJ UmQYB1MrGdrHSl0gPjmf+MKiZuq/43H4ioLzNOSlSMuhouZhb3q5Qg9X/pgETUFgRIzW 8xyaQTXrMyzQaP28NhFjn/zj7co92SW0dMc1SxOXOycobeH6vr/VSbHc4aYWWZQjN2mn 8/xQ== X-Gm-Message-State: AOAM530JdvMMC4ybnZs8jk4rJ7qOh19wNdzNGY9DzDjLdoRG5YD2HiuU LwR/tXmKK/kQ5QpxQTAGh2TPNrCtOUWJI8bLJIHxQA== X-Google-Smtp-Source: ABdhPJw9MIyzoIJ1RLkj1psEZdczlqGKc8hD9QTN82HG81+KramekP5nE/vjSddJehw19xkI1eQJ24eCc0Fp86x1xZg= X-Received: by 2002:a05:6402:b0e:: with SMTP id bm14mr10478897edb.259.1602177259365; Thu, 08 Oct 2020 10:14:19 -0700 (PDT) MIME-Version: 1.0 References: <20201008165408.38228-1-toiwoton@gmail.com> In-Reply-To: <20201008165408.38228-1-toiwoton@gmail.com> From: Jann Horn Date: Thu, 8 Oct 2020 19:13:51 +0200 Message-ID: Subject: Re: [PATCH RESEND v2] mm: Optional full ASLR for mmap() and mremap() To: Topi Miettinen Cc: linux-hardening@vger.kernel.org, Andrew Morton , Linux-MM , kernel list Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000031, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Oct 8, 2020 at 6:54 PM Topi Miettinen wrote: > Writing a new value of 3 to /proc/sys/kernel/randomize_va_space > enables full randomization of memory mappings created with mmap(NULL, > ...). With 2, the base of the VMA used for such mappings is random, > but the mappings are created in predictable places within the VMA and > in sequential order. With 3, new VMAs are created to fully randomize > the mappings. Also mremap(..., MREMAP_MAYMOVE) will move the mappings > even if not necessary. [...] > + if ((flags & MREMAP_MAYMOVE) && randomize_va_space >= 3) { > + /* > + * Caller is happy with a different address, so let's > + * move even if not necessary! > + */ > + new_addr = arch_mmap_rnd(); > + > + ret = mremap_to(addr, old_len, new_addr, new_len, > + &locked, flags, &uf, &uf_unmap_early, > + &uf_unmap); > + goto out; > + } You just pick a random number as the address, and try to place the mapping there? Won't this fail if e.g. the old address range overlaps with the new one, causing mremap_to() to bail out at "if (addr + old_len > new_addr && new_addr + new_len > addr)"? Also, on Linux, the main program stack is (currently) an expanding memory mapping that starts out being something like a couple hundred kilobytes in size. If you allocate memory too close to the main program stack, and someone then recurses deep enough to need more memory, the program will crash. It sounds like your patch will randomly make such programs crash. Also, what's your strategy in general with regards to collisions with existing mappings? Is your intention to just fall back to the classic algorithm in that case? You may want to consider whether it would be better to store information about free memory per subtree in the VMA tree, together with the maximum gap size that is already stored in each node, and then walk down the tree randomly, with the randomness weighted by free memory in the subtrees, but ignoring subtrees whose gaps are too small. 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).