Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp455732pxb; Wed, 20 Jan 2021 11:04:46 -0800 (PST) X-Google-Smtp-Source: ABdhPJzT/nM99n5bIUjRzPIFfOhIhMcXcYB6K0bqa6gJCEMG9v3RRLc9cOkLjZUeAtFn7ZUmo08Q X-Received: by 2002:a17:906:2747:: with SMTP id a7mr7275479ejd.250.1611169486187; Wed, 20 Jan 2021 11:04:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611169486; cv=none; d=google.com; s=arc-20160816; b=BRU3Xi3Ak0yZCs66LgrJI5RbINjF1BiXvvj5I4nG0f8W2FKB7hCKlkOEceklqneb7V Jsk4pjknprUql7ro19cwb0d8nyZgjtRiMiJhNOkfcBNKFFqEfMhkTgyKzC+Yl9oeM5We xzr4IaMsivoydCSG623QWY4Ioq2b/ICW6XoOXzXde+zOB6/9JsNsvbOpMVb27YswdX7E F4MalhBJhQk2yMZ9nIX6C3Wf3EWfkMIJrOUhauVeLDzP4N0PgRBPFEUq+O1gCq2c5WwM nfnn2ORYk2iTIPkrEfEI4MxoMytnrZVSa04AyenRc59oiX7gde9xRuYbQcWVOEjPfQA4 /4TA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=/5Cv4pHDEwpFya1ca/ZpRFyUHE65qa5G41oFQpNl5GM=; b=ln2/5xPA3C/doxpjmJlO6vO9aJzfFaYOuSPbEEqURAfTg5fXr16Lcwn1r/quht2uIH WurajTvGZvFHYEDKA1pDBXrmcSzMDbH+sH2afD6H85pXNpx/YVUb8blsBENQp0k1FPU2 d309eUNPxW7I305IIbMD6DnE5dv3boZPN4RP8E3aOjYlmLZpe0XzTAbI81gn0o1gX15D cRz5UEe5kfJbzi0HSr74tWrs7bOufO2Y3m82KyucN76rcuD7O5futzauAy31LU5smkeH wpQuWlbnWJp4Ov+IEYDVfHvXuAa1qReTrBeKi34lWqG5gRriQHCnnhYlOwY7afJSe0UB nrwg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=jdVSJVKM; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d7si1212962edv.185.2021.01.20.11.04.18; Wed, 20 Jan 2021 11:04:46 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=jdVSJVKM; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2392253AbhATTCM (ORCPT + 99 others); Wed, 20 Jan 2021 14:02:12 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52586 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2392045AbhATSt1 (ORCPT ); Wed, 20 Jan 2021 13:49:27 -0500 Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 99475C061575 for ; Wed, 20 Jan 2021 10:48:42 -0800 (PST) Received: by mail-pf1-x435.google.com with SMTP id w18so3772242pfu.9 for ; Wed, 20 Jan 2021 10:48:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=/5Cv4pHDEwpFya1ca/ZpRFyUHE65qa5G41oFQpNl5GM=; b=jdVSJVKMHHUgt8ZELkdJI4HkFNZQ6l+Q0tIo6UhH7DGbLLRcbPKjW/hUUhWO0vL2oe kUj4kbV0jJXfbI0ebRY83BT5r1o7FthIIkRHB0vj44nEKpGdQmZIU3Ee1bQRl+AAH7vI 5O1++uzkiWCST2JS0lLeFaRNNC21lxtdCKRP2mzI/m7Smugcka75qzj1s46llPrj3J87 SyoMVfxFz96KMbtiWCCJ1HHTJ5Dln8KOckWKDoyD1tUd1kJ6uy3iJit3n7+6WpbWSGpJ QHk2CIBqqW1zSGTBUvbb5UNpsd6CrMp83lr70O//4e2AOXUJNw8F1qmiEnnwZ7aYjmOg CQWg== 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:in-reply-to; bh=/5Cv4pHDEwpFya1ca/ZpRFyUHE65qa5G41oFQpNl5GM=; b=lTe8f3ngStwqLgdeZxVzdtAi6P1smy3mRSRerueM5uBBrTfNaySXa34l9YSmEhaef0 /+katXgddsz3YnKHHFSnSQg8vqfiYqTVoXxA09BZle6ve2u0y8B0q4wcY1jUHg2zIkLB K1RLSdnm2Z3BLWHwxp14FVHxxLnNjJyb/BVfFWZLhFofug7+vo3ZrsStIJnVTgu+b4l5 g8dH+gp9N0uEQ7fjOVs1gvd/Z/5hXUL9F8ikwBwJTxWRjWOlXY6IvqbzMJb1+2G/DLTZ qWr5prQR1Ddo/1VlO1JDJwZqyCUcc2YYCB6xx3jFTXJxFYjHfhNUSoHTHPZPXJIsFu/M r6cA== X-Gm-Message-State: AOAM533kxt0Iq9/I6zA4bEyI110raEH0uqSP+9QipWLZtKTPoD4WZHWk T9ZdtJbYQ/ytc02lFvRsp21CTA== X-Received: by 2002:a05:6a00:1393:b029:1b4:7938:ff1d with SMTP id t19-20020a056a001393b02901b47938ff1dmr10494530pfg.31.1611168522092; Wed, 20 Jan 2021 10:48:42 -0800 (PST) Received: from xps15 (S0106889e681aac74.cg.shawcable.net. [68.147.0.187]) by smtp.gmail.com with ESMTPSA id x23sm3195933pgk.14.2021.01.20.10.48.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 Jan 2021 10:48:41 -0800 (PST) Date: Wed, 20 Jan 2021 11:48:39 -0700 From: Mathieu Poirier To: Al Grant Cc: Sai Prakash Ranjan , Suzuki Poulose , Mike Leach , "coresight@lists.linaro.org" , Stephen Boyd , Denis Nikitin , "linux-arm-msm@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "leo.yan@linaro.org" , "mnissler@google.com" Subject: Re: [PATCH] coresight: etm4x: Add config to exclude kernel mode tracing Message-ID: <20210120184839.GB708905@xps15> References: <20201015124522.1876-1-saiprakash.ranjan@codeaurora.org> <20201015160257.GA1450102@xps15> <20210118202354.GC464579@xps15> <32216e9fa5c9ffb9df1123792d40eafb@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 19, 2021 at 08:36:22AM +0000, Al Grant wrote: > Hi Sai, > > > From: saiprakash.ranjan=codeaurora.org@mg.codeaurora.org > > Hi Mathieu, > > > > On 2021-01-19 01:53, Mathieu Poirier wrote: > > > On Fri, Jan 15, 2021 at 11:16:24AM +0530, Sai Prakash Ranjan wrote: > > >> Hello Mathieu, Suzuki > > >> > > >> On 2020-10-15 21:32, Mathieu Poirier wrote: > > >> > On Thu, Oct 15, 2020 at 06:15:22PM +0530, Sai Prakash Ranjan wrote: > > >> > > On production systems with ETMs enabled, it is preferred to > > >> > > exclude kernel mode(NS EL1) tracing for security concerns and > > >> > > support only userspace(NS EL0) tracing. So provide an option via > > >> > > kconfig to exclude kernel mode tracing if it is required. > > >> > > This config is disabled by default and would not affect the > > >> > > current configuration which has both kernel and userspace tracing > > >> > > enabled by default. > > >> > > > > >> > > > >> > One requires root access (or be part of a special trace group) to > > >> > be able to use the cs_etm PMU. With this kind of elevated access > > >> > restricting tracing at EL1 provides little in terms of security. > > >> > > > >> > > >> Apart from the VM usecase discussed, I am told there are other > > >> security concerns here regarding need to exclude kernel mode tracing > > >> even for the privileged users/root. One such case being the ability > > >> to analyze cryptographic code execution since ETMs can record all > > >> branch instructions including timestamps in the kernel and there may > > >> be other cases as well which I may not be aware of and hence have > > >> added Denis and Mattias. Please let us know if you have any questions > > >> further regarding this not being a security concern. > > > > > > Even if we were to apply this patch there are many ways to compromise > > > a system or get the kernel to reveal important information using the > > > perf subsystem. I would perfer to tackle the problem at that level > > > rather than concentrating on coresight. > > > > > > > Sorry but I did not understand your point. We are talking about the capabilities > > of coresight etm tracing which has the instruction level tracing and a lot more. > > Perf subsystem is just the framework used for it. > > In other words, its not the perf subsystem which does instruction level tracing, > > its the coresight etm. Why the perf subsystem should be modified to lockdown > > kernel mode? If we were to let perf handle all the trace filtering for different > > exception levels, then why do we need the register settings in coresight etm > > driver to filter out NS EL* tracing? And more importantly, how do you suppose > > we handle sysfs mode of coresight tracing with perf subsystem? > > You both have good points. Mathieu is right that this is not a CoreSight > issue specifically, it is a matter of kernel security policy, and other hardware > tracing mechanisms ought to be within its scope. There should be a general > "anti kernel exfiltration" config that applies to all mechanisms within > its scope, and we'd definitely expect that to include Intel PT as well as ETM. > > A kernel config that forced exclude_kernel on all perf events would deal with > ETM and PT in one place, but miss the sysfs interface to ETM. > > On the other hand, doing it in the ETM drivers would cover the perf and sysfs > interfaces to ETM, but would miss Intel PT. > > So I think what is needed is a general config option that is both implemented > in perf (excluding all kernel tracing events) and by any drivers that provide > an alternative interface to hardware tracing events. > I also think this is the right solution. Thanks, Mathieu > Al > > > > > > Thanks, > > Sai > > > > -- > > QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member > > of Code Aurora Forum, hosted by The Linux Foundation