Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp120480imu; Thu, 3 Jan 2019 15:27:05 -0800 (PST) X-Google-Smtp-Source: ALg8bN6hjmSRWz+Z0Pgkms5sC4E0jUq4nVbOlpKAuU4HDrwWZHYMEpWS6A8fps9wczqLl5wTF/Z2 X-Received: by 2002:a63:ef04:: with SMTP id u4mr18924634pgh.197.1546558025308; Thu, 03 Jan 2019 15:27:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1546558025; cv=none; d=google.com; s=arc-20160816; b=ZbspdmsXVWjoLzmjtUavozVmFbUjD8JVlee3+zGnaRvrdAEpLZ0bM0BP6ejRnkb9Ne mxpeADsURWG9QESGuZmPQMl6+2YWQJD+yWedPdLzhB711y4SYCAUjKIb/b5OTw3P6Q9y PsUQCPdoivP+tJudcljTJXCVG0Q+4xO5bsertPDfVcyvolUX8i6Uv3jKw+svqBTiRRYK 4HQKA+YdM67EEmBFnbmUtQxaXoX3pjFnEgLulbkKDmRbUP6iVA6fuwBmot1KFKdaH0k1 iK1FZq6LcMh6b3hWDp0MWkIYlCHrHrAmCAJ7Gl43d8kgN8WYpNEmiJMtwFO/TFFw0MKD oNcg== 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=NvJWnrL9iZPxNcZdiq//i+Edvw6PvAl+freSaomrJnM=; b=h3zm72GACCHeMxXSRFYvUCgIXLMCIiw6RdlA2NyuVQf5j5XWEnhyTkk8roftseKYUE uLcN34zRXgSipKrBACJKQnVmDCPA0tbF36DZNhQTEJRwhoLZJz7LhGCzUd+MWbIqkuCN bkYiIAnsliw+Ef/4c2P4JGYYFzbOMYpQHInTSW+fmYvLo1nV4tKIO/HdNW6lEIeNm+BX Bd1zixRKc9+wszAgtPDAT8ppms8iqkGphCXRo40zKgcbLE50I+mZ5JSgNXuguB4BlkA8 wXQyA9XTerVXf9Xb9Omrzh8+iIf5jSDPjzVljC8t7wyZKnEb36n1aqPro43A4mxJ3Qe0 bhnQ== 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 g10si9572471plm.1.2019.01.03.15.26.40; Thu, 03 Jan 2019 15:27:05 -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 S1730629AbfACQq5 (ORCPT + 99 others); Thu, 3 Jan 2019 11:46:57 -0500 Received: from foss.arm.com ([217.140.101.70]:52884 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728159AbfACQq5 (ORCPT ); Thu, 3 Jan 2019 11:46:57 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 3904415AD; Thu, 3 Jan 2019 08:46:56 -0800 (PST) Received: from [192.168.100.243] (usa-sjc-mx-foss1.foss.arm.com [217.140.101.70]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D27263F5D4; Thu, 3 Jan 2019 08:46:54 -0800 (PST) Subject: Re: [PATCH v2 1/7] sysfs/cpu: Add "Unknown" vulnerability state To: Dave Martin Cc: linux-arm-kernel@lists.infradead.org, mark.rutland@arm.com, mlangsdo@redhat.com, "Rafael J . Wysocki" , Konrad Rzeszutek Wilk , suzuki.poulose@arm.com, marc.zyngier@arm.com, catalin.marinas@arm.com, Dave Hansen , julien.thierry@arm.com, will.deacon@arm.com, linux-kernel@vger.kernel.org, steven.price@arm.com, Peter Zijlstra , Borislav Petkov , David Woodhouse , Greg Kroah-Hartman , ykaukab@suse.de, Thomas Gleixner , shankerd@codeaurora.org References: <20190103004921.1928921-1-jeremy.linton@arm.com> <20190103004921.1928921-2-jeremy.linton@arm.com> <20190103163740.GC3529@e103592.cambridge.arm.com> From: Jeremy Linton Message-ID: Date: Thu, 3 Jan 2019 10:46:53 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20190103163740.GC3529@e103592.cambridge.arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 01/03/2019 10:37 AM, Dave Martin wrote: > On Wed, Jan 02, 2019 at 06:49:15PM -0600, Jeremy Linton wrote: >> There is a lot of variation in the Arm ecosystem. Because of this, >> there exist possible cases where the kernel cannot authoritatively >> determine if a machine is vulnerable. >> >> Rather than guess the vulnerability status in cases where >> the mitigation is disabled or the firmware isn't responding >> correctly, we need to display an "Unknown" state. >> >> Signed-off-by: Jeremy Linton >> Cc: Thomas Gleixner >> Cc: Greg Kroah-Hartman >> Cc: Rafael J. Wysocki >> Cc: Konrad Rzeszutek Wilk >> Cc: Peter Zijlstra >> Cc: Dave Hansen >> Cc: Borislav Petkov >> Cc: David Woodhouse >> --- >> Documentation/ABI/testing/sysfs-devices-system-cpu | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu >> index 9605dbd4b5b5..876103fddfa4 100644 >> --- a/Documentation/ABI/testing/sysfs-devices-system-cpu >> +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu >> @@ -495,6 +495,7 @@ Description: Information about CPU vulnerabilities >> "Not affected" CPU is not affected by the vulnerability >> "Vulnerable" CPU is affected and no mitigation in effect >> "Mitigation: $M" CPU is affected and mitigation $M is in effect >> + "Unknown" The kernel is unable to make a determination > > Do some of the "Unknown" cases arise from the vulnerability detection > code being compiled out of the kernel? > Yes, > I wonder whether at least the detection support should be mandatory. > sysfs is not very useful as a standard vulnerability reporting interface > unless we make best efforts to always populate it with real information. > > > Also, does "Unknown" convey anything beyond what is indicated by the > sysfs entry being omitted altogether? I'm not sure about this one. I tend to think the "unknown" case encourages users that really want an answer to dig deeper and call their hardware/os/whoever to get an answer. I would tend to think that if the entry is missing it would tend to encourage the behavior that Greg KH mentions where the user assumes "hey the system doesn't have a sysfs entry for $VUNLERABILITY, that probably means that its not possible on the architecture".