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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 256ECC3DA7A for ; Fri, 6 Jan 2023 12:02:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231855AbjAFMCx (ORCPT ); Fri, 6 Jan 2023 07:02:53 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46504 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229547AbjAFMCt (ORCPT ); Fri, 6 Jan 2023 07:02:49 -0500 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id C81A3728A9; Fri, 6 Jan 2023 04:02:48 -0800 (PST) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 58F7F11FB; Fri, 6 Jan 2023 04:03:30 -0800 (PST) Received: from FVFF77S0Q05N (unknown [10.57.37.197]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 5011E3F23F; Fri, 6 Jan 2023 04:02:46 -0800 (PST) Date: Fri, 6 Jan 2023 12:02:39 +0000 From: Mark Rutland To: Atish Patra Cc: linux-perf-users@vger.kernel.org, "linux-kernel@vger.kernel.org List" , Peter Zijlstra , Arnaldo Carvalho de Melo , Alexander Shishkin , Will Deacon , Stephane Eranian , Andi Kleen , Palmer Dabbelt , Beeman Strong , Atish Patra , Kan Liang , Anup Patel Subject: Re: Expected rdpmc behavior during context swtich and a RISC-V conundrum Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 05, 2023 at 11:59:24AM -0800, Atish Patra wrote: > Hi All, > There was a recent uabi update[1] for RISC-V that allows the users to > read cycle and instruction count without any checks. > We tried to restrict that behavior to address security concerns > earlier but it resulted in breakage for some user space > applications[2]. > Thus, previous behavior was restored where a user on RISC-V platforms > can directly read cycle or instruction count[3]. > > Comparison with other ISAs w.r.t user space access of counters: > ARM64 > -- Enabled/Disabled via (/proc/sys/kernel/perf_user_access) > -- Only for task bound events configured via perf. > > X86 > --- rdpmc instruction > --- Enable/Disable via “/sys/devices/cpu/rdpmc” > -- Before v4.0 > -- any process (even without active perf event) rdpmc > After v4.0 > -- Default behavior changed to support only active events in a > process’s context. > -- Configured through perf similar to ARM64 > -- Continue to maintain backward compatibility for unrestricted access > by writing 2 to “/sys/devices/cpu/rdpmc” > > IMO, RISC-V should only enable user space access through perf similar > to ARM64 and x86 (post v4.0). > However, we do have to support the legacy behavior to avoid > application breakage. > As per my understanding a direct user space access can lead to the > following problems: > > 1) There is no context switch support, so counts from other contexts are exposed > 2) If a perf user is allocated one of these counters, the counter > value will be written > > Looking at the x86 code as it continues to allow the above behavior, > rdpmc_always_available_key is enabled in the above case. However, > during the context switch (cr4_update_pce_mm) > only dirty counters are cleared. It only prevents leakage from perf > task to rdpmc task. > > How does the context switch of counters work for users who enable > unrestricted access by writing 2 to “/sys/devices/cpu/rdpmc” ? > Otherwise, rdpmc users likely get noise from other applications. Is > that expected ? Regardless of leakage, they're also going to get random jumps in the visible values of the cycle count and instruction count as the task is context-switched (and/or if those values get reset across idle, as can happen on arm64), so those aren't going to be useful unless a number of other constraints apply. AFAICT the affected package was actually a library of intrinsics; does this affect a real application, or was this just in tests? If it's the latter there might still be scope to properly lock this down... Thanks, Mark. > This can be a security concern also where a rogue rdpmc user > application can monitor other critical applications to initiate side > channel attack. > > Am I missing something? Please correct my understanding of the x86 > implementation if it is wrong. > > [1] https://lore.kernel.org/lkml/20221201135110.3855965-1-conor.dooley@microchip.com/ > [2] https://groups.google.com/a/groups.riscv.org/g/sw-dev/c/REWcwYnzsKE?pli=1 > [3] https://lore.kernel.org/all/YxIzgYP3MujXdqwj@aurel32.net/T/ > > -- > Regards, > Atish