)]}'
{
  "commit": "9cb024806610b9e57d97ace0709661f5e308d7f2",
  "tree": "fd86ad602d40c494a4a677d20061100354ee665d",
  "parents": [
    "5a3bd0c8972b19accda8b84476ddf776390b0a05"
  ],
  "author": {
    "name": "Dan Williams",
    "email": "dan.j.williams@intel.com",
    "time": "Wed Nov 12 11:29:12 2025 -0800"
  },
  "committer": {
    "name": "Dan Williams",
    "email": "dan.j.williams@intel.com",
    "time": "Fri Nov 14 15:08:15 2025 -0800"
  },
  "message": "device core: Introduce confidential device acceptance\n\nOf the many problems to solve with PCIe Trusted Execution Environment\nDevice Interface Security Protocol (TDISP) support, this is among the most\nfraught. New device core infrastructure demands a high degree of scrutiny\nespecially when touching the long standing kernel policy that the kernel\ntrusts devices by default. Previous adjacent proposals in this space (e.g.\ndevice filter, no bounce buffer flag...) have not moved forward.\n\nSo, what is this new \u0027struct device_private\u0027 mechanism, how is it different\nfrom previous attempts, and why not a bus-device-type specific mechanism\n(e.g.  pci_dev::untrusted, usb_device::authorized, tb_switch::authorized,\netc...)?\n\nTEE acceptance is not a state that random modules should be allowed to\nchange in the common case. A device entering the accepted state is a\nviolent operation. Pre-existing MMIO and DMA mappings can not survive this\nevent. The device_cc_accept() and device_cc_reject() helpers (where \"cc\" \u003d\u003d\n\"confidential computing\") coordinate with driver attachment and are only\nmeant for core-kernel bus drivers like the PCI core.\n\nFor drivers the default expectation is unenlightened. I.e. drivers that are\nidentical to the non-TDISP case. There are however cases where the device\nneeds a driver to perform configuration prior to userspace performing the\nlock+accept operations to shift the device into operation within the TCB.\nFor that case an enlightened driver needs the ability to determine if the\ndevice is already \"lock+accept\" ready. The device_cc_probe() interface\nexists for that check.\n\nWhen the device enters the TEE, other subsystems need to behave\ndifferently. For example, the IOMMU/DMA mapping subsystem needs to switch\nDMA mapping requests from SWIOTLB bounce buffering to direct-DMA to private\nmemory. That device state is communicated via device_cc_accepted() in a\ncommon way.\n\nThe observation is that PCI is not the only bus that has designs on\ninteracting with a TEE acceptance state. The \"adjacent proposals\" mentioned\nbefore include platform firmware and embedded buses that want to accept\ndevices into the TEE. A bus-type-specific flag would be an ongoing\nmaintenance burden for each new bus that adds TEE acceptance support.\n\nCc: Christoph Hellwig \u003chch@lst.de\u003e\nCc: Jason Gunthorpe \u003cjgg@ziepe.ca\u003e\nCc: Marek Szyprowski \u003cm.szyprowski@samsung.com\u003e\nCc: Robin Murphy \u003crobin.murphy@arm.com\u003e\nCc: Roman Kisel \u003cromank@linux.microsoft.com\u003e\nCc: Bjorn Helgaas \u003cbhelgaas@google.com\u003e\nCc: Samuel Ortiz \u003csameo@rivosinc.com\u003e\nCc: Alexey Kardashevskiy \u003caik@amd.com\u003e\nCc: Xu Yilun \u003cyilun.xu@linux.intel.com\u003e\nCc: \"Aneesh Kumar K.V\" \u003caneesh.kumar@kernel.org\u003e\nCc: Greg Kroah-Hartman \u003cgregkh@linuxfoundation.org\u003e\nCc: \"Rafael J. Wysocki\" \u003crafael@kernel.org\u003e\nCc: Danilo Krummrich \u003cdakr@kernel.org\u003e\nSigned-off-by: Dan Williams \u003cdan.j.williams@intel.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "1786d87b29e227e2b6e8ecb4a0ece00be34f37fe",
      "old_mode": 33188,
      "old_path": "drivers/base/Kconfig",
      "new_id": "d4743bf978ec1f25c34090e6b4b0b2bffacdefc7",
      "new_mode": 33188,
      "new_path": "drivers/base/Kconfig"
    },
    {
      "type": "modify",
      "old_id": "8074a10183dcb720a6b820b8476b230716b37f01",
      "old_mode": 33188,
      "old_path": "drivers/base/Makefile",
      "new_id": "e11052cd52533c8ce0b466a92e3e4403dcc81c8a",
      "new_mode": 33188,
      "new_path": "drivers/base/Makefile"
    },
    {
      "type": "modify",
      "old_id": "cd5f2cdd281c117f44c258e16e6504a32c2098c1",
      "old_mode": 33188,
      "old_path": "drivers/base/base.h",
      "new_id": "d9d5b8e3cc2a4d63e9090bdd9a79a33eda91d7a3",
      "new_mode": 33188,
      "new_path": "drivers/base/base.h"
    },
    {
      "type": "add",
      "old_id": "0000000000000000000000000000000000000000",
      "old_mode": 0,
      "old_path": "/dev/null",
      "new_id": "d7cd0a253071fecd626c1977707ad5137f058b8e",
      "new_mode": 33188,
      "new_path": "drivers/base/coco.c"
    },
    {
      "type": "modify",
      "old_id": "b031ff71a5bdfe9161074ca245d986a4be4c98fa",
      "old_mode": 33188,
      "old_path": "include/linux/device.h",
      "new_id": "260b3aedd6539b44c50c7701c43e4d5e8e82ee11",
      "new_mode": 33188,
      "new_path": "include/linux/device.h"
    }
  ]
}