Received: by 2002:a25:ca44:0:0:0:0:0 with SMTP id a65csp838908ybg; Mon, 27 Jul 2020 00:27:23 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz++MWrvbI7KlhpS6G+exr7/T3NIICGqDOAU5IQ6fkdok0k8Fr26vpAmes1W7lBlnGgtdHF X-Received: by 2002:a17:906:eb11:: with SMTP id mb17mr12892302ejb.501.1595834842966; Mon, 27 Jul 2020 00:27:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595834842; cv=none; d=google.com; s=arc-20160816; b=ZiAK/N5NnzJ8bnXdtWv8jYFMkaXIuH5x+CZNjPOE2Y+mR+kFcl9JQbFl88sHaYBdDV vR1rYhYrb6Pt+RAHs/Bi9WXg2lXJP9KoS+tnFvFhjQ9+CWJadTzncHgcogIpaO0COL23 A5QCYQdg3Aczy1XqJWWLj9HjQKwG7fbxOZmOeO6KfbxRfSu9iL/rwr5HvXOGFIuIVNJZ GTT3CdW6uX5V2jo1KTQVhl88grDxz2RY1TmJyKxmzfvsbioYTstpiMCetnAl45B5Z4Py mOOnXy8ITAsmkbfjC1MsSpKV0qCH908ntUBp+wjpmROiXbX4gaao9UXmcAq+/BIJyJlb Tz9A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:date:message-id:subject:references :in-reply-to:cc:to:from; bh=+OoveFfi3eNBeK4VqiNKl82xaUgKTL+k7j/IhM35CGM=; b=U4fnn/n9H88dTp2xHX1FzY247bFqOT3sVMKyrdP2iYtGdCu8FXYI9+75+D31CkLEHR tEs1OcwnV2UVoSakGxQss6cXLHyFdzIhasy8bg65wTdh0AEwNVKgIWZvFlcnOr0PE76n Jv7ihKQWhdozl36pntVo+i57LYmcDQYiW0dNpBH/Qn8+2vG9yv/HS7zmo5eOXH25nKYl kbQlwg++FzwV4XRR8FHD5QHOihI0gGMB9WLURoizo4eiSJcp2HIz3fsYmBAhBtefOPOS URZu6WRW6xMu3772D6WJg/8h+kt3u2OAU1bDc0u45uy4bDEpsWN9Ydrzi8uH0yRWfjLu qz2A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n9si643586edo.79.2020.07.27.00.27.01; Mon, 27 Jul 2020 00:27:22 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726890AbgG0H0r (ORCPT + 99 others); Mon, 27 Jul 2020 03:26:47 -0400 Received: from ozlabs.org ([203.11.71.1]:43153 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726116AbgG0H0r (ORCPT ); Mon, 27 Jul 2020 03:26:47 -0400 Received: by ozlabs.org (Postfix, from userid 1034) id 4BFWZs6fFyz9sTQ; Mon, 27 Jul 2020 17:26:45 +1000 (AEST) From: Michael Ellerman To: Michael Ellerman , Christophe Leroy , Benjamin Herrenschmidt , Paul Mackerras Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org In-Reply-To: References: Subject: Re: [PATCH v2 0/6] powerpc/32s: Allocate modules outside of vmalloc space for STRICT_KERNEL_RWX Message-Id: <159583478807.602200.856546124460688008.b4-ty@ellerman.id.au> Date: Mon, 27 Jul 2020 17:26:45 +1000 (AEST) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 29 Jun 2020 11:15:19 +0000 (UTC), Christophe Leroy wrote: > On book3s32 (hash), exec protection is set per 256Mb segments with NX bit. > Instead of clearing NX bit on vmalloc space when CONFIG_MODULES is selected, > allocate modules in a dedicated segment (0xb0000000-0xbfffffff by default). > This allows to keep exec protection on vmalloc space while allowing exec > on modules. > > v2: > - Removed the two patches that fix ptdump. Will submitted independently > - Only changing the user/kernel boundary for PPC32 now. > - Reordered the patches inside the series. > > [...] Applied to powerpc/next. [1/6] powerpc/lib: Prepare code-patching for modules allocated outside vmalloc space https://git.kernel.org/powerpc/c/ccc8fcf72a6953fbfd6998999d622295f522b952 [2/6] powerpc: Use MODULES_VADDR if defined https://git.kernel.org/powerpc/c/7fbc22ce29931630da200cfc90fe5a454f54a794 [3/6] powerpc/32s: Only leave NX unset on segments used for modules https://git.kernel.org/powerpc/c/c496433197154144c310a17939736bc5c155914d [4/6] powerpc/32: Set user/kernel boundary at TASK_SIZE instead of PAGE_OFFSET https://git.kernel.org/powerpc/c/b6be1bb7f7216b9e9f33f57abe6e3290c0e66bd4 [5/6] powerpc/32s: Kernel space starts at TASK_SIZE https://git.kernel.org/powerpc/c/f1a1f7a15eb0e13b84791ff2738b84e414501718 [6/6] powerpc/32s: Use dedicated segment for modules with STRICT_KERNEL_RWX https://git.kernel.org/powerpc/c/6ca055322da8fe25ff9ac50db6f3b7b59b6f961c cheers