Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp151638pxj; Fri, 14 May 2021 00:01:50 -0700 (PDT) X-Google-Smtp-Source: ABdhPJznR5sI28NvlQot1n+8JKIxeQe9zIC0ujrjb5NPLM3tQfW8PqFmY3KKjkSlQ3LbvWn9cjIv X-Received: by 2002:a05:6e02:1aa5:: with SMTP id l5mr8979558ilv.289.1620975710123; Fri, 14 May 2021 00:01:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620975710; cv=none; d=google.com; s=arc-20160816; b=nswO3Iq1wWKRnmsCQOOmEcbB4bMa7Usr6RfhrVOAOSB6b9j9w53zEmtu3B4fSXGjPo wF08BnNuUysX0vAIGb7AAvjk0RMEgxaZx3MYvL6hmUbnj75cXLtzq4ELKVuLRF97Rvpk y4EUMPYi4r0tvyWj1nuZNjB/3WAY8fMBLhO40Sva6dD3HNEVCoscv2KZxAl7IroP6wlA /IXGhYtYhc6b0sS3FtML0K+ozzdKJWBUX/JhYOS3JiBgUvd4fCJa2d/jk3jDfAXHQ5Lz nFJ/+zhEY1a8+vbUkNIRgm/IYm/olOdfjPyw2fCFuaELptudaonkrnnDCu1ticbhdsMy bu5Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :message-id:subject:cc:to:from:date:dkim-signature; bh=SYndytl5RVRks/90LNhvdT0vorY2evEaOkyJVKhVz4c=; b=FJf3Dxf6YYBxwqDQBPOt2OkTgDsKTwBLaVAt8b9Z8ecWWAP0vMhZjYVH/X/9v9rbNd pfyV4PVXIYdN60Up9sod5fxZl4pc8XeefQVNXbYel9wkUFEFBliETzZOMUm3AJk9xPmN PsvutpEKuzdMGmU/Fm5oo/MmXjWPipMy1T7HBgyrx3qJwJ1SvcaCByVx8SkykqbvoO1R qgZBTRUXR99/QNDhsnaLHhwkDrgA1rvQUF2nmvHjiVrQ7XsofE6mH4jQIWQU+JMIOELY e+svW0l1eYjWFzDgdaM3RXwRMoiPijZVPPjpKwXdtcqTDwJc0ULQRChEIcIN/WYNDl1f JfRQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=S8aZH569; 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=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id o1si6844811jat.48.2021.05.14.00.01.37; Fri, 14 May 2021 00:01:50 -0700 (PDT) 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=@kernel.org header.s=k20201202 header.b=S8aZH569; 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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232406AbhEMUHD (ORCPT + 99 others); Thu, 13 May 2021 16:07:03 -0400 Received: from mail.kernel.org ([198.145.29.99]:39456 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232389AbhEMUHC (ORCPT ); Thu, 13 May 2021 16:07:02 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id B307161421; Thu, 13 May 2021 20:05:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1620936352; bh=8T+J3wCXI/e4i0Nq0qkxzfPcgMyR9DsieXzCu8AyHN4=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=S8aZH569dpHyPV1WO9KYLvi5aeA4T/Bi2TDTlr76AqbK7Lss5y8R7nzoaJvXSoh8v AlAi/al1uKP6LoN6pTwS+Dbd6rny3YwO5cDVtK1DC74Fqv/ejJqOwgF/af3d4oE08o QT5DjPJ4GXOAagBrMiKykL58ii3A2EuFPFGuP2FPjdcq83lgS/0Km5N2cUzZDp8x4B Wj/GXNjZ41PLmuXelRojpihdaXt+o7+yWC2ioTg6vHAOdFxv15DcQ8SCFDXt4veoBE 1EbsXRaHuYonUI6rnefgLjRpu8TUsLMKo32FB/NTxKi1JdqUbijoRwEHgkljkpOZw5 5M9uuGP7jhqrg== Date: Thu, 13 May 2021 15:05:50 -0500 From: Bjorn Helgaas To: Rajat Jain Cc: Greg Kroah-Hartman , "Rafael J. Wysocki" , Bjorn Helgaas , Alan Stern , Linux Kernel Mailing List , linux-pci , "open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:" , Oliver Neukum , David Laight , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Rajat Jain , Jesse Barnes , Dmitry Torokhov Subject: Re: [PATCH v3 2/2] PCI: Add sysfs "removable" attribute Message-ID: <20210513200550.GA2604592@bjorn-Precision-5520> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 13, 2021 at 11:02:10AM -0700, Rajat Jain wrote: > On Wed, May 12, 2021 at 2:35 PM Rajat Jain wrote: > > > > A PCI device is "external_facing" if it's a Root Port with the ACPI > > "ExternalFacingPort" property or if it has the DT "external-facing" > > property. We consider everything downstream from such a device to > > be removable by user. > > > > We're mainly concerned with consumer platforms with user accessible > > thunderbolt ports that are vulnerable to DMA attacks, and we expect those > > ports to be identified as "ExternalFacingPort". Devices in traditional > > hotplug slots can technically be removed, but the expectation is that > > unless the port is marked with "ExternalFacingPort", such devices are less > > accessible to user / may not be removed by end user, and thus not exposed > > as "removable" to userspace. s/thunderbolt/Thunderbolt/ since I think it's a trademark s/identified as/identified by firmware as/ > > Set pci_dev_type.supports_removable so the device core exposes the > > "removable" file in sysfs, and tell the device core about removable > > devices. > > > > This can be used by userspace to implment any policies it wants to, > > tailored specifically for user removable devices. Eg usage: > > https://chromium-review.googlesource.com/c/chromiumos/platform2/+/2591812 > > https://chromium-review.googlesource.com/c/chromiumos/platform2/+/2795038 > > (code uses such an attribute to remove external PCI devicces or disable > > features on them as needed by the policy desired) s/implment/implement/ s/devicces/devices/ Or maybe something like: This can be used to implement userspace policies tailored for user-removable devices. Not sure exactly what "remove external PCI devices" means. You're talking about the *code* doing something, so I don't think it means physically unplugging the device from the system. Maybe preventing a driver from binding to it or something similar? I hesitate slightly to rely on URLs like googlesource.com in commit logs because we don't know how long they will remain valid. But I guess there's no real alternative here, since this code probably hasn't been posted to any public mailing lists like the ones archived at https://lore.kernel.org/lists.html, right? > > Signed-off-by: Rajat Jain > > +static void pci_set_removable(struct pci_dev *dev) > > +{ > > + struct pci_dev *parent = pci_upstream_bridge(dev); > > + if (parent && > > + (parent->external_facing || dev_is_removable(&parent->dev))) > > + dev_set_removable(&dev->dev, DEVICE_REMOVABLE); > > + else > > + dev_set_removable(&dev->dev, DEVICE_FIXED); > > +} > > Copying comments from Krzysztof from another thread: > > [Krzysztof] We were also wondering if we should only set DEVICE_REMOVABLE for > devices known to be behind an external-facing port, and let everything > else be set to "unknown" (or whatever the default would be). > > [Rajat]: I think I'm fine with this proposal if Bjorn & PCI community > also sees this as a better idea. Essentially the question here is, > would it be better for the non-removable PCI devices to be shown as > "fixed" or "unknown"? I think I would rather see this as: struct pci_dev *parent = pci_upstream_bridge(dev); if (parent && (parent->external_facing || dev_is_removable(&parent->dev))) dev_set_removable(&dev->dev, DEVICE_REMOVABLE); In other words, assume only that everything below an "external-facing" device is removable. In the absence of an "external-facing" property, we don't know anything about the connection, and I'd rather use the default (probably "unknown") instead of assuming "fixed." I don't think we have anything that depends on "fixed," so I don't think there's value in setting it. (Note the blank line between local variables and the "if"; maybe that's what Greg hinted at?) Bjorn