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 2309AC77B75 for ; Mon, 8 May 2023 01:29:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 72CB36B0078; Sun, 7 May 2023 21:29:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6DC6A6B007D; Sun, 7 May 2023 21:29:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5CB146B007E; Sun, 7 May 2023 21:29:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 4E6B36B0078 for ; Sun, 7 May 2023 21:29:32 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 12D17806B6 for ; Mon, 8 May 2023 01:29:32 +0000 (UTC) X-FDA: 80765355384.15.565BD51 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf09.hostedemail.com (Postfix) with ESMTP id E7144140003 for ; Mon, 8 May 2023 01:29:28 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=CZdoz9+v; dmarc=pass (policy=none) header.from=redhat.com; spf=temperror (imf09.hostedemail.com: error in processing during lookup of peterx@redhat.com: DNS error) smtp.mailfrom=peterx@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1683509370; 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=ZQFLJyFxQe/WmXiJ0plNddWag3eZBQCk8VARawBfOrk=; b=bijKqva+4PSBicUEzWt7lOksjwlX4NR4Fv5Aqf6sRtm7S2Ym9nuRdyFa8XlsurJbpi+GXH eTAY2MEU5iPw1eel/KURPvs+C6du8YvX0Y8Pk4y4iOowgkU4udrPWJFPXPVtmJN1jkc/Oj toiB0vU8YgsyyBDDgImIY1oD9z/Fa4U= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=CZdoz9+v; dmarc=pass (policy=none) header.from=redhat.com; spf=temperror (imf09.hostedemail.com: error in processing during lookup of peterx@redhat.com: DNS error) smtp.mailfrom=peterx@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1683509370; a=rsa-sha256; cv=none; b=fPZD2HKITo9nfSIYfbhO5eSu1natYmMZO5DxjG1fTgptYk5XlheR+bIF+htiF/a3257SbY Aibl7TV3RZCl2AmPIrtH0rU9PulJfx+FkofAprnMhaOihL26Lt3lQq4lbLAM9uGVlxfBh/ bIzmm71GI9AseWV5IaUK7Y0t78SYSCU= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1683509368; 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=ZQFLJyFxQe/WmXiJ0plNddWag3eZBQCk8VARawBfOrk=; b=CZdoz9+vKALoF33xKOHcTD0tBWgXBkmHc43I0mWCEEVnv7XRp4BXH6wqgDGqb2CFN4bz6F oKuNiADQsGTKGGWfOtH6igibxnP2KKkPv1rGeOztvGuitSXD0Lp3d1r1TuWMOiD5sReWuv TUObjBbw5AUed+5pqtuWCMKmHgxlrzs= Received: from mail-pf1-f198.google.com (mail-pf1-f198.google.com [209.85.210.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-168-PVtlcb1VPmupCo2LdH-d6A-1; Sun, 07 May 2023 21:29:26 -0400 X-MC-Unique: PVtlcb1VPmupCo2LdH-d6A-1 Received: by mail-pf1-f198.google.com with SMTP id d2e1a72fcca58-643b9ebe42fso419150b3a.0 for ; Sun, 07 May 2023 18:29:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683509365; x=1686101365; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ZQFLJyFxQe/WmXiJ0plNddWag3eZBQCk8VARawBfOrk=; b=FDdsHjoo23yOmrSybagXM/GTHzQ53EtQ9fxz7y7pGF6yYhEyp/lZTQ9HSWNSHLO5a5 dvexnv4qk8AaeOvYpR+M9sEeb2XJvskjeEFknqVkjlk3UwinKY44SegXYtHRAs+wxEPc Z57cn8YtlVIWeNiIgpbfm82du/uLgQo3B0lULmIGqXG/cGinOh2tHIAqxgzCyCj8yWtT 4Giza7C34WCdysVllCa0dE8M+9e+4eaE5dd4U7XIQcUp21OLDMuRbd+/Gqb5KCNw5HN0 nflue0t4shzDHpqJX7bLr6ji502+DNjf5PpEGT0s9esx532z/fLPr3sUi8MiEGNcLoo7 QH7A== X-Gm-Message-State: AC+VfDzoAtJ6V2iIhi7mhrBT48OSiI7I8JH/2Si/FAlY/zZmFPOx49iz yMM7E+yr9afF+YSWZMoixD4WvY2ocTud5c2DyXPsn1y5K96/GfDkfiMZsupcdXGzy4hKdUasWHb 2vLNJ7pDLTTnit9tc3ts= X-Received: by 2002:a17:902:db0a:b0:19a:a815:2877 with SMTP id m10-20020a170902db0a00b0019aa8152877mr10591245plx.6.1683509365104; Sun, 07 May 2023 18:29:25 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ6ynB3ZV1UTQiGDzxNyvKwQ+Ch2kNH77iV4wRFTKDoxgblCq6adzXcf16CYkbTEHVwKWxrbBQ== X-Received: by 2002:a17:902:db0a:b0:19a:a815:2877 with SMTP id m10-20020a170902db0a00b0019aa8152877mr10591227plx.6.1683509364792; Sun, 07 May 2023 18:29:24 -0700 (PDT) Received: from x1n ([64.114.255.114]) by smtp.gmail.com with ESMTPSA id z14-20020a1709028f8e00b001aaf6353736sm5785489plo.80.2023.05.07.18.29.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 07 May 2023 18:29:23 -0700 (PDT) Date: Sun, 7 May 2023 21:29:23 -0400 From: Peter Xu To: Florent Revest Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, catalin.marinas@arm.com, anshuman.khandual@arm.com, joey.gouly@arm.com, mhocko@suse.com, keescook@chromium.org, david@redhat.com, izbyshev@ispras.ru, nd@arm.com, broonie@kernel.org, szabolcs.nagy@arm.com Subject: Re: [PATCH 0/4] MDWE without inheritance Message-ID: References: <20230504170942.822147-1-revest@chromium.org> MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Stat-Signature: 4r6it7pae3mun1bzani585cxfniyadws X-Rspam-User: X-Rspamd-Queue-Id: E7144140003 X-Rspamd-Server: rspam07 X-HE-Tag: 1683509368-652615 X-HE-Meta: U2FsdGVkX19lKWGg3HCdIM1cI8IJibkMRbfTkuMAHFC+CawKsmUvdivAGAcjn7JScir+JJ4aWIGu1XWhQy/0CGgiglu1brTSJ20wkYwVkYUa3i4Ow97kBjYYfAxvMXo/Op6dVe9pT3ZgUmtqNgVFqxyDCNkhGIV6TL3q81JDV1uSrLWYPrsMU5CtrNO3iRJS3Hah0URkZZlew2OS3eUQQLYhuw1EerUNnF2PwZgvry7WUIiR0NnZiFOezUdl6nZxyiUjgMyLB9LZaClpCxU8VkTo7EhmkPXOfGVnBpoQoccuWdUdHnMlp8tePbk9R2TEdm2r3wXvY1L0oOEivNYefhNTN9uxR3pMBT9ejgLGw/0n2wOrltILOg7LTnFmL+q1eA/4ZvQD7LtzyEMIR2Yd6sbwdzdbqpLW+tsrnW0P7fu2/QYHXk1rq5uYrIUi9ozdKh1b0CG2wrOSfEDxED5ZUDd3kZ9Kg6GGLxOwLoZKVPmr01ajWKRmeaEFv+rgu165fVzgi3uTfcFY9SX80Y2zc2u+jZTVk+mzOES++SUqjLGe4ya9hRymoP/gxacnuV+BPkq6dZsozKGtJvVbrmSC9PfdluqjtBOWf0VvknLbttQXUJa9zkuwjg6qlw42YI2Z90bn0BuW+0t9J52QSewogbC1yZEPhniJACMjedoxeRW1x9GdDbnYT4i8m3mSCxdFulSL47pjlW+XbqRtyrCd04twGkXmSXE1vGG5vSEQTzZJig0JfyWA495hWZc6rGDUyTdqh0T1AAB/mpFj7hTyqZrAesKlc0OlIItuSCcxuttSrl2aCR5NNjlkNYDLfGxIUiqw74OFmTuvMCXs+4EhaCxTeRtFXmQscPbohK+GjssuzBldRQedVePhpVo+9lkEMz5dLOSiFRPCFfubfk2r1N4PBzlaaH/bqa5pgx5V++RqmIIMZdivguh4A/kqdGHNBEbOEaHxTpY8QEQJ4sO 5Im02ro8 PFJha9YNzqRLVn70pIctIBrQuqlu/h4k7BMJjukQBZ521i7Fa1o/PXyVhJq8g/VE1ip4TGfpL2Pbbd5RfrCNIcD3Rs5UxQzlzBxaAz1YnE6Rumkux7hUIrB52uZFuBTNfdLbRqShXgoxFhcGw9l4aS3saBy2G+hI/2pXjqQZWsNlaR7aeHxRNhUD2zmn/GcqgB86V8guByzqX0cLQsrYeAE7le/NIFCFPG9X65LwC7Obbs1UYjfLF3ULN5uSV7ZjHNkV9p+I8DvLS0rkR6YoLt84asgoxtcKkOZlVv3TC9w562mTxSoW5VOglAQC8bzd06Ph3rQhXNzy1lQL/EQewlQW711cDOjBvga0nJtytkIGDCc+sRN0ArlI3XiHKTvGBveGgnUlwXjX7NUQ= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000064, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, May 05, 2023 at 06:42:08PM +0200, Florent Revest wrote: > On Thu, May 4, 2023 at 10:06 PM Peter Xu wrote: > > > > On Thu, May 04, 2023 at 07:09:38PM +0200, Florent Revest wrote: > > > Joey recently introduced a Memory-Deny-Write-Executable (MDWE) prctl which tags > > > current with a flag that prevents pages that were previously not executable from > > > becoming executable. > > > This tag always gets inherited by children tasks. (it's in MMF_INIT_MASK) > > > > > > At Google, we've been using a somewhat similar downstream patch for a few years > > > now. To make the adoption of this feature easier, we've had it support a mode in > > > which the W^X flag does not propagate to children. For example, this is handy if > > > a C process which wants W^X protection suspects it could start children > > > processes that would use a JIT. > > > > > > I'd like to align our features with the upstream prctl. This series proposes a > > > new NO_INHERIT flag to the MDWE prctl to make this kind of adoption easier. It > > > sets a different flag in current that is not in MMF_INIT_MASK and which does not > > > propagate. > > > > I don't think I have enough context, so sorry if I'm going to ask a naive > > question.. > > Not at all! :) You're absolutely right, it's important to address these points. > > > I can understand how current MDWE helps on not allowing any modifi-able > > content from becoming executable. How could NO_INHERIT help if it won't > > inherit and not in MMF_INIT_MASK? > > The way I see it, enabling MDWE is just a small step towards hardening > a binary anyway. It can possibly make exploitation a bit harder in the > case where the attacker has _just_: a write primitive they can use to > write a shellcode somewhere and a primitive to make that page > executable later. It's a fairly narrow protection already and I think > it only really helps as part of a broader "defense in depth" strategy. > > > IIUC it means the restriction will only apply to the current process. Then > > I assume the process can escape from this rule simply by a fork(). If so, > > what's the point to protect at all? > > If we assume enough control from the attacker, then MDWE is already > useless since it can be bypassed by writing to a file and then > mmapping that file with PROT_EXEC. I think that's a good example of > how "perfect can be the enemy of good" in security hardening. MDWE > isn't a silver-bullet but it's a cheap trick and it makes a small dent > in reducing the attack surface so it seems worth having anyway ? > > But indeed, to address your question, if you choose to use this > NO_INHERIT flag: you're no longer protected if the attacker can fork() > as part of their exploitation. I think it's been a useful trade-off > for our internal users since, on the other hand, it also makes > adoption a lot easier: our C++ services developers can trivially opt > into a potpourri of hardening features without having to think too > much about how they work under-the-hood. The default behavior has been > to use a NO_INHERIT strategy so users don't get bad surprises the day > when they try to spawn a JITted subcommand. In the meantime, their C++ > service still gets a little bit of extra protection. > > > And, what's the difference of this comparing to disabling MDWE after being > > enabled (which seems to be forbidden for now, but it seems fork() can play > > a similar role of disabling it)? > > That would be functionally somewhat similar, yes. I think it mostly > comes down to ease of adoption. I imagine that users who would opt > into NO_INHERIT are those who are interested in MDWE for the binary > they are writing but aren't 100% confident in what subprocesses they > will run and so they don't have to think about disabling it after > every fork. Okay, that makes sense to me. Thanks. Since the original MDWE was for systemd, I'm wondering what will happen if some program like what you said is invoked by systemd and with MDWE enabled already. Currently in your patch IIUC MDWE_NO_INHERIT will fail directly on MDWE enabled process, but then it makes me think whether it makes more sense to allow converting MDWE->MDWE_NO_INHERIT in this case. It seems to provide a most broad coverage on system daemons using MDWE starting from systemd initial process, meanwhile allows specific daemons to fork into anything like a JIT process so it can make itself NO_INHERIT. Attackers won't leverage this because MDWE_NO_INHERIT also means MDWE enabled. -- Peter Xu