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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 21A98C4321E for ; Thu, 10 Nov 2022 11:47:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:CC:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=tCFndZQ955R2EE+s0uyEUqj2voOOlNkeq+v+BkyyDPw=; b=DAPeRP+QJFauLZ 8w28lcKgPzdswUWALWfUwhIqyRMAT2GtOfRPck9t3rqzRsVtHHl3k/ZygaAjkYLaYwRMvFVs1ouqH YTkNFbsuVBfEIehOTqgStoTxee8XioIZpNd4jlPRiUlAmSjeoxQQOQu9AkOE0o4MsSd3Rz6CNRuhz P7JOs6UWjMrRga3fa9tu5J1LVvvHzKpD3K0N27I0KqDrXxTHh8kFIboncKaXdqg1FhLONtnxcO68N o4cqZJLoyhV3DyewZ8TyPNXLG0M78s26pgx9yq8134Tmy5DHuzABnxwbSW9x739O5v0gpliycl2Vg cDWk7+R3E/dwkxJCiY5g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ot5zg-005TkT-MV; Thu, 10 Nov 2022 11:45:20 +0000 Received: from mail-db8eur05on2048.outbound.protection.outlook.com ([40.107.20.48] helo=EUR05-DB8-obe.outbound.protection.outlook.com) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1ot5id-005Lxb-7O for linux-arm-kernel@lists.infradead.org; Thu, 10 Nov 2022 11:27:50 +0000 ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=Wd19s202KEvD/luNxsVGSE/fVKK9ImgxrmReojd/rYwv81TwwFiEjCCZmvVcWdr2sKHFVVELNXLzU5s7xnjWyz6ZcD8mFldJMfdaROyzMiXtGVxNIACMR6xdMeKOgeBsAjmZmVz23zFuh6Ren0h5EtEdZcYMqjRDRVA8bydVls/2n38cI5H48lNf5Jc8gfV2/9uwPlIUUJ5PvcuVP/GBmSMioH0x8Jgo8o7t+h48gVV83x2g2hRn64kVFs4eMNRxCcFVwolLalKn6+inXm7z14TpUJDXAsmIaYuQ53ugFuK++haV38hrUfPbEKMkSpuhQgR6Dn0X7UriT1KyLLg5tg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=CAY6bTKEHy6E0jFBr1GmEPR2eW12htYF2xzXRchbCnE=; b=G6QZ6b7HrdFrAW2B37x09seyqwwLw5UJg68J8g9DyJ/Ag29g0QqMG0N6r6zJJoSDIO4dYf+PDxtCZO7CURBjwieQshPV8cd5KbpXGIpmoLfgSTJw/gUGBwyF0SRygZOmpu5WwDY7Abr12tSlHDopcVPTNz0WdmYfhTiftzgoRrrykzcAeM1/3D0D6nAqK+FGcsM6NxSn/4k9K1Tt3FdoqjGVWanGuqAVTdp9A3/j/6NCPqxh3bq3y3rLR8R9egjAvSreBiobXQnFNxqdXQUEcXcy+QGjrdEWJ99Go1VFPGVB7zCalhCtMnsg1VabPnVTjBkoRPzsHGxE3PCETo2vvw== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) smtp.rcpttodomain=lists.infradead.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dmarc=[1,1,header.from=arm.com]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CAY6bTKEHy6E0jFBr1GmEPR2eW12htYF2xzXRchbCnE=; b=UAY3ohk3rLdPeCOCzrqlh6Xk/13MKQbFuTbQt2YKsn21YqWIadGtmzVtnXTG8oAuqF3AVmNoAolqWY3hcZR16AF1drA/jEFtHVijEoZQY878rp1zC2KF0BP0IlMeNzzU0xGA5OAsdn6qrpqPAN4ImP8IBASXIxuJbWWSrO3TAJs= Received: from DB6P192CA0011.EURP192.PROD.OUTLOOK.COM (2603:10a6:4:b8::21) by DB9PR08MB7533.eurprd08.prod.outlook.com (2603:10a6:10:301::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5813.13; Thu, 10 Nov 2022 11:27:26 +0000 Received: from DBAEUR03FT022.eop-EUR03.prod.protection.outlook.com (2603:10a6:4:b8:cafe::40) by DB6P192CA0011.outlook.office365.com (2603:10a6:4:b8::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5791.27 via Frontend Transport; Thu, 10 Nov 2022 11:27:26 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; pr=C Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DBAEUR03FT022.mail.protection.outlook.com (100.127.142.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5813.12 via Frontend Transport; Thu, 10 Nov 2022 11:27:26 +0000 Received: ("Tessian outbound f394866f3f2b:v130"); Thu, 10 Nov 2022 11:27:25 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 31081a39acac836d X-CR-MTA-TID: 64aa7808 Received: from 2e37aa3daea7.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id D157C998-6C6E-4D49-B8D4-6846751CF33A.1; Thu, 10 Nov 2022 11:27:18 +0000 Received: from EUR01-DB5-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 2e37aa3daea7.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 10 Nov 2022 11:27:18 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=K1K/wsANYCnoQoBYLM49+4Nz6oJUqMhkcFYIFSWesJNPZ9A/z6BZ8NjQJYv4KoA5W7r7J0ZJonFzbgJXFeBpFw+F7Xo1JzunPNf6MLsEGFtAOYJiaIavrqCHEI85k+z0SBDcpbjTtiApHbK63gtotrEue8OOko2W80NhzJKFuMmTGg76C1HwH8+1EZRU4Ahftzb04o2zdDXsj9BeVe6egKVCChak6Qne/Yg4nv/MrVPcdM4mP3YWHJV9ZFR4sfQ3kQuEF7vIkZQmubOTD1mI8G4/nci2FDphCDKnG7e5cpp2ySh/o1uorngOWBD2ICixc3J7MmeAI45skWkcE4B+vA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=CAY6bTKEHy6E0jFBr1GmEPR2eW12htYF2xzXRchbCnE=; b=MWJpZYP9yhrKC787GIePpEwET+5BT9nFahz97afGzClX4g+VCVajeM995D8K5sEPx0mdgA+Fh3m7HCGWWbWBkgr1MTsF29zypIVwHmTM1r7sP8aCLP8u6jR92MxwUEQmXvczexRFsmhuUqplnNyVTuYSs1uqSswMhsVdz29oN2XAJVZpLWZXxk6tyivH10lJpR9eJVmN1FxoVQm9y67GN6z0bgcbrPtvlKhLB0Lh8l7KQuzcUBMIamUcrCOLhdi413Egkqny4Z1j5SKhUZdYv/scEfLrZAZoNcrQFzIczdBdtXxPKuq91aB8zogtswydAsCq8lCHKipVrZSncLs8eA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 40.67.248.234) smtp.rcpttodomain=chromium.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CAY6bTKEHy6E0jFBr1GmEPR2eW12htYF2xzXRchbCnE=; b=UAY3ohk3rLdPeCOCzrqlh6Xk/13MKQbFuTbQt2YKsn21YqWIadGtmzVtnXTG8oAuqF3AVmNoAolqWY3hcZR16AF1drA/jEFtHVijEoZQY878rp1zC2KF0BP0IlMeNzzU0xGA5OAsdn6qrpqPAN4ImP8IBASXIxuJbWWSrO3TAJs= Received: from DB7PR02CA0033.eurprd02.prod.outlook.com (2603:10a6:10:52::46) by DB9PR08MB7493.eurprd08.prod.outlook.com (2603:10a6:10:36e::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5813.13; Thu, 10 Nov 2022 11:27:16 +0000 Received: from DBAEUR03FT024.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:52:cafe::22) by DB7PR02CA0033.outlook.office365.com (2603:10a6:10:52::46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5813.12 via Frontend Transport; Thu, 10 Nov 2022 11:27:16 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 40.67.248.234) smtp.mailfrom=arm.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 40.67.248.234 as permitted sender) receiver=protection.outlook.com; client-ip=40.67.248.234; helo=nebula.arm.com; pr=C Received: from nebula.arm.com (40.67.248.234) by DBAEUR03FT024.mail.protection.outlook.com (100.127.142.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.5813.12 via Frontend Transport; Thu, 10 Nov 2022 11:27:16 +0000 Received: from AZ-NEU-EX02.Emea.Arm.com (10.251.26.5) by AZ-NEU-EX03.Arm.com (10.251.24.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.12; Thu, 10 Nov 2022 11:27:16 +0000 Received: from AZ-NEU-EX03.Arm.com (10.251.24.31) by AZ-NEU-EX02.Emea.Arm.com (10.251.26.5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.12; Thu, 10 Nov 2022 11:27:15 +0000 Received: from e124191.cambridge.arm.com (10.1.197.45) by mail.arm.com (10.251.24.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.12 via Frontend Transport; Thu, 10 Nov 2022 11:27:15 +0000 Date: Thu, 10 Nov 2022 11:27:14 +0000 From: Joey Gouly To: Kees Cook CC: Catalin Marinas , Andrew Morton , Lennart Poettering , Zbigniew =?utf-8?Q?J=C4=99drzejewski-Szmek?= , "Alexander Viro" , Szabolcs Nagy , "Mark Brown" , Jeremy Linton , "Topi Miettinen" , , , , , , Subject: Re: [PATCH v1 1/2] mm: Implement memory-deny-write-execute as a prctl Message-ID: <20221110112714.GA1201@e124191.cambridge.arm.com> References: <20221026150457.36957-1-joey.gouly@arm.com> <20221026150457.36957-2-joey.gouly@arm.com> <202210281053.904BE2F@keescook> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <202210281053.904BE2F@keescook> User-Agent: Mutt/1.9.4 (2018-02-28) X-EOPAttributedMessage: 1 X-MS-TrafficTypeDiagnostic: DBAEUR03FT024:EE_|DB9PR08MB7493:EE_|DBAEUR03FT022:EE_|DB9PR08MB7533:EE_ X-MS-Office365-Filtering-Correlation-Id: bc4994d1-0ef9-40c5-c665-08dac30e8b50 x-checkrecipientrouted: true NoDisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: 2YB0KO879c3f20HFE+k/Z/8truzMEZaGio8Zk7GsJKQTN/bKTaf+9bly/dyymZr7e64gxKPxwPSMY5HzNcsbEZHYxxymRxnfR0xYg7b3U9mI1O4U6/zTntkd9JjrKLAOs2Gecmz+ZCIq3nBwrDNW58HMk8bO9u70BTjg8LEzuVd8yIq51NQxXYIi+PBphLZkZPBKj3mrnk+Vp2boZK8Z62Swl1e9syAgSUhxr30226/TLMrla1DGyzmuV3zvl2nrKdG/6uokc1/X4fCglHZI2YN4N74OZp/5GLpEl4VwgTS8DTS1ObEHQfNdqylfUM3ZlHhXPkAs9ZBdQ4npVDH4Y9QnjFvtaL3xvmKrNBZFMJtmci6RxCjmMjnj/Xq81De1EMpNHnFlgNjSfpF6lPnoP/bWXpiwZJN7zhjPAUpsXN0lxDnmoibzwL8nJVtsxny9TEcC55L1TgcnFU3MgEL5vwrU/H90IxiLLwohFn77P+AAqXQSGSzLPE8ouuJdoELf3X4mo3xcCcpokqPXUIXnRFkhgYoQU+i5dveoKlN3NE70FWXeUEaUPJsdQ5B0bOYiS4prz/0fJtFhpnuFxAQDImrJ2ys579XjdKrW0JVNnABP74us3bfKiSYEATUFdMTgeKufy4MNctQaAwaDcKS47oXNJb+pd0zy4qiIcs2IjL4LiUJ2KD5opty7o4nH3RO1BxTL2DbY3BUHqUj0gtC5uZLWwD9yHfcrU7bREAI8BzJXhnpstSNLuqHDLVjCqrWEUcuc7Rbt0M4W8AVvFpJzmaD+XZsBOTu1UwqdTmXAJaU2fP7l5qfc3OTghzqaHKfnO8qumJUHrzXfqqOZukegm9PKpQmWiqx1sxkM/XW8ats= X-Forefront-Antispam-Report-Untrusted: CIP:40.67.248.234;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:nebula.arm.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230022)(4636009)(376002)(346002)(396003)(39860400002)(136003)(451199015)(46966006)(40470700004)(36840700001)(478600001)(82310400005)(82740400003)(966005)(336012)(33656002)(2906002)(36860700001)(41300700001)(40480700001)(6916009)(44832011)(316002)(54906003)(86362001)(356005)(81166007)(7416002)(186003)(7696005)(70586007)(8676002)(70206006)(1076003)(40460700003)(83380400001)(4326008)(26005)(8936002)(47076005)(5660300002)(426003)(55016003)(17423001)(36900700001);DIR:OUT;SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR08MB7493 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DBAEUR03FT022.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 9a034a19-abae-4250-3af4-08dac30e85a3 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: omQhTQ7518GsregqQ7KalIxxx/FK+QgoxjrcoCLykjkzzjU750zNb2pwHGvm24YZzl077fZi1Zg3AuZlevZNOqYpleL6IhbVW2VOsIpcHHan8yD0XG7ZsiS5VOEtzBLX4Uc66WqRFjHmdQIqwsii01zMfEHj/XSJBsnvSYH0Kq1By1ivmhql66v5vgkpbPJjokALcmU78Fx49a87mFitqWr0lRaXrGgP8Sa4EFmOCPytq5lfYxvLkm0FxGzjG8UdZmso10GthEwwVoEzPvQH1x6CTeVQCzHrai78coxEIubwkWkQD+PEnUFZ/RrJE9Vn//ftx9AQXhSEIIiSca4lIBTl06DsHcGxoAvvFSg5JkT5w2aKLTXLuh9h1kDyLdFzi7h5orzK7n98T2kWXLVWP57spXbhfJe1A/k4YjxcxuBL9HaJL+5bL/0A2a38A3q/HjBJ1z8UJW/kRlvOh5GMSyB3V9sNbkdTTrRhvs/rZ/6ggcU6G5qB5VesYGGT4I1uqDdGQl9534bHUQACV++l5k+j9c7tvt5tGl6SbhvXizhYtB43ljnpwYaS2TGqI61+QqQdxNP6pU8UD8Gg+/9rbOeyqViN2CJ/iKN8WMilXhsbuuEzwKo/q2dx2hahEJco5GZbVUCyQYgOf5oNbcYkF+368xP1c3tI4tUlKqR7DudiOzwV7vNUTEZBuviXZ63Jx2Kwslu6CPAsttBjB6yp3100XBl3o1A8PSV/Kduoy9sEnvnCAdZ7bdtKXYg2VS/Wp2QO/X8eWYGJDkQDoDfIcTb+t8X0bXoRCXoU1dF2kTXPvdFVDXH/D8fNY0CFgFv/MzoVIGFUfACmZB1wD5iSAQ== X-Forefront-Antispam-Report: CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com;CAT:NONE;SFS:(13230022)(4636009)(39860400002)(136003)(376002)(396003)(346002)(451199015)(46966006)(40470700004)(36840700001)(426003)(47076005)(54906003)(966005)(316002)(7696005)(41300700001)(107886003)(6862004)(8676002)(70586007)(70206006)(4326008)(8936002)(478600001)(2906002)(40460700003)(5660300002)(44832011)(33656002)(26005)(186003)(336012)(55016003)(83380400001)(1076003)(40480700001)(36860700001)(82310400005)(86362001)(81166007)(82740400003)(17423001);DIR:OUT;SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Nov 2022 11:27:26.0475 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: bc4994d1-0ef9-40c5-c665-08dac30e8b50 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: DBAEUR03FT022.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR08MB7533 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221110_032739_750777_FA25E26C X-CRM114-Status: GOOD ( 24.36 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi, On Fri, Oct 28, 2022 at 11:51:00AM -0700, Kees Cook wrote: > On Wed, Oct 26, 2022 at 04:04:56PM +0100, Joey Gouly wrote: > > The aim of such policy is to prevent a user task from creating an > > executable mapping that is also writeable. > > > > An example of mmap() returning -EACCESS if the policy is enabled: > > > > mmap(0, size, PROT_READ | PROT_WRITE | PROT_EXEC, flags, 0, 0); > > > > Similarly, mprotect() would return -EACCESS below: > > > > addr = mmap(0, size, PROT_READ | PROT_EXEC, flags, 0, 0); > > mprotect(addr, size, PROT_READ | PROT_WRITE | PROT_EXEC); > > > > The BPF filter that systemd MDWE uses is stateless, and disallows > > mprotect() with PROT_EXEC completely. This new prctl allows PROT_EXEC to > > be enabled if it was already PROT_EXEC, which allows the following case: > > > > addr = mmap(0, size, PROT_READ | PROT_EXEC, flags, 0, 0); > > mprotect(addr, size, PROT_READ | PROT_EXEC | PROT_BTI); > > > > where PROT_BTI enables branch tracking identification on arm64. > > > > Signed-off-by: Joey Gouly > > Co-developed-by: Catalin Marinas > > Signed-off-by: Catalin Marinas > > Cc: Andrew Morton > > --- > > include/linux/mman.h | 15 +++++++++++++++ > > include/linux/sched/coredump.h | 6 +++++- > > include/uapi/linux/prctl.h | 6 ++++++ > > kernel/sys.c | 18 ++++++++++++++++++ > > mm/mmap.c | 3 +++ > > mm/mprotect.c | 5 +++++ > > 6 files changed, 52 insertions(+), 1 deletion(-) > > > > diff --git a/include/linux/mman.h b/include/linux/mman.h > > index 58b3abd457a3..d84fdeab6b5e 100644 > > --- a/include/linux/mman.h > > +++ b/include/linux/mman.h > > @@ -156,4 +156,19 @@ calc_vm_flag_bits(unsigned long flags) > > } > > > > unsigned long vm_commit_limit(void); > > + > > +static inline bool map_deny_write_exec(struct vm_area_struct *vma, unsigned long vm_flags) > > Traditionally, it is easier to write these in the positive instead of > needing to parse a double-negative. > > static inline bool allow_write_exec(...) This doesn't feel like a double negative to me, and I think it would be better to keep the name of the function similar to the name of the 'feature'. However I'm not too fussed either way. > > > +{ > > + if (!test_bit(MMF_HAS_MDWE, ¤t->mm->flags)) > > + return false; > > + > > + if ((vm_flags & VM_EXEC) && (vm_flags & VM_WRITE)) > > + return true; > > + > > + if (vma && !(vma->vm_flags & VM_EXEC) && (vm_flags & VM_EXEC)) > > + return true; > > + > > + return false; > > +} > > Since this is implementation "2" from the earlier discussion[1], I think > some comments in here are good to have. (e.g. to explain to people > reading this code why there is a vma test, etc.) Perhaps even explicit > repeat the implementation expectations. > > Restating from that thread: > > 2. "is not already PROT_EXEC": > > a) mmap(PROT_READ|PROT_WRITE|PROT_EXEC); // fails > > b) mmap(PROT_READ|PROT_EXEC); > mprotect(PROT_READ|PROT_EXEC|PROT_BTI); // passes > > c) mmap(PROT_READ); > mprotect(PROT_READ|PROT_EXEC); // fails > > d) mmap(PROT_READ|PROT_WRITE); > mprotect(PROT_READ); > mprotect(PROT_READ|PROT_EXEC); // fails Good idea, I will add a comment. > > [1] https://lore.kernel.org/linux-arm-kernel/YmGjYYlcSVz38rOe@arm.com/ > > > #endif /* _LINUX_MMAN_H */ > > diff --git a/include/linux/sched/coredump.h b/include/linux/sched/coredump.h > > index 8270ad7ae14c..0e17ae7fbfd3 100644 > > --- a/include/linux/sched/coredump.h > > +++ b/include/linux/sched/coredump.h > > @@ -81,9 +81,13 @@ static inline int get_dumpable(struct mm_struct *mm) > > * lifecycle of this mm, just for simplicity. > > */ > > #define MMF_HAS_PINNED 27 /* FOLL_PIN has run, never cleared */ > > + > > +#define MMF_HAS_MDWE 28 > > +#define MMF_HAS_MDWE_MASK (1 << MMF_HAS_MDWE) > > + > > #define MMF_DISABLE_THP_MASK (1 << MMF_DISABLE_THP) > > > > #define MMF_INIT_MASK (MMF_DUMPABLE_MASK | MMF_DUMP_FILTER_MASK |\ > > - MMF_DISABLE_THP_MASK) > > + MMF_DISABLE_THP_MASK | MMF_HAS_MDWE_MASK) > > Good, yes, new "live forever" bit here. Perhaps bikeshedding over the > name, see below. > > > > > #endif /* _LINUX_SCHED_COREDUMP_H */ > > diff --git a/include/uapi/linux/prctl.h b/include/uapi/linux/prctl.h > > index a5e06dcbba13..ab9db1e86230 100644 > > --- a/include/uapi/linux/prctl.h > > +++ b/include/uapi/linux/prctl.h > > @@ -281,6 +281,12 @@ struct prctl_mm_map { > > # define PR_SME_VL_LEN_MASK 0xffff > > # define PR_SME_VL_INHERIT (1 << 17) /* inherit across exec */ > > > > +/* Memory deny write / execute */ > > +#define PR_SET_MDWE 65 > > +# define PR_MDWE_FLAG_MMAP 1 > > + > > +#define PR_GET_MDWE 66 > > + > > #define PR_SET_VMA 0x53564d41 > > # define PR_SET_VMA_ANON_NAME 0 > > > > diff --git a/kernel/sys.c b/kernel/sys.c > > index 5fd54bf0e886..08e1dd6d2533 100644 > > --- a/kernel/sys.c > > +++ b/kernel/sys.c > > @@ -2348,6 +2348,18 @@ static int prctl_set_vma(unsigned long opt, unsigned long start, > > } > > #endif /* CONFIG_ANON_VMA_NAME */ > > > > +static inline int prctl_set_mdwe(void) > > +{ > > + set_bit(MMF_HAS_MDWE, ¤t->mm->flags); > > + > > + return 0; > > +} > > + > > +static inline int prctl_get_mdwe(void) > > +{ > > + return test_bit(MMF_HAS_MDWE, ¤t->mm->flags); > > +} > > These will need to change -- the aren't constructed for future expansion > at all. At the very least, all the arguments need to passed to be > checked that they are zero. e.g.: > > int prctl_set_mdwe(unsigned long bits, unsigned long arg3, > unsigned long arg4, unsigned long arg5) > { > if (arg3 || arg4 || arg5) > return -EINVAL; > > ... > > return 0; > } > > Otherwise, there's no way to add arguments in the future because old > userspace may have been sending arbitrary junk on the stack, etc. > > And regardless, I think we'll need some explicit flag bits here, since > we can see there has been a long history of various other desired > features that may end up living in here. For now, a single bit is fine. > The intended behavior is the inability to _add_ PROT_EXEC to an existing > vma, and to deny the creating of a W+X vma to begin with, so perhaps > this bit can be named MDWE_FLAG_REFUSE_EXEC_GAIN? > > Then the above "..." becomes: > > if (bits & ~(MDWE_FLAG_REFUSE_EXEC_GAIN)) > return -EINVAL; > > if (bits & MDWE_FLAG_REFUSE_EXEC_GAIN) > set_bit(MMF_HAS_MDWE, ¤t->mm->flags); > else if (test_bit(MMF_HAS_MDWE, ¤t->mm->flags)) > return -EPERM; /* Cannot unset the flag */ > > And prctl_get_mdwe() becomes: > > int prctl_get_mdwe(unsigned long arg2, unsigned long arg3, > unsigned long arg4, unsigned long arg5) > { > if (arg2 || arg3 || arg4 || arg5) > return -EINVAL; > return test_bit(MMF_HAS_MDWE, ¤t->mm->flags) ? > MDWE_FLAG_REFUSE_EXEC_GAIN : 0; > } Thanks, makes sense, I have incorporated those changes. > > > + > > SYSCALL_DEFINE5(prctl, int, option, unsigned long, arg2, unsigned long, arg3, > > unsigned long, arg4, unsigned long, arg5) > > { > > @@ -2623,6 +2635,12 @@ SYSCALL_DEFINE5(prctl, int, option, unsigned long, arg2, unsigned long, arg3, > > error = sched_core_share_pid(arg2, arg3, arg4, arg5); > > break; > > #endif > > + case PR_SET_MDWE: > > + error = prctl_set_mdwe(); > > + break; > > + case PR_GET_MDWE: > > + error = prctl_get_mdwe(); > > + break; > > case PR_SET_VMA: > > error = prctl_set_vma(arg2, arg3, arg4, arg5); > > break; > > diff --git a/mm/mmap.c b/mm/mmap.c > > index 099468aee4d8..42eaf6683216 100644 > > --- a/mm/mmap.c > > +++ b/mm/mmap.c > > @@ -1409,6 +1409,9 @@ unsigned long do_mmap(struct file *file, unsigned long addr, > > vm_flags |= VM_NORESERVE; > > } > > > > + if (map_deny_write_exec(NULL, vm_flags)) > > + return -EACCES; > > + > > This seems like the wrong place to do the check -- that the vma argument > is a hard-coded "NULL" is evidence that something is wrong. Shouldn't > it live in mmap_region()? What happens with MAP_FIXED, when there is > an underlying vma? i.e. an MAP_FIXED will, I think, bypass the intended > check. For example, we had "c" above: > > c) mmap(PROT_READ); > mprotect(PROT_READ|PROT_EXEC); // fails > > But this would allow another case: > > e) addr = mmap(..., PROT_READ, ...); > mmap(addr, ..., PROT_READ | PROT_EXEC, MAP_FIXED, ...); // passes I can move the check into mmap_region() but it won't fix the MAP_FIXED example that you showed here. mmap_region() calls do_mas_munmap(..) which will unmap overlapping regions. However the `vma` for the 'old' region is not kept around, and a new vma will be allocated later on "vma = vm_area_alloc(mm);", and the vm_flags are just set to what is passed into mmap_region(), so map_deny_write_exec(vma, vm_flags) will just be as good as passing NULL. It's possible to save the vm_flags from the region that is unmapped, but Catalin suggested it might be better if that is part of a later extension, what do you think? > > > > addr = mmap_region(file, addr, len, vm_flags, pgoff, uf); > > if (!IS_ERR_VALUE(addr) && > > ((vm_flags & VM_LOCKED) || > > diff --git a/mm/mprotect.c b/mm/mprotect.c > > index 8d770855b591..af71ef0788fd 100644 > > --- a/mm/mprotect.c > > +++ b/mm/mprotect.c > > @@ -766,6 +766,11 @@ static int do_mprotect_pkey(unsigned long start, size_t len, > > break; > > } > > > > + if (map_deny_write_exec(vma, newflags)) { > > + error = -EACCES; > > + goto out; > > + } > > + > > This looks like the right place. Any rationale for why it's before > arch_validate_flags()?o No big justification, it's just after the VM_ACCESS_FLAGS check and is more generic than the architecture specific checks. > > > /* Allow architectures to sanity-check the new flags */ > > if (!arch_validate_flags(newflags)) { > > error = -EINVAL; > > -Kees Thanks for the review and for the rewritten test, I have replaced my commit with the one that you sent. Joey _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel