Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp6233298ybc; Wed, 27 Nov 2019 17:52:14 -0800 (PST) X-Google-Smtp-Source: APXvYqzfBw/pWEuQ75eBv//a778TwLFjzFP4OtC5jN+zMlFmQdl7gkajj0I3kxlSHe/ziGFyxSHO X-Received: by 2002:a17:906:3798:: with SMTP id n24mr8766406ejc.15.1574905933911; Wed, 27 Nov 2019 17:52:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574905933; cv=none; d=google.com; s=arc-20160816; b=JejsSs3nlnZaqY5sQolGx2ZUqxMlgd26a1drx3mWhHmKTemCLl5NvltwvVul9ff1M+ uX/wZvWSmuDV/c4ZT0KlOaZO9fioYGzVhiwJQP0fTjYLXj4a0INBelDDrg2Zvq0x5kQ8 HulbtI2RaLV7E5vkEX+bwgKtYORehCwz8Y92YEuu4aITcrxdLtdIl8N/4fT8VuLOZEhr LFqDjGCciT4W05Z2WK1umAzsc85q25Lrs7VwumtGF9Z0zp2+w6IgVjAQhVZ6Tv6FPmVw DTjKoG7sCb5AyaOfUbRJj46RHTr1kG5k1YjMiInF56trTxO+VboHuhfsmL1v9QGnsOON QM3g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=VR2/v9AWTifanIT/eMBWdlLjcrylXavL2K2N3+XyWKM=; b=cIlgqkNwCVEDrEmnVIdRROgn//b4dgeghgGloZO6ut/JZEcqxg1vDJuPzdk+gFJhZC AwisNRggd3w0eRrFuO8dPEnzWlUafJcs2P3IfLwHsWyWbNUjfPyIlaVLSHcitRlnxzpz 6HTo3rZqZU1/ohwtccx1MfCoDDP/ngjBoThu+AaOZ2o7hdazZoR1NO8VSSqE9h9qNYiQ ag757BURxTsCxtSqhiGGqu1YybqWqO5SNc+ovor0Y33e02t+bDSVQ9TrPK3IVgJJNhqS euyW8GIlxcWKnY1H7/uISqHhw3S2gc7eoL4gXWYRS7J94W12lZPwF0gNfg073VNpIJWF nalQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=Jwr8BYRG; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id ay20si2030029edb.62.2019.11.27.17.51.49; Wed, 27 Nov 2019 17:52:13 -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; dkim=pass header.i=@chromium.org header.s=google header.b=Jwr8BYRG; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727192AbfK1Buy (ORCPT + 99 others); Wed, 27 Nov 2019 20:50:54 -0500 Received: from mail-pf1-f195.google.com ([209.85.210.195]:47024 "EHLO mail-pf1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726695AbfK1Buy (ORCPT ); Wed, 27 Nov 2019 20:50:54 -0500 Received: by mail-pf1-f195.google.com with SMTP id 193so12255820pfc.13 for ; Wed, 27 Nov 2019 17:50:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=VR2/v9AWTifanIT/eMBWdlLjcrylXavL2K2N3+XyWKM=; b=Jwr8BYRG9hc5AwI+XoTTuxNeM7IqXgM0Ugt7NqcfVJem+UlL6jjo8c2CE9bkJ9vRyA 4s9trIxViiJQSkX7847WiHDXh1bBc1UoFEsFnWpL4EhPKEOacBGNu6rhdY7tuOpKLANB BrryU15HsnWXYz3n5+1U9TFSzMvnm/XdPCrZk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=VR2/v9AWTifanIT/eMBWdlLjcrylXavL2K2N3+XyWKM=; b=FWJnvtNBmV+KHAGxsSgrGsmNHAa7oM5FC6q/laGJixjTMWW2Tv5vzyx67UPggcenrq 7akOMVhJ23TfXBt0BlacYcBOf4J3sDj4bhknvCLBkugTkzEqLNDbF3wBlvJu1bHC9TRJ YPLlbudqUyK50iWaSpKKetbWcmclwG3UGyfp8gsyBsy3LapRqbDRtOZ0nefZWKdt3c18 iqTkYcZ5ch/EOSGVJEKd5u4gzhLqdYJoTwCBAifj/nDO/Ogg0KlgkoP7fJ+MElYOuKZE tESQ+XxxlNsSiJbu7hFth7k7MxyQjENzfctcggO3r3g6jDFPoBEciW4si03EWX+U6jPF bkjg== X-Gm-Message-State: APjAAAX9Dg52dXPLezqx22L2jPAvcXLBRat0KRtJ7bTr+18fQSp3siGm TnCyW7ms9GGZyG6HHM6X/O5kuA1++Hw= X-Received: by 2002:a63:fd4c:: with SMTP id m12mr8479924pgj.211.1574905853402; Wed, 27 Nov 2019 17:50:53 -0800 (PST) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id s18sm18227508pfs.20.2019.11.27.17.50.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Nov 2019 17:50:52 -0800 (PST) Date: Wed, 27 Nov 2019 17:50:51 -0800 From: Kees Cook To: Andy Lutomirski Cc: Ingo Molnar , Andy Lutomirski , x86 , linux-kernel@vger.kernel.org Subject: Re: [PATCH] lkdtm/bugs: Avoid ifdefs for DOUBLE_FAULT Message-ID: <201911271748.A7C361E28@keescook> References: <201911271118.FCC2D04F@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 27, 2019 at 01:01:40PM -0800, Andy Lutomirski wrote: > > > > On Nov 27, 2019, at 11:19 AM, Kees Cook wrote: > > > > LKDTM test visibility shouldn't change, so remove the ifdefs on > > DOUBLE_FAULT and make sure test failure doesn't crash the system. > > > > Link: https://lore.kernel.org/lkml/20191127184837.GA35982@gmail.com > > Fixes: b09511c253e5 ("lkdtm: Add a DOUBLE_FAULT crash type on x86") > > Signed-off-by: Kees Cook > > --- > > applies on top of tip/x86/urgent > > --- > > drivers/misc/lkdtm/bugs.c | 8 +++++--- > > drivers/misc/lkdtm/core.c | 4 +--- > > drivers/misc/lkdtm/lkdtm.h | 2 -- > > 3 files changed, 6 insertions(+), 8 deletions(-) > > > > diff --git a/drivers/misc/lkdtm/bugs.c b/drivers/misc/lkdtm/bugs.c > > index a4fdad04809a..22f5293414cc 100644 > > --- a/drivers/misc/lkdtm/bugs.c > > +++ b/drivers/misc/lkdtm/bugs.c > > @@ -342,9 +342,9 @@ void lkdtm_UNSET_SMEP(void) > > #endif > > } > > > > -#ifdef CONFIG_X86_32 > > void lkdtm_DOUBLE_FAULT(void) > > { > > +#ifdef CONFIG_X86_32 > > /* > > * Trigger #DF by setting the stack limit to zero. This clobbers > > * a GDT TLS slot, which is okay because the current task will die > > @@ -373,6 +373,8 @@ void lkdtm_DOUBLE_FAULT(void) > > asm volatile ("movw %0, %%ss; addl $0, (%%esp)" :: > > "r" ((unsigned short)(GDT_ENTRY_TLS_MIN << 3))); > > > > - panic("tried to double fault but didn't die\n"); > > -} > > + pr_err("FAIL: tried to double fault but didn't die!\n"); > > +#else > > + pr_err("FAIL: this test is only available on 32-bit x86.\n"); > > #endif > > +} > > I’m not familiar with the userspace tooling, but this seems unfortunate. The first FAIL is “the test case screwed up, and it’s a bug.” The second FAIL is “not applicable to this system.” > > > ISTM simply not exposing the test on systems that don’t support makes sense. Can you clarify? I don't like the tests liked in the DIRECT file to change from build to build (it should be stable per kernel version). Userspace needs to know how to evaluate the results of running each test, so in both cases, I consider it a failure: double fault didn't work or you tried to test double fault on an unsupported architecture. (The SMEP test works similarly.) -- Kees Cook