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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 34AAEC4332F for ; Fri, 9 Dec 2022 13:59:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229731AbiLIN7p (ORCPT ); Fri, 9 Dec 2022 08:59:45 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59258 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229580AbiLIN7n (ORCPT ); Fri, 9 Dec 2022 08:59:43 -0500 Received: from sin.source.kernel.org (sin.source.kernel.org [IPv6:2604:1380:40e1:4800::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7A5FC54778; Fri, 9 Dec 2022 05:59:42 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sin.source.kernel.org (Postfix) with ESMTPS id 35D8ACE2898; Fri, 9 Dec 2022 13:59:40 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 257B9C433EF; Fri, 9 Dec 2022 13:59:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1670594378; bh=YKyaVpqeCeqlnoMH5zjc8JmcTERpSzdvRksnhg86Hlk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=XSqMYnYFgFkdooVOqxjGblosYBPVpJZh+jjvBiZ+t2eiO+aNIJBCWIchLr4ioGdwF 3IxbYM2fIZ6HatHjXF7bFyQuDHhJeq/WWVjekztG20UXvNp60lK2II76IXayTvYcVA grzp69iGM2l1uBkzUuT3zeXtOFVxcQ833QE0IdcutyaG+KnM+YksxlIvCeuOnV+4kQ oWWB6tG1+n+uzDdt3gqmL6Wf5ILTZBnLLV9i9m+FivMxfbIHP3dOzQ8LVsn/1C6YQC hH75x2yzWEP97IraUdWZK+DOMkXzeHH1TkJEUNqw37oUZsjKntTNKUVVJa51dTi+XG 3XOy00JMK149A== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1p3duZ-00BbOT-LV; Fri, 09 Dec 2022 13:59:35 +0000 Date: Fri, 09 Dec 2022 13:59:35 +0000 Message-ID: <86bkocr83c.wl-maz@kernel.org> From: Marc Zyngier To: Jason Gunthorpe Cc: Alexander Gordeev , Alex Williamson , Lu Baolu , Christian Borntraeger , Cornelia Huck , David Woodhouse , Gerald Schaefer , Vasily Gorbik , Heiko Carstens , iommu@lists.linux.dev, Joerg Roedel , Kevin Tian , kvm@vger.kernel.org, linux-s390@vger.kernel.org, Robin Murphy , Suravee Suthikulpanit , Sven Schnelle , Thomas Gleixner , Will Deacon , Bharat Bhushan , Christian Borntraeger , Eric Auger , Eric Farman , Marc Zyngier , Matthew Rosato , Tomasz Nowicki , Will Deacon Subject: Re: [PATCH iommufd 1/9] irq: Add msi_device_has_secure_msi() In-Reply-To: <1-v1-9e466539c244+47b5-secure_msi_jgg@nvidia.com> References: <0-v1-9e466539c244+47b5-secure_msi_jgg@nvidia.com> <1-v1-9e466539c244+47b5-secure_msi_jgg@nvidia.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (aarch64-unknown-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-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: jgg@nvidia.com, agordeev@linux.ibm.com, alex.williamson@redhat.com, baolu.lu@linux.intel.com, borntraeger@linux.ibm.com, cohuck@redhat.com, dwmw2@infradead.org, gerald.schaefer@linux.ibm.com, gor@linux.ibm.com, hca@linux.ibm.com, iommu@lists.linux.dev, joro@8bytes.org, kevin.tian@intel.com, kvm@vger.kernel.org, linux-s390@vger.kernel.org, robin.murphy@arm.com, suravee.suthikulpanit@amd.com, svens@linux.ibm.com, tglx@linutronix.de, will@kernel.org, bharat.bhushan@nxp.com, borntraeger@de.ibm.com, eric.auger@redhat.com, farman@linux.ibm.com, marc.zyngier@arm.com, mjrosato@linux.ibm.com, tomasz.nowicki@caviumnetworks.com, will.deacon@arm.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-s390@vger.kernel.org On Thu, 08 Dec 2022 20:26:28 +0000, Jason Gunthorpe wrote: > > This will replace irq_domain_check_msi_remap() in following patches. > > The new API makes it more clear what "msi_remap" actually means from a > functional perspective instead of identifying an implementation specific > HW feature. > > Secure MSI means that an irq_domain on the path from the initiating device irq_domain is a SW construct, and you are trying to validate something that is HW property. "Secure" is also a terribly overloaded term that means very different things in non-x86 circles. When I read this, I see an ARM system with a device generating an MSI with the "secure" bit set as part of the transaction and identifying the memory access as being part of the "secure" domain. But that's not what you mean at all. > to the CPU will validate that the MSI message specifies an interrupt > number that the initiating device is authorized to trigger. Secure MSI > must block devices from triggering interrupts they are not authorized to > trigger. Currently authorization means the MSI vector is one assigned to > the device. What you are describing here is a *device isolation* property, and I'd rather we stay away from calling that "secure". If anything, I'd rather call everything else "broken". M. -- Without deviation from the norm, progress is not possible.