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=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 58035C433DF for ; Mon, 8 Jun 2020 17:51:22 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1637F206A4 for ; Mon, 8 Jun 2020 17:51:22 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="F1GKRaIO" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1637F206A4 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id B1EAA6B0003; Mon, 8 Jun 2020 13:51:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AA6B56B0005; Mon, 8 Jun 2020 13:51:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 998B76B0006; Mon, 8 Jun 2020 13:51:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0022.hostedemail.com [216.40.44.22]) by kanga.kvack.org (Postfix) with ESMTP id 7D0A46B0003 for ; Mon, 8 Jun 2020 13:51:21 -0400 (EDT) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 39414165E1F for ; Mon, 8 Jun 2020 17:51:21 +0000 (UTC) X-FDA: 76906786362.17.body94_1b1584826dbb Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin17.hostedemail.com (Postfix) with ESMTP id 0EC1D180CF7F7 for ; Mon, 8 Jun 2020 17:51:21 +0000 (UTC) X-HE-Tag: body94_1b1584826dbb X-Filterd-Recvd-Size: 5427 Received: from mail-lf1-f66.google.com (mail-lf1-f66.google.com [209.85.167.66]) by imf41.hostedemail.com (Postfix) with ESMTP for ; Mon, 8 Jun 2020 17:51:20 +0000 (UTC) Received: by mail-lf1-f66.google.com with SMTP id c21so10763452lfb.3 for ; Mon, 08 Jun 2020 10:51:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gRjynYNCSrQ+3LtO4CNYj8Qf3Jgs1oHj0547MN3DDYw=; b=F1GKRaIO4F6VG9PR/aABO+XPQFsB+3IjOpHn/tPG9PgsJUMoTRZxAVYFC2ezpZy8YU PZryA5pna6jQLicPTHXs0WpMxKgYndes5Iq6ShULp29PTCH40gxeckP66Q4V6qrp7yq7 yoymkfnyZoYAiFHWGK0DKZE+Q3L11R7jiEUqc= 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=gRjynYNCSrQ+3LtO4CNYj8Qf3Jgs1oHj0547MN3DDYw=; b=ouy1sQs1foGQGAqqqkFflDFo7Yh8AcjLKl9rwQ7CRh0IxzU5ad/74L2NBi5i8ZOCPi PDMfdF3grDstlLHOw87DyooJNXjo/mAHhiyauY8E+cHH1uaJF1zOBmjwZ9wHY3HDGmrg Etg6u/h5s0O9KYPzgdYldWzzKY1R+g5fzTaJQnzhsWId4eLCCztfLwVW5XRD0mjDqvfq hCbKHHKzlJ1Pmb+a2Ihpiqv7VWtJKJnUIjzBoHQ6XmYK3HyH7l59CDPfHfOWaZNmIlji ZbqsMfZZPO4TKmsMOl8CCoZtmtdtiMnjR+CxdfUyRD+8EgPSyZipIRcewNtf11Fg76SD 1QJg== X-Gm-Message-State: AOAM533B1KN28REqwxhY82tlIozKxuoZChKT3qjndR19tf3pEQZfBuX/ aLAR3NMsgwxADo/P0QfoPuwPqFTm7Xw= X-Google-Smtp-Source: ABdhPJx/kGQBJSx3EfDm6/tc2kXztsEZK+OYn8DZZ5nXc3YLJykgkCGmL0ryfW9f4MIaWx10tz9EtA== X-Received: by 2002:a19:5212:: with SMTP id m18mr13141491lfb.127.1591638678021; Mon, 08 Jun 2020 10:51:18 -0700 (PDT) Received: from mail-lj1-f180.google.com (mail-lj1-f180.google.com. [209.85.208.180]) by smtp.gmail.com with ESMTPSA id l14sm940105lja.2.2020.06.08.10.51.16 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Jun 2020 10:51:16 -0700 (PDT) Received: by mail-lj1-f180.google.com with SMTP id n24so21594812lji.10 for ; Mon, 08 Jun 2020 10:51:16 -0700 (PDT) X-Received: by 2002:a2e:b5d9:: with SMTP id g25mr12358808ljn.285.1591638675803; Mon, 08 Jun 2020 10:51:15 -0700 (PDT) MIME-Version: 1.0 References: <20200607212615.b050e41fac139a1e16fe00bd@linux-foundation.org> <20200608044121.stuEeVRhM%akpm@linux-foundation.org> In-Reply-To: <20200608044121.stuEeVRhM%akpm@linux-foundation.org> From: Linus Torvalds Date: Mon, 8 Jun 2020 10:50:59 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [patch 24/54] mm/mmap.c: do not allow mappings outside of allowed limits To: Andrew Morton Cc: agordeev@linux.ibm.com, Linux-MM , mm-commits@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 0EC1D180CF7F7 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam04 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 Sun, Jun 7, 2020 at 9:41 PM Andrew Morton wrote: > > One can set a lowest possible address in /proc/sys/vm/mmap_min_addr > and mmap below that bound nevertheless. Well, /proc/sys/vm/mmap_min_addr actually sets "dac_mmap_min_addr" directly, and then indirectly sets mmap_min_addr with slightly different rules. > It is possible to request a fixed mapping address below mmap_min_addr and > succeed. This update adds early checks of mmap_min_addr and mmap_end > boundaries and fixes the above issue. > > Apart from it is wrong I am not aware of any existing issue. Hmm. I think your patch is generally fine, although a few things worries me: - the "mmap_end" check seems wrong. It should be something like if (len > mmap_end || addr > mmap_end-len) shouldn't it? - the limit we _do_ test is that "dac_mmap_min_addr", and we allow lower limits for CAP_SYS_RAWIO - I think this will break vm86 mode on 32-bit x86. Have you tested that? In other words, I think the reason we don't do that hard check of mmap_min_addr is exactly that vm86 issue. If we were to force a hard check, we're now making it impossible to use vm86 mode. So I'm dropping this patch, because it is not clear that this was fully thought through. And if it *was* intentional, and people knew about the vm86 issues, and the thing about dac_mmap_min_addr and the check in cap_mmap_addr(), then it should be mentioned in the commit message. That said, I'd be more than willing to move the "cap_mmap_addr()" check into the mm layer and make it a whole lot more obvious. And I'd also be more than willing to really make the difference between "dac_mmap_min_addr" and "mmap_min_addr" actually meaningful, and really enforce "mmap_min_addr", because right now it's a half-baked feature that isn't actually used for anything but hinting and the grow-down issue. And that, in turn, is because of those vm86 issues, but also because we've historically had programs that wanted some legacy behavior and did a mmap() of a zero-page at the 0 address (because that's how some old Unix environments worked - I htink legacy parisc or similar). Linus