Received: by 10.223.185.116 with SMTP id b49csp2251386wrg; Thu, 22 Feb 2018 10:30:43 -0800 (PST) X-Google-Smtp-Source: AH8x225ZcuSf9U1VipsQPKX+f7mU++EDSAkz2M6IvOvWlqWtPuQ+sKZSWCKwUi9FeRuTjm6RzHig X-Received: by 2002:a17:902:46a:: with SMTP id 97-v6mr7282212ple.96.1519324243846; Thu, 22 Feb 2018 10:30:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519324243; cv=none; d=google.com; s=arc-20160816; b=bHNRykBHOHgHj96bjh92QVCeLlH6vAHgiP/QcVnMU9IGUADJefX9J9J2ANAWrBkLPP 3GsDoycqfVtZOXjsW1tE+bXpFJhLO7X1vxj74iLC0DwU9shZm8OZA57+JuZ+nJr1d0V3 s/nwgNUR2L3n94C0exuwCKOlK0sRoIxqMuZb5tX1c9bXEq7FzemsHgKy2bU72U+4K6Oa fy9ka2by52y4Xs/1NgFkmC7Hbml6jnIdJNNELvS5g/PorUrHXgmbblfuMLBcjacCl/8U VGqURSkhf2xr26d+6FxBAUkWe7Hq4hT0akDCu+rMC/VFTOkDtbTkpKMjio3j7panWhUC bKIw== 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:references:cc:to:from:subject:arc-authentication-results; bh=TlahBmqwp9e+Da/sUZyyEUSsZR+kiZly4UjCXOpNmLg=; b=r5Mqn7oLDg7+MBacCedYQEj6NaToEd8ZHQSbUxXkTiRpbUe0XALDC46kSoZrQsaYd8 l5Et0nHg9L68GNP7jAOclvYTcth3S4DCKotlAgseSp1s02ECu4qygfhGhu2qd/OSn804 wSpwxcfnJkSFhWiNvI2lXI/EhH0eWqmsdBTBxP8Ww2eUpjIuDisO98mG97NGsas6NF2r +bOPZ15S3QF1ZcAJHJJAlxRyeFCkFQBIn4qDSkAvI7j+Lniua/jx1prEahx0yfExtkoJ v4vTYv92OcmeGaCDJJ6/UOHdiTVmxOuew/IAvgm0gpeb/YIqEHsl71LW8Qf6wcnXPkcL 5ymQ== 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 f1si427343pfn.167.2018.02.22.10.30.28; Thu, 22 Feb 2018 10:30:43 -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 S933742AbeBVS27 (ORCPT + 99 others); Thu, 22 Feb 2018 13:28:59 -0500 Received: from lhrrgout.huawei.com ([194.213.3.17]:27197 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S933541AbeBVS26 (ORCPT ); Thu, 22 Feb 2018 13:28:58 -0500 Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id C840B7C69714; Thu, 22 Feb 2018 18:28:53 +0000 (GMT) Received: from [10.122.225.51] (10.122.225.51) by smtpsuk.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 22 Feb 2018 18:28:54 +0000 Subject: Re: [PATCH 2/6] genalloc: selftest From: Igor Stoppa To: Kees Cook CC: Matthew Wilcox , Randy Dunlap , Jonathan Corbet , Michal Hocko , Laura Abbott , Jerome Glisse , Christoph Hellwig , "Christoph Lameter" , linux-security-module , Linux-MM , LKML , Kernel Hardening References: <20180212165301.17933-1-igor.stoppa@huawei.com> <20180212165301.17933-3-igor.stoppa@huawei.com> Message-ID: <81471cf6-5a27-6e8c-ac7c-e7c4cc35d410@huawei.com> Date: Thu, 22 Feb 2018 20:28:30 +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: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit 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 22/02/18 11:14, Igor Stoppa wrote: > > > On 22/02/18 00:28, Kees Cook wrote: >> On Tue, Feb 20, 2018 at 8:59 AM, Igor Stoppa wrote: >>> >>> >>> On 13/02/18 01:50, Kees Cook wrote: >>>> On Mon, Feb 12, 2018 at 8:52 AM, Igor Stoppa wrote: > > [...] > >>>>> + genalloc_selftest(); >>>> >>>> I wonder if it's possible to make this module-loadable instead? That >>>> way it could be built and tested separately. >>> >>> In my case modules are not an option. >>> Of course it could be still built in, but what is the real gain? >> >> The gain for it being a module is that it can be loaded and tested >> separately from the final kernel image and module collection. For >> example, Chrome OS builds lots of debugging test modules but doesn't >> include them on the final image. They're only used for testing, and >> can be separate from the kernel and "production" modules. > > ok I started to turn this into a module, but after all it doesn't seem like it would give any real advantage, compared to the current implementation. This testing is meant to catch bugs in memory management as early as possible in the boot phase, before users of genalloc start to fail in mysterious ways. This includes, but is not limited to: MCE on x86, uncached pages provider on arm64, dma on arm. Should genalloc fail, it's highly unlikely that the test rig would even reach the point where it can load a module and run it, even if it is located in initrd. The test would not be run, precisely at the moment where its output would be needed the most, leaving a crash log that is hard to debug because of memory corruption. I do not know how Chrome OS builds are organized, but I imagine that probably there is a separate test build, where options like lockdep, ubsan, etc. are enabled. All options that cannot be left enabled in a production kernel, but are very useful for sanity checks and require a separate build. Genalloc testing should be added there, rather than in a module, imho. -- igor