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 96EE8C7EE21 for ; Thu, 4 May 2023 20:06:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B3DF66B0075; Thu, 4 May 2023 16:06:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AED966B0078; Thu, 4 May 2023 16:06:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9DC686B007B; Thu, 4 May 2023 16:06:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by kanga.kvack.org (Postfix) with ESMTP id 86EAD6B0075 for ; Thu, 4 May 2023 16:06:36 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1683230796; 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: in-reply-to:in-reply-to:references:references; bh=m/qDBDw/nNJdwxgJ/b5PZHY5Zg9oYrRyxLosJRIIGco=; b=N+kfjHupoyBodqWIpES64SJeh560/XEQ34y6NBbnDoTP0Dh8wGn2s/73e9Y+WKss1O2SW1 EeG9roW3AJ2cVXSt8e2lRPsPkJBVctO1DB0xlfzGEAfcHaRQ/bKZAJ6C7uleNoeqBfNS2g PhiVDQc37ebxb1rrefXbGaRP+niy3bE= Received: from mail-qt1-f200.google.com (mail-qt1-f200.google.com [209.85.160.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-201-NGUdQOZFNgiNH6YAIz9vhg-1; Thu, 04 May 2023 16:06:35 -0400 X-MC-Unique: NGUdQOZFNgiNH6YAIz9vhg-1 Received: by mail-qt1-f200.google.com with SMTP id d75a77b69052e-3ef4f29c9d1so1326501cf.0 for ; Thu, 04 May 2023 13:06:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683230794; x=1685822794; h=in-reply-to: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=m/qDBDw/nNJdwxgJ/b5PZHY5Zg9oYrRyxLosJRIIGco=; b=IcnE/77931t3DmG+Xdlu3wMJg8SMswB5qNjIhRQvOJ8HcLw/7QgqrvS2JmbBmiIIbz D2uB5DlktBuvXFEaMQIyHPoku2GSpztNvT1zL+JejbSHT/FUQWTIEvYruOlL8IqboMxA dtdszB+A4T/yd88DwxWa+HAHCSu1XXul9KYzW+1/3PigCMctcDZFZMOaVbd+8HGb+ezE mvfgY+Lj6uh687M4WqFbd9XDe/g0xzhBxpI/i9blLSR0RdVNnZzjGx2pfRqp6NbURB9Y beZ+804nC6bnWAM2vO8pu9V/MeeolosXj1mLIh7lY4JVtIdKrplWY6HUD6P58q+qSiCZ AC1A== X-Gm-Message-State: AC+VfDxlRmmOnbfwbKGC2V0Zc47B4mtEOvDBh3hU4hIA401n8Q+BeOzg L0TtvwdQabHYGZSKGgRRKZ7nN2HFfRKvcKTFiiqSC4+UcsIzgpUHxIhx7n0H5ssqEXTJ6Kpd8tU wV0AbkR+WXjE= X-Received: by 2002:a05:622a:1cb:b0:3f3:726a:6a70 with SMTP id t11-20020a05622a01cb00b003f3726a6a70mr2800146qtw.6.1683230794648; Thu, 04 May 2023 13:06:34 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5Wjc1ftfCKYjSepetDA4oT7sVlLuqF5bHmOjjIBYYM8Ko/PVF9+G1TaNTzwpyb1+uQBGLdBA== X-Received: by 2002:a05:622a:1cb:b0:3f3:726a:6a70 with SMTP id t11-20020a05622a01cb00b003f3726a6a70mr2800119qtw.6.1683230794373; Thu, 04 May 2023 13:06:34 -0700 (PDT) Received: from x1n (bras-base-aurron9127w-grc-40-70-52-229-124.dsl.bell.ca. [70.52.229.124]) by smtp.gmail.com with ESMTPSA id q3-20020ae9e403000000b0074df3f7e14esm39387qkc.67.2023.05.04.13.06.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 04 May 2023 13:06:33 -0700 (PDT) Date: Thu, 4 May 2023 16:06:32 -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: <20230504170942.822147-1-revest@chromium.org> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline 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 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.. 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? 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? 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)? Thanks, -- Peter Xu