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 064D1C77B7A for ; Thu, 1 Jun 2023 23:55:19 +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:To:References:Message-Id:Cc:Date: In-Reply-To:From:Subject:Mime-Version:Reply-To:Content-ID:Content-Description :Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=8SgotI1ztNZKwkZt0EBDOVjVv+GOo70w4t3JZa7wIxc=; b=qGgiO84W7U3Gdj hjOvXujb669ySgFDeo//HkUKnuFMLrHRwhvAPsMWmKu9qomvtf3XrNO1To7VwCwaT0UV8PwIBqNgV YCkRwgisn9e7EzcNvxnWBeMxY9yNwxTVyEEimGFaK1lhiw6LkSOC/RJio2gQwyln8r4PBW6lNcrCv bt58PdaIXVmr4Ke2DpveNdcP6vAj2qxZ86uUkArypobg+aHYXM45mvbiJk5lTfPj8HkrPrWTgAq4q uj9BLM++NiWPU5ZqOJERPnLHngCeo3WhQNbHJxOaP2CCsSon6EHbsF5kdnJeUOmNFLUUwqtSBjj// 8HQdH6UD7d1n8wu/oqeA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1q4s86-005GxZ-19; Thu, 01 Jun 2023 23:54:54 +0000 Received: from mail-oi1-x233.google.com ([2607:f8b0:4864:20::233]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1q4s83-005Gwe-26; Thu, 01 Jun 2023 23:54:52 +0000 Received: by mail-oi1-x233.google.com with SMTP id 5614622812f47-38dec65ab50so1235081b6e.2; Thu, 01 Jun 2023 16:54:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1685663690; x=1688255690; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=uq+xoVGoOBMASX6Qo6F/Chq5PaVghrBgpVyIfFrv3Do=; b=hQ0RCKA9jRCKnGCyO2kN3QTLC3yb+Mdefo52tmuodc7Rt84YU9NlyduoNwqz+Q967d V7uBGj6VWFgr8YM6btVxO0XdtNVoooAp04klqJfE2ZmBUTlaUrv5ESo1tluojxtb/P0b IXsvFxgfg/85GYZ9MIdxPzQ2yHr/de4bqkKek71QIfTGQZKS+sL+6FNopqB/1pl5gZdM 9SlKfIAzGLZNhvxUgWL+XEi7FhwDSsySWQZgNcWM1R6l7k6VA58bq3RnIGKXMDknOFde ITMFH1EZ3IUbIVWsPaSYfWLIZRF8wgeqkPJHfjZqlj6I94YsQOh8SKgp5f7sF92n6NGq pQcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685663690; x=1688255690; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=uq+xoVGoOBMASX6Qo6F/Chq5PaVghrBgpVyIfFrv3Do=; b=IJwxb9I2VwFlpPD/fhjoI531IzccJupYFwG4XT/KRgZqGWOA1El+Ldrrg8rqW5UBp2 TiMb6Zl3tykpuwwVi7S3SxKpS+TK4GyjETi76WU+SidurxE44iC0hZ1YiD/GpL/9h3fj gSstoRhdEdOEzjmaaZlRCCAwA3S8QV3DN+/Oy3r7mEnvYPKMYn91QQv8Ay6idZ8HX6+c XiITVnZcEMo1DXmjydh3LTC7zr9HTb75pLefdZ+Txqz6pgltcha7arnCodV+6Pw5O172 lxksYUuc0+PofiTQY8Q6H1pgGhg7FFsVsNy1QAig4bWfh1Ub2cbfWxUUI5XP1e9mENKW ie1A== X-Gm-Message-State: AC+VfDyxcQRqF9OHA6UOVoPyf11ybOTO3QpMcJmrr8i2zBiMWTHcBpBf kfA9QUgXDjrUlLPH2JSH/cY= X-Google-Smtp-Source: ACHHUZ6FGoT9AAhqdl4GKiokh7jtAU2ufEnyUr4RvYWwArHNvXyiDuy+wWqdSoxg1oPDBs7mS6RMxw== X-Received: by 2002:a54:4604:0:b0:399:55c9:6f20 with SMTP id p4-20020a544604000000b0039955c96f20mr610729oip.52.1685663689890; Thu, 01 Jun 2023 16:54:49 -0700 (PDT) Received: from smtpclient.apple ([66.170.99.95]) by smtp.gmail.com with ESMTPSA id e2-20020a170902d38200b001aafa2e212esm4074977pld.52.2023.06.01.16.54.47 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Jun 2023 16:54:49 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\)) Subject: Re: [PATCH 12/13] x86/jitalloc: prepare to allocate exectuatble memory as ROX From: Nadav Amit In-Reply-To: <68b8160454518387c53508717ba5ed5545ff0283.camel@intel.com> Date: Thu, 1 Jun 2023 16:54:36 -0700 Cc: "kent.overstreet@linux.dev" , Thomas Gleixner , "mcgrof@kernel.org" , "deller@gmx.de" , "netdev@vger.kernel.org" , "davem@davemloft.net" , "linux@armlinux.org.uk" , "linux-mips@vger.kernel.org" , "linuxppc-dev@lists.ozlabs.org" , "hca@linux.ibm.com" , "catalin.marinas@arm.com" , "linux-kernel@vger.kernel.org" , "linux-riscv@lists.infradead.org" , "linux-s390@vger.kernel.org" , "palmer@dabbelt.com" , "chenhuacai@kernel.org" , "mpe@ellerman.id.au" , "x86@kernel.org" , "tsbogend@alpha.franken.de" , "rppt@kernel.org" , "linux-trace-kernel@vger.kernel.org" , "linux-parisc@vger.kernel.org" , "christophe.leroy@csgroup.eu" , "rostedt@goodmis.org" , Will Deacon , "dinguyen@kernel.org" , "naveen.n.rao@linux.ibm.com" , "sparclinux@vger.kernel.org" , "linux-modules@vger.kernel.org" , "bpf@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "song@kernel.org" , "linux-mm@kvack.org" , "loongarch@lists.linux.dev" , Andrew Morton Message-Id: <50D768D7-15BF-43B8-A5FD-220B25595336@gmail.com> References: <20230601101257.530867-1-rppt@kernel.org> <20230601101257.530867-13-rppt@kernel.org> <0f50ac52a5280d924beeb131e6e4717b6ad9fdf7.camel@intel.com> <68b8160454518387c53508717ba5ed5545ff0283.camel@intel.com> To: "Edgecombe, Rick P" X-Mailer: Apple Mail (2.3731.600.7) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230601_165451_711740_2A8F8835 X-CRM114-Status: GOOD ( 21.70 ) 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 > On Jun 1, 2023, at 1:50 PM, Edgecombe, Rick P wrote: > > On Thu, 2023-06-01 at 14:38 -0400, Kent Overstreet wrote: >> On Thu, Jun 01, 2023 at 06:13:44PM +0000, Edgecombe, Rick P wrote: >>>> text_poke() _does_ create a separate RW mapping. >>> >>> Sorry, I meant a separate RW allocation. >> >> Ah yes, that makes sense >> >> >>> >>>> >>>> The thing that sucks about text_poke() is that it always does a >>>> full >>>> TLB >>>> flush, and AFAICT that's not remotely needed. What it really >>>> wants to >>>> be >>>> doing is conceptually just >>>> >>>> kmap_local() >>>> mempcy() >>>> kunmap_loca() >>>> flush_icache(); >>>> >>>> ...except that kmap_local() won't actually create a new mapping >>>> on >>>> non-highmem architectures, so text_poke() open codes it. >>> >>> Text poke creates only a local CPU RW mapping. It's more secure >>> because >>> other threads can't write to it. >> >> *nod*, same as kmap_local > > It's only used and flushed locally, but it is accessible to all CPU's, > right? > >> >>> It also only needs to flush the local core when it's done since >>> it's >>> not using a shared MM. >> >> Ahh! Thanks for that; perhaps the comment in text_poke() about IPIs >> could be a bit clearer. >> >> What is it (if anything) you don't like about text_poke() then? It >> looks >> like it's doing broadly similar things to kmap_local(), so should be >> in the same ballpark from a performance POV? > > The way text_poke() is used here, it is creating a new writable alias > and flushing it for *each* write to the module (like for each write of > an individual relocation, etc). I was just thinking it might warrant > some batching or something. I am not advocating to do so, but if you want to have many efficient writes, perhaps you can just disable CR0.WP. Just saying that if you are about to write all over the memory, text_poke() does not provide too much security for the poking thread. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel