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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 1AC33E93806 for ; Tue, 14 Apr 2026 04:25:35 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id B9B3F10E09C; Tue, 14 Apr 2026 04:25:34 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.b="R4fZy+c/"; dkim-atps=neutral Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.8]) by gabe.freedesktop.org (Postfix) with ESMTPS id 504B810E09C for ; Tue, 14 Apr 2026 04:25:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1776140733; x=1807676733; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=dQLOprtZW2vZZ1ogSLN1Vkxo49+iiXw35FTdJg/26sY=; b=R4fZy+c/ipnLkGWRlTmB1ZIwJ+wPbWOd6q57R2OAn1HSB8+oGT3V0Ak6 4TOJqpwXnpI31Jhknv08rHR71eSRanchDHWy/SRvq+VnYwwj9kLqagPdt HuPQHsV0zEC1mrnvsTzQXn+zAeJf6c+KGWOs7av9nRR85OsDrOTGp7MGI P1IcGnEmimyoHiFojAWZeU/xYsu+Wxoh7UWNszeydqZ/Pwc61vkMcH1eX pXpAWpKdYyQD/oXjOervMDuOxd30okRkh+6HAtHDfvsrPlDeNSqJ9Wp3C xl4tAcWmiYEkB2Xa/qt13Fm6bJpUkdwWC/zNfyS2wCbcjz7l4w54E7fQT Q==; X-CSE-ConnectionGUID: RvfLlEIGTiC1oUplKXL21A== X-CSE-MsgGUID: m1MuSbEZQUCwVd+hfPApOA== X-IronPort-AV: E=McAfee;i="6800,10657,11758"; a="94653369" X-IronPort-AV: E=Sophos;i="6.23,178,1770624000"; d="scan'208";a="94653369" Received: from fmviesa009.fm.intel.com ([10.60.135.149]) by fmvoesa102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Apr 2026 21:25:33 -0700 X-CSE-ConnectionGUID: G65CSlxxRt+ylzcVbH/1Wg== X-CSE-MsgGUID: 8OQPtKCLRzq0A1WN2+4TkQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.23,178,1770624000"; d="scan'208";a="223477245" Received: from unknown (HELO adixit-MOBL3.intel.com) ([10.125.136.209]) by fmviesa009-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Apr 2026 21:25:32 -0700 Date: Mon, 13 Apr 2026 21:25:31 -0700 Message-ID: <87340y88xw.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: Matt Roper Cc: , Umesh Nerlige Ramappa Subject: Re: [PATCH v2 00/10] Start fixing OA whitelist mistakes In-Reply-To: <20260408-oa-whitelist-cleanup-v2-0-db4a06aae8b0@intel.com> References: <20260408-oa-whitelist-cleanup-v2-0-db4a06aae8b0@intel.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.2 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-BeenThere: intel-xe@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel Xe graphics driver List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-xe-bounces@lists.freedesktop.org Sender: "Intel-xe" On Wed, 08 Apr 2026 16:42:59 -0700, Matt Roper wrote: > Hi Matt, > There are a number of mistakes in the OA register whitelists: > - Unlimited upper bounds (never allowed for whitelists entries!) > - Whitelisting registers that userspace already has access to > - Whitelisting registers that userspace is not intended to ever need > access to > > This series addresses the first two bullets and partially addresses the > third. For registers that weren't supposed to be exposed in the first > place, there are still some cases where we're exposing registers that we > really shouldn't be, or exposing them on engines that we shouldn't be, > but we need to confirm that no legitimate userspace has started > (mis)using them before making further changes so that we won't cause a > regression. > > This series also partially unmacro-izes some of the OA entries since the > several layers of C macros were obfuscating exactly what was/wasn't > being whitelisted and making it harder to audit for mistakes. Thanks for these patches, but at a high level, this series does *not* align with how we are planning to solve this problem (according to how we have been asked to do it by our architects). So changes in this series are simulatenously excessive, and also don't do the job. So our plan here is as follows: 1. No (or zero) OA registers will be whitlisted by default (after module probe). 2. OA registers will be whitelisted only when /proc/sys/dev/xe/observation_paranoid is 0. This file is 1 by default and sudo is needed to set it to 0. This means that OA registers will be whitelisted only with an explicit permission from root (or system admin, who is the final arbiter of system security). So that is the plan. We have just started this work and will send these patches when they are ready. We will also send patches for previous stable kernels if needed. Any help/patches for this work are also welcome :-) Regarding *this* series, my plan is to include patches from this series as needed, but after we have sent out the paranoid whitlisting series (or include them in the same series). But I don't want to take this series as is. If we implement the plan mentioned above, we don't have to finely control which registers are exposed, the precise product versions they are exposes for etc. All this will just increase maintenance overhead, whereas system admin control of whitelisting makes such fine tuning unnecessary. My current thinking is also to retain the current macros. Having cursorily looked at this series, the following patches are making sense to me: > drm/xe/oa: Stop whitelisting OAG_OASTATUS > drm/xe: Add WHITELIST_RO macro > drm/xe: Enable all FORCE_TO_NONPRIV registers But we'll have more clarity after the paranoid whitelisting work shapes up a little bit more (also I haven't looked at all the patches closely yet). I also had some similar patches lying around (waiting for us to make progress on paranoid whitelisting) and I just sent them out here: https://patchwork.freedesktop.org/series/164832/ Thanks. -- Ashutosh > > v2: > - Continue to whitelist OAGSAG's trigger since we've been allowing > userspace to access it on the "wrong" engine. Hardware only expects > the GSC engine to access this instance, so it doesn't automatically > grant VCS/VECS access. > - Eliminate whitelisting of OASTARTTRIG_COUNTER; this has never been a > valid register for userspace to have access to and was only > accidentally included due to improper use of a RANGE_4 flag. > - Consolidate oam_mmio_trg_vcs and oam_mmio_trg_vecs into a single > entry with a custom match function. > - Eliminate some layers of C macros to make it clear which registers > we're actually referencing. > > -- > 2.52.0 > > --- > Matt Roper (10): > drm/xe/oa: Stop whitelisting non-SAG MMIO_TRG registers on non-DG2 > drm/xe/oa: Stop whitelisting OAG_OASTATUS > drm/xe/oa: Stop whitelisting OAM registers on non Xe2/Xe3 > drm/xe/oa: Stop whitelisting OAG registers after Xe3 > drm/xe: Add WHITELIST_RO macro > drm/xe/oa: Consolidate RTP entries for OAM whitelist > drm/xe/oa: Consolidate RTP entries for OAG whitelist > drm/xe/oa: Consolidate RTP entries for OA MERT > drm/xe: Enable all FORCE_TO_NONPRIV registers > drm/xe/oa: Stop whitelisting OASTARTTRIG_COUNTER > > drivers/gpu/drm/xe/regs/xe_engine_regs.h | 7 +- > drivers/gpu/drm/xe/xe_reg_whitelist.c | 115 ++++++++++++++++++------------- > 2 files changed, 74 insertions(+), 48 deletions(-) > --- > base-commit: 9e217a8df7b2f298a2fd850e29f970b7360dc77b > change-id: 20260407-oa-whitelist-cleanup-21baae7fbb78 > > Best regards, > -- > Matt Roper > Graphics Software Engineer > Linux GPU Platform Enablement > Intel Corporation >