Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp2478617pxb; Mon, 18 Jan 2021 20:35:29 -0800 (PST) X-Google-Smtp-Source: ABdhPJwQqyexBZOYYcQtYxFZqh8dfYRQbFCRQn9xygQ+LVR9rglJTnJt9YIE1Fdojw8RSCHZbkLL X-Received: by 2002:a05:6402:22d6:: with SMTP id dm22mr1880462edb.255.1611030929102; Mon, 18 Jan 2021 20:35:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611030929; cv=none; d=google.com; s=arc-20160816; b=GuQnvn0enPVjlWMn5F+VOcq44IYYbP3ETZoudIH0fJDNWkuT7dXTRpb+P2hsnEMF3F 2CT2MDm69r6JtKni6IPvZb6RCGWxpcvHjLIdOZSCVLxyHq3zxUGs6Q0j6SqQ/Jx2tU4n 52w0K+eJRoT1d0TKrEbalUF0BFlxNLszAfNvoqz3BwaHh+LHJm0NZtbijn21rD+CCYlw dQWqk6UiBBQRqknPUBKvUKqBW68gTL3dAbTJqOBru9pynWQi4NMLjAfdWxP03rOylFdf XahoMhOh0OkvAUmIBlJyeHizeBA6ztk3rT29TNEUDqSMahQN89/ejJ/tS0ayduLbHsYU +S1w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=tYITA3Yxe+LNUEBbIjMhLMDLo8Pr6qOWRiVR9QOc69o=; b=l8Znu/byQFwGsIv5tgd1e/3SYo9F6zTjahJToPL4ctcQJBM5jH77YfkwL9HfUINnuh SG8U+esEtYtJwDHTQB1pc/NNG4EpEDny2BfLWZGIbsvGYoevMsdBUiQeIiR264UaPGQG uM7KIY3P9BPxPHSUVpbDuY8GZdIlp8s8hLHwPiiWJa0p34Ne5a2ooeD7e+UPGEqul7IK V+XJ0kIb8C9sWtEOMkb3t/qwNFa2Y0vqt8nWBYIC8jNRb77guSnJ/WwxFrpRSaLTY3/x gJ/FyUBiXshz1CZEUMdHPcxypZyb1AgHXhAjh4f4YxuxZcFWZ/PIqNn5/pY7SHazwjKj S0pg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=WBp4BQ4i; 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=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s12si1942862ejz.50.2021.01.18.20.35.01; Mon, 18 Jan 2021 20:35:29 -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=@chromium.org header.s=google header.b=WBp4BQ4i; 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=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2405245AbhAROt5 (ORCPT + 99 others); Mon, 18 Jan 2021 09:49:57 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57876 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2405179AbhAROsR (ORCPT ); Mon, 18 Jan 2021 09:48:17 -0500 Received: from mail-ua1-x92a.google.com (mail-ua1-x92a.google.com [IPv6:2607:f8b0:4864:20::92a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 88122C0613C1 for ; Mon, 18 Jan 2021 06:47:36 -0800 (PST) Received: by mail-ua1-x92a.google.com with SMTP id v23so1307004uam.8 for ; Mon, 18 Jan 2021 06:47:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tYITA3Yxe+LNUEBbIjMhLMDLo8Pr6qOWRiVR9QOc69o=; b=WBp4BQ4iS/nMuJHj2dRCYS1FOe1q70UMadKm9plqyvTpqfBAye6UbGn+Szu9OK2C9t /sL8U2B/SyzKpzYyfD/PA0RseoBzXrBcf12M4EFyJMxQXw3jeGXo1UhmVOCddHRiGoax Xyfns6tQ10yiERfST33vIWqybEqEXPJWFcPbE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tYITA3Yxe+LNUEBbIjMhLMDLo8Pr6qOWRiVR9QOc69o=; b=d6aL5oPAgp4ND6SMzEPqcX49+UdWK6q/AMpaZ5yKUx4mGSVKpcTDKsP/9mgG7P21QS Nrd49pz9IFLHuQQEbOIMmJrVqDTLgtfaEGz2GT8kBz/7TLCL/lsDOF3UjM9MsrPLwfKw 5KDJ53nJzY7dxu6fMeoDFYZWkD1HLgMTvGyH088ywTBReKR4a3ZinSRaiO2FnrABxq5m G8GzE6lP7H1oKB53SAr9TzcxykiBEQoBTuyqlwLOkYF/lUibVtcLgsostETDTwoBF7b0 EjnmjSN7ivcfMvIv8T9e5EjBqz2FgAKYftR6bueF8yuUDrsl0Mpke4QJVprBqagUAY71 MLRA== X-Gm-Message-State: AOAM533YQWRpsb8PfOTMP77YxbMkk5EVB3HcpYrcPItI6I7DyAMySTVC MZgzSttyQpDUhEPuCWFAViFUdiOg61Qm7uB5m2wtSw== X-Received: by 2002:ab0:7193:: with SMTP id l19mr2785323uao.84.1610981255465; Mon, 18 Jan 2021 06:47:35 -0800 (PST) MIME-Version: 1.0 References: <20201015124522.1876-1-saiprakash.ranjan@codeaurora.org> <20201015160257.GA1450102@xps15> In-Reply-To: From: Mattias Nissler Date: Mon, 18 Jan 2021 15:47:23 +0100 Message-ID: Subject: Re: [PATCH] coresight: etm4x: Add config to exclude kernel mode tracing To: Sai Prakash Ranjan Cc: Mathieu Poirier , Suzuki K 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, Al Grant , leo.yan@linaro.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 15, 2021 at 6:46 AM 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. Well, the idea that root privileges != full control over the kernel isn't new and at the very least since lockdown became part of mainline [1] no longer an esoteric edge case. Regarding the use case Sai hints at (namely protection of secrets in the kernel), Matthew Garret actually has some more thoughts about confidentiality mode for lockdown for secret protection [2]. And thus, unless someone can make a compelling case that instruction-level tracing will not leak secrets held by the kernel, I think an option for the kernel to prevent itself from being traced (even by root) is valuable. Finally, to sketch a practical use case scenario: Consider a system where disk contents are encrypted and the encryption key is set up by the user when mounting the file system. From that point on the encryption key resides in the kernel. It seems reasonable to expect that the disk encryption key be protected from exfiltration even if the system later suffers a root compromise (or even against insiders that have root access), at least as long as the attacker doesn't manage to compromise the kernel. [1] https://lwn.net/Articles/796866/ [2] https://mjg59.dreamwidth.org/55105.html > > After this discussion, I would like to post a v2 based on Suzuki's > feedback earlier. @Suzuki, I have a common config for ETM3 and ETM4 > but couldn't get much idea on how to implement it for Intel PTs, if > you have any suggestions there, please do share or we can have this > only for Coresight ETMs. > > Thanks, > Sai > > -- > QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a > member > of Code Aurora Forum, hosted by The Linux Foundation