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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id D5A05C77B73 for ; Wed, 19 Apr 2023 15:07:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 59E6D900002; Wed, 19 Apr 2023 11:07:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 527F46B0075; Wed, 19 Apr 2023 11:07:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3C82C900002; Wed, 19 Apr 2023 11:07:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 29BC06B0074 for ; Wed, 19 Apr 2023 11:07:13 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id D0D6AAC2A5 for ; Wed, 19 Apr 2023 15:07:12 +0000 (UTC) X-FDA: 80698468704.12.35021C5 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf25.hostedemail.com (Postfix) with ESMTP id D0556A002F for ; Wed, 19 Apr 2023 15:07:09 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=CQW919Qj; spf=pass (imf25.hostedemail.com: domain of longman@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=longman@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1681916829; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=FNMRMuDPRUofqdpcKxax9VPRmENaL6UlH4uiYpQa9Hc=; b=5oerp7JAw3e9ju+Qj2oVbUmLnD/onQgD4J0KVx6DaRpgCBZ0OiZvwoDqkIuvzGROG9VbtP RD2NtERbLTjthQ8t0+KLIz/goZ86SDKVUYHoaW+orcBK2CJSW7UUa2VPcDR5WAUcS10xgL TDgEejZpgWHEzSrEUErkVcuznqo/9/0= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=CQW919Qj; spf=pass (imf25.hostedemail.com: domain of longman@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=longman@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1681916829; a=rsa-sha256; cv=none; b=gLvQwzfytve3+4GsAzaR+cix2fdO7JaFNIlD2xNDQlrJATlvKlrN1sVHJqYax9v2/35hT0 XGd5aalWNyQ8PEjen0MPJSoaLG7oK4kEFO1uQ89n/qbgrENOkoMqAUztV2CtLm/GWkLoh5 Yhp45cSDP8h7driwVWJmt38tyACiJm8= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1681916829; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=FNMRMuDPRUofqdpcKxax9VPRmENaL6UlH4uiYpQa9Hc=; b=CQW919QjYMfFXE5CsyJsjSNvYFHJayQtRsf0sEYru5UScF8xAfeL51/0JLHf8AJkAyYxY0 7JrL6+LQ4u2DIhdC7lyku1DJpF9qJ7caClputem9NIAtCETTLtNlN4iApX3XEv1IS0OfsN eqZcIf62lXkG1r0EkuUzIm85fPWvdsU= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-537-r0csUHEcO028aZ6RXyMXXw-1; Wed, 19 Apr 2023 11:07:05 -0400 X-MC-Unique: r0csUHEcO028aZ6RXyMXXw-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 4D79E101A551; Wed, 19 Apr 2023 15:07:05 +0000 (UTC) Received: from [10.22.9.10] (unknown [10.22.9.10]) by smtp.corp.redhat.com (Postfix) with ESMTP id E702A40C94A9; Wed, 19 Apr 2023 15:07:04 +0000 (UTC) Message-ID: <9f92d530-1cfc-6e50-a717-321ac64ed1c2@redhat.com> Date: Wed, 19 Apr 2023 11:07:04 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Subject: Re: [PATCH] mm/mmap: Map MAP_STACK to VM_STACK Content-Language: en-US To: Matthew Wilcox Cc: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Joe Mario , Barry Marson , Rafael Aquini References: <20230418210230.3495922-1-longman@redhat.com> <20230418141852.75e551e57e97f4b522957c5c@linux-foundation.org> <6c3c68b1-c4d4-dd82-58e8-f7013fb6c8e5@redhat.com> From: Waiman Long In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.1 on 10.11.54.2 X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: D0556A002F X-Rspam-User: X-Stat-Signature: 4p464c1xsgykk6wjxze1aabpzgjtrbfb X-HE-Tag: 1681916829-162583 X-HE-Meta: U2FsdGVkX19kZsXHTvuq+Uthya/Auy85HcDQmkGJbVorTqPWVMVDrcslHiSfbY53OyLAfygSLKMytTT4Lck7uo6aFdhSmVrcba35S+gSedUxWnaJvYCN4iIU4rbGY+64pdXNSQmD1kYyQ8rxvJi5Y+wKTtZOdA5WXIP7g+thOBlqgMnD3NC7SOIRMXsi8uu9dkUPmOujhTNmtBsrtJR6m+PgViQ8C1gSglsHiMeDkSvtBaYn05SfX6uZJcwdtcjUqTaiS4/C0dUNsEqlUG5NadI1nA9nNOThUL8QXDnlkWVP7JQ+a0DMfQ0006NxF6w6cQLZUSZgbW1k62Kdpfw2iJnh8hN/geVEbdEnsK2NRQtx3b+K708mIx0UvLtPyO6So4ZbTKXY5R3LqrFqMlUAiWd/GDUZ/BeITO0/sYeW7PTRZjH8ffcb9NJSEUjsISns5JX+O4fXv6ZSXQBt3ESDAAWIlMoXK4UTsJVKEsjAwu4DLrPlGTrLwpBkFOSZ7ONdXwbZxhzl/G5KxL20Aksqv0qwL4BnEFsAf6r5SVmCXj9VP0GqgQBC9PwbuMs3yHczq5Q/RViRSaXTvihY/nk5ViW2iOLvrvXCYhckP4bU4ztkCinsRtqvukK+7p0xRl77Toulg3RdFU+S3yBUice9thDqlFx7O6sXnD7DuQmvTj784tgcvc4QUBCm1m80F1kOQcJHQm7Mcqzo5XC9neiTe/R50totHr6+eQyuaDee2KL0ihW5RfNW56Zklj7UD7PPaTBLbVysT2ZJBRidBEJKONxMee6X/qhY3nVybPDSwQPqP+ymn5/aBxovL+KPEcwAzLKk/t490+dPkOgmuTblQpAUtaxLLAFOQSl3PNz5SIyE924U0+RChbsdcezrlNoG67jVXTYWDYswzR67+TbDy8QHgomL46NQxSpt8QFthRci665QTF2j8EgxXHluER2vGce7AxIdd54vO79hz8J 7qrjcO1z FRobtL6bz2nxybb0Oo7M1kNsasJ/d0468YTNx5SiCpRCmLF1wMbrSaEGpwfBAGus0l+oHvQDsmES0j/YzzW6uWQNbxQT6jWqjnxSgiOenADo53jEsTPZJP3Ynq9QfJEG4ftlCDFzTymbw8hf/dcNPMwjWMkS/xFFYXc+xshbndWzkVczkprJQiXNrIhWVF28LwHKG/HtsH/4SYiT1j81jJDu/oHvUptCGtYaF 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 4/18/23 23:46, Matthew Wilcox wrote: > On Tue, Apr 18, 2023 at 09:16:37PM -0400, Waiman Long wrote: >>  1) App runs creating lots of threads. >>  2) It mmap's 256K pages of anonymous memory. >>  3) It writes executable code to that memory. >>  4) It calls mprotect() with PROT_EXEC on that memory so >>     it can subsequently execute the code. >> >> The above mprotect() will fail if the mmap'd region's VMA gets merged with >> the VMA for one of the thread stacks.  That's because the default RHEL >> SELinux policy is to not allow executable stacks. > By the way, this is a daft policy. The policy you really want is > EXEC|WRITE is not allowed. A non-writable stack is useless, so it's > actually a superset of your current policy. Forbidding _simultaneous_ > write and executable is just good programming. This way, you don't need > to care about the underlying VMA's current permissions, you just need > to do: > > if ((prot & (PROT_EXEC|PROT_WRITE)) == (PROT_EXEC|PROT_WRITE)) > return -EACCESS; I am not totally sure if the application changes the VMA to read-only first. Even if it does that, it highlights another possible issue when an anonymous VMA is merged with a stack VMA. Either the mprotect() to write-protect the VMA will fail or the application will segfault if it writes stuff to the stack. This particular issue is not related to SELinux. It provides another good idea why we should avoid merging stack VMA to anonymous VMA. Cheers, Longman