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=-3.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 D80C6C47094 for ; Thu, 10 Jun 2021 13:32:06 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9919160FF0 for ; Thu, 10 Jun 2021 13:32:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9919160FF0 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=UThxQuY0T/xQiJmxwcmeUsAQZQR1fAQZHEeQSw/8Uy0=; b=mpJIV/HMXrTpIl CnzP50yO69Vq//PSCFx3V71/adtmhB5Yuz19lcZY6RTbnnXspDBBQIaInzYc4KeaF0lWKNSjCFoOS PrxYZXiQoOpML8E7y0s6xTZxjLk8Rk+dDY4EN6cBwEuOs9qMtDhFch95rVmr3nuv2VTNJIFfGhw/m tSUEubiW+bpuD29vDg5dyJqwbC6wrrHlzu+wOB+9D8C6r3SdGpLmPoQ+7XcyTf5RrK4PhGeD24g2B fi1K0Ukjrr97dAEljf2c9YKSvjd6mfl3V8cJMWko9IitWuLsRt9Pr/WOjF6oPhvADZ4I8WbwsTWfa XIvd5N3tYr+VoLqySvKg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lrKkq-000sRz-PH; Thu, 10 Jun 2021 13:29:52 +0000 Received: from mail-io1-f54.google.com ([209.85.166.54]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1lrKkn-000sR7-Hd for linux-arm-kernel@lists.infradead.org; Thu, 10 Jun 2021 13:29:51 +0000 Received: by mail-io1-f54.google.com with SMTP id 5so26953818ioe.1 for ; Thu, 10 Jun 2021 06:29:49 -0700 (PDT) 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=v4hLoN0siMfHmp2NeUt0J1eeOoHTnNdIx4P036PPjEI=; b=Wk2mffK1+ySY6phuAC9E6Oscs2QoIMJbvTczGwXAWqrgPaSNdboavkfXm+SHEyHUeN a7Cw5c2uW9jwxssW5/CHcxTLxz/zoQkIybbfmRMePDAjimANLEjvKq4MeAf8rppdazHw UDKe3a2tjdjRTtfXlGuSN/UwMx6wavCnuFK9k= 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=v4hLoN0siMfHmp2NeUt0J1eeOoHTnNdIx4P036PPjEI=; b=U0pi3hXy64vug1xsUWzTaFc7kKH+CAoonG5LKPgsfkkKzPFyRMqceHP/Wn644kH1JU HAyod5voXIvHNJTfspdZwXXxAUkNXp1ilb/u/EuVZrLAECfXw1sOFVNQy5XadACSfvVg fJS6mt7ab8kcjNo80mzTZJYUNTccBbBbFUne0ApNZgLXKyZvb9b9DQJJDFSLQ8+ABUVT 0wXApuIyzTUkihxBwzoJBIZZx8ZmNn2lrh9tkM5YAUObPPb0ontINL55BlR6dFAQ3gKy bfQqdZ+2GqQGxarKxX+Tyf3E8Hfz2F2M4OSExEsSGDL9hkQqK4ZDo5tuboYWputkmmKf rfug== X-Gm-Message-State: AOAM531hsdOvVnFhVXsJMM1N8BVX86kh3o3msZOBv++b2iLZ+AqiDcMb 2e+kZgROYN+j18N48M3PNtvEpGEAfxUsGuAJ/sgK/Q== X-Google-Smtp-Source: ABdhPJwDWhkRU1fVAP0bMfTTGja5FWHh/AN0sLKJdb5q2n5Skn/iVPxz7MLUvyRN1QZI0LSB0X1ZlcBFwRk8mJUuCsc= X-Received: by 2002:a02:354d:: with SMTP id y13mr4772274jae.83.1623331728198; Thu, 10 Jun 2021 06:28:48 -0700 (PDT) MIME-Version: 1.0 References: <87tupqu10c.fsf@linux.intel.com> <20210309063828.26392-1-saiprakash.ranjan@codeaurora.org> <20210309144423.GD203350@tassilo.jf.intel.com> <24e0d604750babd3461768897bb2ae82@codeaurora.org> In-Reply-To: <24e0d604750babd3461768897bb2ae82@codeaurora.org> From: Mattias Nissler Date: Thu, 10 Jun 2021 15:28:35 +0200 Message-ID: Subject: Re: [PATCHv2 0/4] perf/core: Add support to exclude kernel mode PMU tracing To: Sai Prakash Ranjan Cc: Andi Kleen , acme@kernel.org, Al Grant , alexander.shishkin@linux.intel.com, coresight@lists.linaro.org, Denis Nikitin , Douglas Anderson , jolsa@redhat.com, Leo Yan , linux-arm-kernel@lists.infradead.org, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, mark.rutland@arm.com, Mathieu Poirier , Mike Leach , mingo@redhat.com, namhyung@kernel.org, Peter Zijlstra , Suzuki K Poulose , Stephen Boyd X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210610_062949_599626_B9ADBC9E X-CRM114-Status: GOOD ( 45.37 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org I know this reply is hopelessly late, but I still want to clarify a few things (see inline for that) and provide some background on the thinking that led to this proposal and where we ultimately landed for the benefit of folks that come across this thread in the future. The team working on tracing had asked me to provide input on the security angle. We generally follow principle of least privilege / attack surface minimization principles, and so the conclusion "kernel tracing not needed" -> let's turn it off so we have one less thing to potentially worry about was an easy one. What I hadn't been aware of is that (a) no such config option exists in the kernel and (b) the approach that the kernel is taking is to limit access to tracing data to privileged users (via perf_event_paranoid sysctl, CAP_PERFMON). Same for leaking kernel code pointers (note that kernel tracing trivially defeats KASLR), privileged userspace can already read /proc/kallsysms. While I would still like the kernel to give us a build time option to disable kernel tracing, we can work with the current state of affairs. On Wed, Mar 10, 2021 at 4:17 PM Sai Prakash Ranjan wrote: > > Hi Andi, > > On 2021-03-09 20:14, Andi Kleen wrote: > >> The disk encryption is just one example The intention behind that example was to illustrate the point that there are some data items that the kernel should hide to all of userspace, including privileged processes. I know this has been controversial in the past, but I hope we all agree that the kernel (if configured appropriately) is aiming to do so. > > and there might be others > >> which > >> we might not be aware of yet and we are not suspecting there is > >> something > >> wrong with the crypto code that needs to be fixed. > > > > Then you don't have any leaks relating to branch tracing. > > > > >> restrict an external(in the sense that its not related to crypto or > >> any > >> other security related component) entity such as hardware assisted > >> tracing > >> like ARM coresight and so on. I don't see why or how the crypto code > >> needs > >> to be fixed for something that is not related to it although it is > >> affected. > > > > It's just a general property that if some code that is handling secrets > > is data dependent it already leaks. Timing side channels have been a constant source of grief in crypto implementations for decades now. Things have become better in the most popular implementations, but bugs continue to be found. I happened to chat about this topic with David Benjamin (boringssl maintainer) recently, and his take was that timing side channels are a well understood problem meanwhile, but in practice few implementations get the details right. And the thing with high-resolution timestamps in traces is that it gives you a tool to observe timing differences closer to the source (so less noise) than if you just measure syscall latency from userspace. So, in theory you are right - data-dependent branches should not exist in crypto code, and if they do we should just fix them, since they're potentially exploitable already. In practice, timestamp information in tracing data can act as a magnifying glass that may well make a difference between whether a timing side channel is problematic in practice or not. > > > > > >> The analogy would be like of the victims and a perpetrator. Lets take > >> coresight > >> as an example for perpetrator and crypto as the victim here. Now we > >> can try > > > > There's no victim with branch tracing, unless it is already leaky. > > > >> If we just know one victim (lets say crypto code here), what happens > >> to the > >> others which we haven't identified yet? Do we just wait for someone to > >> write > >> an exploit based on this and then scramble to fix it? > > > > For a useful security mitigation you need a threat model first I would > > say. > > > > So you need to have at least some idea how an attack with branch > > tracing would work. > > > > > >> Initial change was to restrict this only to HW assisted instruction > >> tracing [1] > > > > I don't think it's needed for instruction tracing. > > > > From what I know, newer ARM A-profile cores doesn't allow data tracing. > And you > are saying that just the instruction tracing cannot be used to infer any > important data. > > There are few security folks in CC who probably can give us more details > on how > branch tracing can be used for an exploit. @mnissler? > > Thanks, > Sai > > -- > QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a > member > of Code Aurora Forum, hosted by The Linux Foundation _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel