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.8 required=3.0 tests=BAYES_00, 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 8B184C433DB for ; Thu, 4 Mar 2021 20:02:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4D13F64F65 for ; Thu, 4 Mar 2021 20:02:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233080AbhCDUBX (ORCPT ); Thu, 4 Mar 2021 15:01:23 -0500 Received: from mga18.intel.com ([134.134.136.126]:5002 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236436AbhCDUAw (ORCPT ); Thu, 4 Mar 2021 15:00:52 -0500 IronPort-SDR: FFtnBEmkJbgWTP6Qlm6SOH00t0xe4p/wgGnXgEJVqp9EQyHReVmULEtRwsGV3hWL21ZgPepURb k+k81HNUGklg== X-IronPort-AV: E=McAfee;i="6000,8403,9913"; a="175125353" X-IronPort-AV: E=Sophos;i="5.81,223,1610438400"; d="scan'208";a="175125353" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Mar 2021 11:59:06 -0800 IronPort-SDR: D3DTZrbThlWBnXNSvA3kUTKRJ4GZ7ZoI1FThV+majRRy54gGnc32w/Zs/23DnxNdKFnV593bgw xq+5vG7zjhIQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.81,223,1610438400"; d="scan'208";a="428792917" Received: from tassilo.jf.intel.com (HELO tassilo.localdomain) ([10.54.74.11]) by fmsmga004.fm.intel.com with ESMTP; 04 Mar 2021 11:59:05 -0800 Received: by tassilo.localdomain (Postfix, from userid 1000) id 25CAD302859; Thu, 4 Mar 2021 11:59:05 -0800 (PST) From: Andi Kleen To: Sai Prakash Ranjan Cc: Mathieu Poirier , Suzuki K Poulose , Mike Leach , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Mark Rutland , Alexander Shishkin , Leo Yan , Jiri Olsa , Namhyung Kim , coresight@lists.linaro.org, Stephen Boyd , Denis Nikitin , Mattias Nissler , Al Grant , linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Douglas Anderson Subject: Re: [PATCHv2 0/4] perf/core: Add support to exclude kernel mode PMU tracing References: Date: Thu, 04 Mar 2021 11:59:05 -0800 In-Reply-To: (Sai Prakash Ranjan's message of "Tue, 2 Mar 2021 00:34:14 +0530") Message-ID: <871rcuvgfq.fsf@linux.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org Sai Prakash Ranjan writes: > > "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." Normally disk encryption is in specialized work queues. It's total overkill to restrict all of the kernel if you just want to restrict those work queues. I would suggest some more analysis where secrets are actually stored and handled first. -Andi 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.8 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 5368AC433DB for ; Thu, 4 Mar 2021 20:03:23 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 C0CB164F65 for ; Thu, 4 Mar 2021 20:03:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C0CB164F65 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com 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=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:Message-ID:In-Reply-To:Date:References: Subject:Cc:To:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=ktZV1Y9i6q1N9TUeKAb2EJnVGgnmjKWKvuAQoPDpmIM=; b=Fd6HUtkNkfGGnwDIKQyhJteTz CvB9cg6a2IixmnxpHzINIK0T0NmVlDET1i0ji2azXYUCu/nR1DR08mYXdqiUBWuJkyfhqgJNVAQkn rIFwU+3EANiqb4tvFKP4aofpPzlFSzHNEzfKf+5JxfVGry8duZYRrSbWvVkWIhw9jxuB+M1NSuYMM GZPALnvGp7l3n56fdIGsI/3lRnyLp0z+NV8Q+OpmUiyUSaUydpLDs2cxY96BuvD7X0fBfZ2w38Hpj dOs8C/m23J7gor2yWc3ZP2Ek+6MTWBO+9/+34ynwZuiqk5gCuO0SYUhcnmk4LTJ8T8opOZR29aMLC sIsebWNUw==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lHuAH-009rSr-U9; Thu, 04 Mar 2021 20:01:42 +0000 Received: from casper.infradead.org ([2001:8b0:10b:1236::1]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lHuA7-009rRe-CB for linux-arm-kernel@desiato.infradead.org; Thu, 04 Mar 2021 20:01:34 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=Content-Type:MIME-Version:Message-ID: In-Reply-To:Date:References:Subject:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=sw3kP/L2wEwl/uWR8XnvIXWDXovlIz25ezk0KRQ8J58=; b=WOW9NLmDwKXTtP+HS5DrQh9SL5 x/4Wc9HkN4fZcA7VoN/ybyRTWdc/bBoA+mRIeU+5Ez1GmCNvimpc9nyxKWF10z1/oNpC73I+qzYBk ToVNABX+EL+/W6U17/ogdg9GT973J4dQyd2PgFnnXnegNUtWJtq1IQkns2hzHPSa52nQzDVDVYvN/ 0sFxn6vgRwRlqqmrwnDtzTZF142ttWza8pY0GWuVVd0nOCQ8UnlBzYqYwRggi1ENXYkcSBDjQgKoB wlxfH18j/AiVUa3e8eMc23VYYRPaJkfVK+q4gnBkYecsBEI8UD6w1Yi594UBI6ZdlDa6c+U+NQKWw fkaHfy2w==; Received: from mga11.intel.com ([192.55.52.93]) by casper.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lHu9R-008UwP-8l for linux-arm-kernel@lists.infradead.org; Thu, 04 Mar 2021 20:01:02 +0000 IronPort-SDR: 5WAVTFesFL2LZ0EUvIyrDlDRapPWE4pUV4Vr2QWybOAPqghmyf1gB0mICDb+bUFUvX2oC4y1cy nAbvTS4776BA== X-IronPort-AV: E=McAfee;i="6000,8403,9913"; a="184121760" X-IronPort-AV: E=Sophos;i="5.81,223,1610438400"; d="scan'208";a="184121760" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Mar 2021 11:59:06 -0800 IronPort-SDR: D3DTZrbThlWBnXNSvA3kUTKRJ4GZ7ZoI1FThV+majRRy54gGnc32w/Zs/23DnxNdKFnV593bgw xq+5vG7zjhIQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.81,223,1610438400"; d="scan'208";a="428792917" Received: from tassilo.jf.intel.com (HELO tassilo.localdomain) ([10.54.74.11]) by fmsmga004.fm.intel.com with ESMTP; 04 Mar 2021 11:59:05 -0800 Received: by tassilo.localdomain (Postfix, from userid 1000) id 25CAD302859; Thu, 4 Mar 2021 11:59:05 -0800 (PST) From: Andi Kleen To: Sai Prakash Ranjan Cc: Mathieu Poirier , Suzuki K Poulose , Mike Leach , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Mark Rutland , Alexander Shishkin , Leo Yan , Jiri Olsa , Namhyung Kim , coresight@lists.linaro.org, Stephen Boyd , Denis Nikitin , Mattias Nissler , Al Grant , linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Douglas Anderson Subject: Re: [PATCHv2 0/4] perf/core: Add support to exclude kernel mode PMU tracing References: Date: Thu, 04 Mar 2021 11:59:05 -0800 In-Reply-To: (Sai Prakash Ranjan's message of "Tue, 2 Mar 2021 00:34:14 +0530") Message-ID: <871rcuvgfq.fsf@linux.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210304_200102_874744_B203C0F6 X-CRM114-Status: GOOD ( 14.54 ) 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 Sai Prakash Ranjan writes: > > "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." Normally disk encryption is in specialized work queues. It's total overkill to restrict all of the kernel if you just want to restrict those work queues. I would suggest some more analysis where secrets are actually stored and handled first. -Andi _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel