Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2505027imu; Thu, 17 Jan 2019 15:47:03 -0800 (PST) X-Google-Smtp-Source: ALg8bN5cxlGanz3ohZ5HhR+5/kT0uQNq7HUHZhSLSXosrwC9HmSjRE83ODuAqPHmzcV6NGc4qE30 X-Received: by 2002:a62:4bcf:: with SMTP id d76mr17674406pfj.170.1547768823643; Thu, 17 Jan 2019 15:47:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547768823; cv=none; d=google.com; s=arc-20160816; b=ycxcdiGBUbyXKDiRFcyoOIb8aOd9D1q5UrOtEhp2NjoWRxxMJtBbLYS/n9PXXPBo7f v3nku7teEUco4JJQlQ4tV19eyQvdxSPSBsywQzY5j1+BaAzLjkG69pk97c7mAfeka7B3 AAtJyuzFz30deecLBEpZocX7apD2na6lffAlCHta11aHv2WBeqMrHQn338nym50JGBKj ldiqPlTjLxDoGlZ/6YB0WmB0zDopJ3s2gJRYUELVRWPjBgzCAeSSl8SpUZ2fcbVYOkOR 0AZ9Qgy0bNNf6Jc17IKhNPW2JqFMfigFzm7oXkwBf7ntbV37G3PToHVcRsQZxVrH0v4n CCsw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=Iwxi6k9gsSNMnMm5j1d0vf4v98YR+wymuOCzB6WDIz8=; b=cIR2cwxgRVRSus/vbejReVACLYDvr7XrCPEjVUX9CR6lGPIxTVlarseJ2WzBWDF+wH EYCqRCgOp9vNf5sDFRHS5EObjQUHk2yP7LPFH2m5CGmjI5jhaDJpruDBfnabMoejsb+v dZRxdxHgO/GWlf6hqvjKtV2hemDGdx7XSeapSdg9lSfXlqUqX+Tnq2m2jU50lcivTNTa EkApqGbjWA6HMR/k7nrf7ksLRUvb602gA7nf9i3ST5qcF3RG1MG5wE5ZqGQ2o+uRVfH+ jdV3g780CZg/W0tM5u45qHCz4BsbVrKc+LI6nFk5hzfGtTFgO96aHdwqDibGzxcJZGfJ 5bsA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v17si3070558pga.566.2019.01.17.15.46.44; Thu, 17 Jan 2019 15:47:03 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727081AbfAQXp1 (ORCPT + 99 others); Thu, 17 Jan 2019 18:45:27 -0500 Received: from terminus.zytor.com ([198.137.202.136]:35287 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726008AbfAQXp1 (ORCPT ); Thu, 17 Jan 2019 18:45:27 -0500 Received: from hanvin-mobl2.amr.corp.intel.com (fmdmzpr04-ext.fm.intel.com [192.55.54.39]) (authenticated bits=0) by mail.zytor.com (8.15.2/8.15.2) with ESMTPSA id x0HNink3948140 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Thu, 17 Jan 2019 15:44:50 -0800 Subject: Re: [PATCH 17/17] module: Prevent module removal racing with text_poke() To: Nadav Amit , Masami Hiramatsu Cc: Rick Edgecombe , Andy Lutomirski , Ingo Molnar , Linux List Kernel Mailing , the arch/x86 maintainers , Thomas Gleixner , Borislav Petkov , Dave Hansen , Peter Zijlstra , Damian Tometzki , linux-integrity , LSM List , Andrew Morton , Kernel Hardening , Linux-MM , Will Deacon , Ard Biesheuvel , "kristen@linux.intel.com" , "deneen.t.dock@intel.com" References: <20190117003259.23141-1-rick.p.edgecombe@intel.com> <20190117003259.23141-18-rick.p.edgecombe@intel.com> <20190117165422.d33d1af83db8716e24960a3c@kernel.org> From: "H. Peter Anvin" Message-ID: Date: Thu, 17 Jan 2019 15:44:48 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 1/17/19 10:07 AM, Nadav Amit wrote: >> On Jan 16, 2019, at 11:54 PM, Masami Hiramatsu wrote: >> >> On Wed, 16 Jan 2019 16:32:59 -0800 >> Rick Edgecombe wrote: >> >>> From: Nadav Amit >>> >>> It seems dangerous to allow code modifications to take place >>> concurrently with module unloading. So take the text_mutex while the >>> memory of the module is freed. >> >> At that point, since the module itself is removed from module list, >> it seems no actual harm. Or would you have any concern? > > So it appears that you are right and all the users of text_poke() and > text_poke_bp() do install module notifiers, and remove the module from their > internal data structure when they are done (*). As long as they prevent > text_poke*() to be called concurrently (e.g., using jump_label_lock()), > everything is fine. > > Having said that, the question is whether you “trust” text_poke*() users to > do so. text_poke() description does not day explicitly that you need to > prevent modules from being removed. > > What do you say? > Please make it explicit. -hpa