Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp3952743imm; Mon, 11 Jun 2018 04:43:00 -0700 (PDT) X-Google-Smtp-Source: ADUXVKKZIk+xJVxusTwvwRvhxYrnvnH0cxlx3TQVShsYVs/dPYyc5oywSTjy6/LUMtY/Y5ywkc82 X-Received: by 2002:a63:b609:: with SMTP id j9-v6mr14654576pgf.335.1528717380412; Mon, 11 Jun 2018 04:43:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528717380; cv=none; d=google.com; s=arc-20160816; b=bomhHj72Qd1GoKTPk5Zej+ii7e460X6txHhnlNTIdjPRHOgiAGvk09FaqF1U38obNg xFoNwFNIMR9qE2jXSCdO9xP6uengJKtBiDkmVttuGZ7jl0Oi3Km/I7qoLGn30ICsiXQo xE68RgOyezCmMXV7SQEdCvoU0TiuoiqYT1vs+bxHXDrjknCaytHOGwk/3MoQlLDiIYqZ eMTasO4qyQd2VR9pU8CsuDQd1IDMvlPCZdAAEennKOjFxb3WOCc4Zk4848ZlT5CRyx+9 iWjpN2jY2u/UC9lSu0sh/REhcyiKEpjZSjuLtzprPkKzdLJplmfDArxjTrjHJwOlOGYb eyjA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=4b7DQe9PCVnuyI9DVVOip4009/b7jx4de8NU3I/2cqo=; b=qSKHvz+fPrU6mUL4k4npa+5lFneGZY1FNtERwZ7csU6HfrCKSj7sscx2DZxZWNCGqB G/gXYJLJCPTSBoxiQcFr0uh/tRETku1eU99FjEETo3o3i1/vzCsZkXzbdOQFm+Tln91s BIV9rQ0bKn6AvTQ8EQYwsng8wZdCbnqc1MMa/u6JPcIciJL4aEUP4eywg0Mu7nSB8oRE QI6dM4iwirbaj/fIhX8XIPkwki8sGa4s9EDig+jhSS3dBwZjygPNVgTHOWIY1Ps9j6/p yQZCsjPNv9ctKAYvtbwXXu0rUwJFn++Xt8db8RmNae02lkusSJslTgAF3zmpkAoiYzRF HTaA== 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 g4-v6si16951989pgs.322.2018.06.11.04.42.46; Mon, 11 Jun 2018 04:43:00 -0700 (PDT) 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 S932929AbeFKLlY (ORCPT + 99 others); Mon, 11 Jun 2018 07:41:24 -0400 Received: from mx2.suse.de ([195.135.220.15]:39075 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932841AbeFKLlX (ORCPT ); Mon, 11 Jun 2018 07:41:23 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (charybdis-ext-too.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id C401AABCC; Mon, 11 Jun 2018 11:41:21 +0000 (UTC) Date: Mon, 11 Jun 2018 13:41:21 +0200 From: Petr Mladek To: Miroslav Benes Cc: jikos@kernel.org, jpoimboe@redhat.com, jeyu@kernel.org, live-patching@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/3] livepatch: Deny the patched modules to be removed Message-ID: <20180611114121.2u7wt6d6xu2cm6it@pathway.suse.cz> References: <20180607092949.1706-1-mbenes@suse.cz> <20180607092949.1706-3-mbenes@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180607092949.1706-3-mbenes@suse.cz> User-Agent: NeoMutt/20170421 (1.8.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 2018-06-07 11:29:48, Miroslav Benes wrote: > We decided to deny the patched modules to be removed. If it proves to be > a major drawback for users, we can still implement a different approach. > > The reference of a patched module has to be taken regardless of a > patch's state. Thus it is not taken and dropped in enable/disable paths, > but in register/unregister paths. > --- a/kernel/livepatch/core.c > +++ b/kernel/livepatch/core.c > @@ -739,6 +746,14 @@ static int klp_init_object_loaded(struct klp_patch *patch, > } > } > > + /* > + * Do not allow patched modules to be removed. > + * > + * All callers of klp_init_object_loaded() set obj->mod. > + */ > + if (klp_is_module(obj) && !try_module_get(obj->mod)) > + return -ENODEV; > + > return 0; > } This looks strange. We try to take the reference after we do all actions needed for a loaded module. There is nothing that would prevent obj->mod to get into the going state. Note that it was safe (except for the relocated symbols) because the module was not able to really go until it called klp_module_going(). But you removed this last break by the 3rd patch. I suggest another approach: I would rename klp_find_object_module() to klp_get_object_module() and get the reference there. Note that it should be fine to call it later in klp_init_object() (before klp_init_object_loaded()). This would solve klp_init_patch(). We will also need to get the reference in klp_module_coming(). It can be called anywhere there. If it fails, we will block loading the module. Note that the mod->klp_alive logic will still be necessary. It solves various races when both the patch and the patched module are loaded in parallel. Sigh, this also means that we still could call klp_init_object_loaded() and apply reloacations even when the patched module fails to loaded later from other reasons. This means that this approach does not solve the original problem completely. I wonder how complicated would be the arch-specific part that would clean up relocations when the module is unloaded. Best Regards, Petr