From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 68734C46470 for ; Tue, 7 Aug 2018 10:24:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id F251C2170A for ; Tue, 7 Aug 2018 10:24:39 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F251C2170A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388870AbeHGMiQ (ORCPT ); Tue, 7 Aug 2018 08:38:16 -0400 Received: from foss.arm.com ([217.140.101.70]:52058 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388770AbeHGMiP (ORCPT ); Tue, 7 Aug 2018 08:38:15 -0400 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 EBE5D80D; Tue, 7 Aug 2018 03:24:36 -0700 (PDT) Received: from [10.4.13.119] (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 09F6A3F2EA; Tue, 7 Aug 2018 03:24:35 -0700 (PDT) Subject: Re: [PATCH] arm64: Trap WFI executed in userspace To: Dave Martin Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Catalin Marinas , Will Deacon References: <20180807093326.5090-1-marc.zyngier@arm.com> <20180807100437.GA9097@e103592.cambridge.arm.com> From: Marc Zyngier Organization: ARM Ltd Message-ID: <9af8bb9a-7c6c-2560-5965-118dfadf8141@arm.com> Date: Tue, 7 Aug 2018 11:24:34 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20180807100437.GA9097@e103592.cambridge.arm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/08/18 11:05, Dave Martin wrote: > On Tue, Aug 07, 2018 at 10:33:26AM +0100, Marc Zyngier wrote: >> It recently came to light that userspace can execute WFI, and that >> the arm64 kernel doesn trap this event. This sounds rather benign, >> but the kernel should decide when it wants to wait for an interrupt, >> and not userspace. >> >> Let's trap WFI and treat it as a way to yield the CPU to another >> process. > > This doesn't amount to a justification. > > If the power controller is unexpectedly left in a bad state so that > WFI will do something nasty to a cpu that may enter userspace, then we > probably have bigger problems. > > So, maybe it really is pretty harmless to let userspace execute this. Or not. It is also a very good way for userspace to find out when an interrupt gets delivered and start doing all kind of probing on the kernel. The least the userspace knows about that, the better I feel. > I can't think of a legitimate reason for userspace to execute WFI > however. Userspace doesn't have interrupts under Linux, so it makes > no sense to wait for one. > > Have we seen anybody using WFI in userspace? It may be cleaner to > map this to SIGILL rather than be permissive and regret it later. I couldn't find any user, and I'm happy to just send userspace to hell in that case. But it could also been said that since it was never prevented, it is a de-facto ABI. M. -- Jazz is not dead. It just smells funny...