Received: by 10.223.185.116 with SMTP id b49csp5028836wrg; Wed, 7 Mar 2018 05:20:17 -0800 (PST) X-Google-Smtp-Source: AG47ELvgzqghi1+teXemLPodpOuJ6QnMAp3EqdpJ/ytvFEhHt/IYECyKvsywQ4Dg41WnWUgdx8Yz X-Received: by 2002:a17:902:3283:: with SMTP id z3-v6mr20954764plb.118.1520428817021; Wed, 07 Mar 2018 05:20:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520428816; cv=none; d=google.com; s=arc-20160816; b=Fwifzr09eJANnoNbolknCRKcpgVVOxFWgkorUbaPBylgfIfoIaTkQukmPyOU3UnBNx nAAyU2Z5GDuaxTEmfBAw0ofv9tCFbksqzY2hsClEAWOMomCj3s6D/v/rdTixPQ3mbJmT ELFN3XCVFJUXCnpwVMzb06/3djCt6Wi+Ml2tlmjbE3+pFuIhA8HR1pJFSmhJJGSMH1kR d+Mqi6tnRjwuhkyco8+9KeyLaC4P11Xfj9ljcq/bQWbZ91ssTQmDTY7eGe/CX3WmmHCP G+HoHg9RJQ4IIRRwesTzqgLuM4LN+8fHVR4gQVYV4KAz30nJcTOEsoas30yfLalwqpie /1vg== 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:arc-authentication-results; bh=kl+VA5wFf4VVXJhTK1TvzoG0Yn7hB7AsS5rYZfUPrmA=; b=jYqiPfENBgytGvs47+KvHoweiJIqbsQOMS1GJk9X5jLkGJ1eRVrHMYuG8ycCba2bvE TuUWhJcJtHo9MeuAzhhC5M7rEMAGbnvljqycMPbjSCfTRdbdX2pkDGoGhejcN8bUG/Sc 4sWYBOgy1/bPtceU0Xrhe/BxZPpFIGknisk/VvRP3PG3Baw/JCHbdM/2pfqZ7a0PIfdl e4bvGcXj8SnMxMe4yksPeJsJ2xSSziZV/7VA1Wy1cpTkWBckvhC6etm19MWUWm0mHCNp SuhO+bDp2IGjGJk6EsIsDCKseSUrNpIMv5lrgDZYUXUG/oMe5JHr+udsBgJY3hY8JRSn dfyA== 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 l6si4173485pgq.550.2018.03.07.05.20.02; Wed, 07 Mar 2018 05:20:16 -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 S1754480AbeCGNTE (ORCPT + 99 others); Wed, 7 Mar 2018 08:19:04 -0500 Received: from lhrrgout.huawei.com ([194.213.3.17]:28563 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751204AbeCGNTB (ORCPT ); Wed, 7 Mar 2018 08:19:01 -0500 Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 0962AEEEF29FE; Wed, 7 Mar 2018 13:18:58 +0000 (GMT) Received: from [10.122.225.51] (10.122.225.51) by smtpsuk.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.382.0; Wed, 7 Mar 2018 13:18:54 +0000 Subject: Re: [PATCH 6/7] lkdtm: crash on overwriting protected pmalloc var To: J Freyensee , , , , CC: , , , , References: <20180228200620.30026-1-igor.stoppa@huawei.com> <20180228200620.30026-7-igor.stoppa@huawei.com> <1723ee8d-c89e-0704-c2c3-254eda39dc8b@gmail.com> From: Igor Stoppa Message-ID: <6378e63e-174f-642e-d319-1d121b74d3d7@huawei.com> Date: Wed, 7 Mar 2018 15:18:16 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <1723ee8d-c89e-0704-c2c3-254eda39dc8b@gmail.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [10.122.225.51] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/03/18 19:20, J Freyensee wrote: > On 2/28/18 12:06 PM, Igor Stoppa wrote: [...] >> void __init lkdtm_perms_init(void); >> void lkdtm_WRITE_RO(void); >> void lkdtm_WRITE_RO_AFTER_INIT(void); >> +void lkdtm_WRITE_RO_PMALLOC(void); > > Does this need some sort of #ifdef too? Not strictly. It's just a function declaration. As long as it is not used, the linker will not complain. The #ifdef placed around the use and definition is sufficient, from a correctness perspective. But it's a different question if there is any standard in linux about hiding also the declaration. I am not very fond of #ifdefs, so when I can I try to avoid them. >> + pr_info("attempting bad pmalloc write at %p\n", i); >> + *i = 0; > > OK, now I'm on the right version of this patch series, same comment > applies.  I don't get the local *i assignment at the end of the > function, but seems harmless. Because that's the whole point of the function: prove that pmalloc protection works (see the message in the pr_info one line above). The function is supposed to do: * create a pool * allocate memory from it * protect it * try to alter it (and crash) *i = 0; performs the last step -- igor