![[BACK]](/icons/back.gif){kind=icon}
Up to [cvs.NetBSD.org] / src / sys / external / bsd / common / include / linux
Request diff between arbitrary revisions
Keyword substitution: kv
Default branch: MAIN
Pull up following revision(s) (requested by rin in ticket #928): sys/external/bsd/drm2/dist/drm/drm_gem.c: revision 1.25 sys/external/bsd/drm2/dist/drm/radeon/radeon_ci_dpm.c: revision 1.7 sys/external/bsd/drm2/dist/drm/nouveau/nvkm/engine/device/priv.h: revision 1.4 sys/external/bsd/drm2/dist/drm/nouveau/nvkm/engine/device/nouveau_nvkm_engine_device_acpi.c: revision 1.4 sys/external/bsd/drm2/dist/drm/i915/display/intel_opregion.h: revision 1.6 sys/external/bsd/drm2/dist/drm/i915/i915_drv.h: revision 1.49 sys/external/bsd/drm2/include/linux/mxm-wmi.h: revision 1.1 sys/external/bsd/drm2/dist/drm/nouveau/nvkm/subdev/pci/nouveau_nvkm_subdev_pci_pcie.c: revision 1.4 sys/external/bsd/drm2/dist/drm/nouveau/nvkm/engine/device/nouveau_nvkm_engine_device_base.c: revision 1.13 sys/external/bsd/common/include/linux/bitops.h: revision 1.17 sys/external/bsd/drm2/nouveau/files.nouveau: revision 1.40 sys/external/bsd/drm2/linux/linux_pci.c: revision 1.30 sys/external/bsd/drm2/dist/drm/radeon/radeon_drv.h: revision 1.5 sys/external/bsd/drm2/dist/drm/nouveau/nvkm/subdev/pci/nouveau_nvkm_subdev_pci_pcie.c: revision 1.5 sys/external/bsd/drm2/dist/drm/nouveau/nvkm/subdev/mxm/nouveau_nvkm_subdev_mxm_base.c: revision 1.5 sys/external/bsd/drm2/dist/drm/amd/amdgpu/amdgpu_gart.c: revision 1.12 sys/external/bsd/drm2/dist/drm/radeon/radeon_rv770.c: revision 1.3 sys/external/bsd/drm2/dist/drm/nouveau/nvkm/engine/disp/nouveau_nvkm_engine_disp_sorgm200.c: revision 1.3 sys/external/bsd/common/include/linux/printk.h: revision 1.14 sys/external/bsd/drm2/dist/drm/nouveau/nvkm/subdev/instmem/nouveau_nvkm_subdev_instmem_gk20a.c: revision 1.10 sys/external/bsd/drm2/dist/drm/amd/amdgpu/amdgpu_vi.c: revision 1.4 sys/external/bsd/drm2/include/linux/acpi.h: revision 1.11 sys/external/bsd/drm2/drm/drm_cdevsw.c: revision 1.31 sys/external/bsd/drm2/dist/drm/radeon/radeon_si.c: revision 1.6 sys/external/bsd/drm2/dist/drm/nouveau/nouveau_acpi.c: revision 1.5 sys/external/bsd/drm2/dist/drm/i915/display/intel_acpi.h: revision 1.5 sys/external/bsd/drm2/include/acpi/video.h: revision 1.3 sys/external/bsd/drm2/dist/drm/radeon/radeon_evergreen.c: revision 1.6 sys/external/bsd/drm2/dist/drm/nouveau/nouveau_acpi.h: revision 1.4 sys/arch/sparc64/include/pci_machdep.h: revision 1.31 sys/arch/sparc64/dev/pci_machdep.c: revision 1.83 sys/external/bsd/drm2/include/linux/kref.h: revision 1.14 sys/external/bsd/drm2/dist/drm/nouveau/nvkm/engine/device/nouveau_nvkm_engine_device_pci.c: revision 1.12 sys/external/bsd/drm2/linux/linux_dma_buf.c: revision 1.17 sys/external/bsd/drm2/dist/drm/nouveau/nvkm/subdev/bios/nouveau_nvkm_subdev_bios_shadowacpi.c: revision 1.4 sys/external/bsd/drm2/drm/drm_module.c: revision 1.32 sys/external/bsd/drm2/dist/drm/i915/i915_gem.h: revision 1.8 sys/external/bsd/drm2/dist/drm/i915/gem/i915_gem_dmabuf.c: revision 1.7 sys/external/bsd/drm2/include/linux/smp.h: revision 1.5 sys/external/bsd/drm2/dist/drm/amd/amdgpu/amdgpu_si.c: revision 1.5 sys/external/bsd/drm2/dist/drm/amd/amdgpu/amdgpu_device.c: revision 1.20 sys/arch/x86/x86/bus_dma.c: revision 1.91 sys/external/bsd/drm2/radeon/files.radeon: revision 1.40 sys/external/bsd/drm2/include/acpi/acpi_bus.h: revision 1.1 sys/external/bsd/drm2/dist/drm/nouveau/nouveau_drv.h: revision 1.5 sys/external/bsd/drm2/dist/drm/amd/amdgpu/amdgpu_device.c: revision 1.21 sys/external/bsd/common/include/asm/barrier.h: revision 1.20 sys/external/bsd/drm2/include/linux/nbsd-namespace-acpi.h: revision 1.2 sys/external/bsd/common/include/asm/barrier.h: revision 1.21 sys/modules/drmkms/drmkms_pci.h: revision 1.1 sys/external/bsd/drm2/dist/drm/drm_dp_helper.c: revision 1.17 sys/external/bsd/drm2/radeon/radeon_pci.c: revision 1.23 sys/external/bsd/drm2/linux/linux_xa.c: revision 1.4 sys/external/bsd/drm2/ttm/ttm_bo_vm.c: revision 1.23 sys/external/bsd/drm2/ttm/ttm_bo_vm.c: revision 1.24 sys/external/bsd/drm2/ttm/ttm_bo_vm.c: revision 1.25 sys/external/bsd/drm2/linux/linux_pci.c: revision 1.26 sys/dev/pci/pcivar.h: revision 1.120 sys/arch/xen/include/pci_machdep.h: revision 1.24 sys/external/bsd/drm2/ttm/ttm_bo_vm.c: revision 1.26 sys/external/bsd/drm2/linux/linux_pci.c: revision 1.27 sys/external/bsd/drm2/ttm/ttm_bo_vm.c: revision 1.27 sys/external/bsd/drm2/linux/linux_pci.c: revision 1.28 sys/external/bsd/drm2/dist/drm/radeon/radeon_cik.c: revision 1.8 sys/external/bsd/drm2/ttm/ttm_bo_vm.c: revision 1.28 sys/external/bsd/drm2/linux/linux_pci.c: revision 1.29 sys/external/bsd/drm2/include/linux/pci.h: revision 1.57 sys/external/bsd/drm2/include/linux/pci.h: revision 1.58 sys/external/bsd/drm2/dist/drm/radeon/radeon_acpi.c: revision 1.5 sys/external/bsd/drm2/dist/drm/nouveau/nouveau_display.c: revision 1.6 sys/external/bsd/drm2/dist/drm/amd/powerplay/hwmgr/amdgpu_hwmgr.c: revision 1.3 sys/external/bsd/drm2/dist/drm/amd/display/dc/core/amdgpu_dc_stream.c: revision 1.3 share/man/man9/bus_dma.9: revision 1.69 sys/external/bsd/drm2/drm/drm_gem_cma_helper.c: revision 1.15 sys/external/bsd/drm2/dist/drm/radeon/radeon_acpi.c: revision 1.6 sys/external/bsd/drm2/dist/drm/radeon/radeon.h: revision 1.12 sys/external/bsd/drm2/dist/drm/amd/amdgpu/amdgpu_cik.c: revision 1.7 sys/dev/acpi/acpi_mcfg.c: revision 1.29 sys/external/bsd/drm2/dist/drm/amd/amdgpu/amdgpu_acpi.c: revision 1.6 sys/external/bsd/drm2/dist/drm/radeon/radeon_r600.c: revision 1.7 sys/external/bsd/drm2/dist/drm/radeon/radeon_bios.c: revision 1.13 sys/modules/amdgpu/Makefile: revision 1.9 sys/external/bsd/drm2/dist/drm/radeon/radeon_bios.c: revision 1.14 sys/external/bsd/common/linux/linux_tasklet.c: revision 1.12 sys/external/bsd/drm2/dist/drm/nouveau/include/nvkm/core/device.h: revision 1.10 sys/external/bsd/drm2/dist/drm/i915/gem/i915_gem_mman.c: revision 1.23 sys/external/bsd/drm2/dist/drm/amd/amdgpu/amdgpu.h: revision 1.9 sys/external/bsd/drm2/include/linux/interval_tree.h: revision 1.14 sys/external/bsd/drm2/dist/drm/i915/gem/i915_gem_mman.c: revision 1.26 sys/external/bsd/drm2/dist/drm/amd/powerplay/hwmgr/amdgpu_smu7_hwmgr.c: revision 1.5 sys/dev/pci/pci.c: revision 1.168 sys/external/bsd/drm2/dist/drm/i915/gem/i915_gem_mman.c: revision 1.27 sys/external/bsd/drm2/dist/drm/radeon/radeon_si_dpm.c: revision 1.9 sys/external/bsd/drm2/pci/files.drmkms_pci: revision 1.18 sys/external/bsd/drm2/linux/linux_sync_file.c: revision 1.3 sys/external/bsd/drm2/amdgpu/files.amdgpu: revision 1.31 sys/external/bsd/drm2/dist/drm/nouveau/nvkm/engine/device/nouveau_nvkm_engine_device_tegra.c: revision 1.4 sys/external/bsd/drm2/dist/drm/drm_gem.c: revision 1.24 sys/arch/xen/xen/xpci_xenbus.c: revision 1.29 drm: Eliminate __HAVE_ATOMIC_AS_MEMBAR conditionals. Discussed on tech-kern: https://mail-index.netbsd.org/tech-kern/2023/02/23/msg028729.html linux asm/barrier.h: Fix !MULTIPROCESSOR build. remove "nouveau" from a comment. noted by jmcneill. drm: KASSERT(A && B) -> KASSERT(A); KASSERT(B) comment a function that has a clear overbounds read but it isn't used. found by GCC 12. nix the NetBSD specific GEM_BUG_ON(). avoids GCC 12 warnings, and matches upstream closer. avoid uninitialised variable usage in drm_gem_cma_create_internal(). in the case nothing has returned 'error', 'nsegs' and the dma info are (potentially) uninitialised, so consider this an error. found by GCC 12. avoid a GCC 12 warning. there's a 1-element long array and a loop conditional that tries to see if indexes for it are not identical. as these indexes will always both be 0, the only valid index, the condition is always false. GCC 12 triggers a strange warning on this code that can never run (see below), so simply assert the array size is 1 and comment the rest. amdgpu_dc_stream.c:470:55: error: array subscript [0, 0] is outside array bounds of 'struct dc_writeback_info[1]' [-Werror=array-bounds] 470 | stream->writeback_info[j] = stream->writeback_info[i]; convert a KASSERT() into an if () panic() sequence to appease GCC 12. OK riastradh@. drm: Fix conditionals around drmkms_pci and agp. Kernel should build now with all pci drm drivers stripped out but DRM_LEGACY still enabled. (Might not be very useful, but it'll build. Maybe we should also have DRM_LEGACY_PCI so those drivers can be modloaded later.) drmkms: Fix module build. avoid an unlikely array bounds issue picked up by GCC 12. nvkm_pcie_speed() can return -1, which is then used as an array index, so make this default return PCIe 1.0 speeds. drm: enable almost all PCIe functionality linux_pci.c revisions 1.24 and 1.25 implemented most of the remaining missing PCIe backends, but only enabled them for some amdgpu portions. this enables all code marked with "XXX amdgpu pcie", "XXX radeon pcie", and "XXX pcie speed". for most of it, simply removing #ifndefs __NetBSD__ to enable compliation was required, once the new "bus->max_bus_speed" member was added to struct pci_bus. add an "always fails" backend for pci_enable_atomic_ops_to_root() which seems to only be necessary for virtual GPU functionality (and could be implemented if needed.) tested on radeon 5450, 7750, R7 240 [radeon], and RX 550 [amdgpu], and nvidia 750 and 1030 [nouveau]. this still does not quite work on nvidia cards. there are two problems that remain: - the call to set the link speed is skipped because the speed is set to the default value of "-1". nvkm_pcie_set_link() will actually determine the right value for this and for some cards, calling this function if the current speed is -1 helps set the link speed. it may be that on linux other paths we don't have enabled properly would set this (there's one via debugfs, and a jetson specific one, though perhaps setting either AC or DC speed values as boot options (after hooking up these for netbsd) would currently work. - worse, cards newer than kepler - geforce 900, 1000, and newer, are all lacking the backing support to set pcie link speed. the GT 1030 card i have been testing with remains at pcie 1.0. radeon: fix and enable ACPI methods for getting ROM BIOS The hacky way of getting the BIOS mapped only works on x86. ACPI should be preferred if available. Makes BIOS reading though VFCT work on aarch64 with EDK2. (But only if EDK2 has POSTed the GPU.) XXX amdgpu should get the same treatment. drm: put_cpu() should enable preemption, not disable it again drm(4): make pr_debug equivalent to aprint_debug significantly reduces the default spam from amdgpu(4). drm: Set CONFIG_ACPI in linux/acpi.h and make it build. Leave a little ACPI-related functionality disabled for now, like getting EDID out of ACPI -- needs a bit more work to make this work, and I don't have hardware to work on that. Should help with failures of the forms: - unable to locate a BIOS ROM - bios: unable to locate usable image on various machines. radeon_acpi.c: ifdef out unused function on NetBSD. Should fix syzkaller build. drm(4): Fix st_rdev in stat. dminor->index already has the 64*type adjustment, as allocated in drm_minor_alloc. PR kern/58180 linux_sync_file: Fix missing init/fini steps. Noted by rjs@. PR kern/58210 ttm: Sync ttm_bo_uvm_fault_idle better with Linux. PR xsrc/58133 ttm: Undo mistake in previous. PR xsrc/58133 linux: Add a few more cases to pci_get_class. Should fix crash on boot with amdgpu now that the ACPI business is enabled. i915: Fix dmabuf mmap object. drm: Fix missing bounds checks in dma buf mmap. drm_gem.c: Fix sense of assertion. This is the opposite of WARN_ON. Noted by rjs@. drm_gem.c: Enable drm_gem_fence_array_add now that we emulate xa. linux_xa: Delete and replace collision in xa_store as intended. Don't free the colliding node that's still in the tree. Noted by rjs@. i915_gem_mman.c: Apply mmap types via pmap flags. This way, userland gets buffers mapped write-combining or uncached as needed. PR xsrc/58307 x86: Teach bus_dmamem_map about BUS_DMA_PREFETCHABLE. PR port-amd64/58308 bus_dma(9): Document BUS_DMA_PREFETCHABLE. Like BUS_DMA_NOCACHE. Doesn't absolve you of the need for bus_dmamap_sync, but if you later pass the vaddr to bus_dmamap_load, the DMA map might notice the mapping is write-combining and use this to make bus_dmamap_sync cheaper. PR kern/58309 nouveau_nvkm_subdev_instmem_gk20a.c: Use BUS_DMA_PREFETCHABLE. Matches Linux's pgprot_writecombine. Unclear where the appropriate bus_dmamap_sync happens, or is supposed to happen -- not using it would be wrong, but asking for a prefetchable mapping may paper over symptoms, at least! ttm: Sync more with Linux. Add the original copyright and attribution since this is now, intentionally, a modified copy of the original and not just roughly the same algorithm. ttm: Respect PGO_ALLPAGES. Not sure this is useful but it reduces XXX's and makes this match udv_fault better so it's easier to understand. ttm: Sync cacheability flag logic with Linux. ttm: Add XXX about readahead fault failures. pci: Pass cookie through pci_find_device, pci_enumerate_bus, take 2. New functions pci_find_device1 and pci_enumerate_bus1 have the cookie argument. Existing symbols pci_find_device and pci_enumerate_bus are now wrappers for the cookieless version. This will allow pci_find_device callers to pass a cookie through to the match function so they can keep state or pass in extra parameters like b/d/f numbers, which will allow us to nix some horrible kludges in the Linux PCI API emulation for drm (and, perhaps, Intel wifi). This change drops the symbol pci_probe_device, in favour of a new pci_probe_device1 with the cookie argument. But I don't think that requires a revbump because it's only called by MD pci_enumerate_bus1 implementations, which don't live in modules anyway. Take 2: Make sure to handle NULL match function. linux_pci: Nix pci enumeration kludges. Now that we can pass a cookie through, this stuff will be a little less fragile. i915: Omit needless i915_gem_object_pin/unpin_pages cycle in fault. vm_fault_cpu and vm_fault_gtt, called by i915_gem_fault, already do the pinning and unpinning internally, so there is no need for i915_gem_fault to do it. No functional change intended, except that the transient pin count will be one lower than before during the fault routine (but it will still be positive). i915: Match Linux fault routine return code actions. Omit needless EINTR interception -- this is now handled by i915_error_to_vmf_fault. Earlier revert was over a false alarm -- bisection shows the new warnings arose from linux_pci.c 1.29 here: https://mail-index.netbsd.org/source-changes/2024/06/23/msg151929.html linux_pci: Fix shifto in pci_get_class. It looks like Linux's pci_get_class also matches the interface part of the PCI class register (but not the revision part), and I hadn't noticed that in the previous shim structured differently. With GCC12 kernel ALL/amd64 triggers "'sor' may be used uninitialized". If "sublinks & 3" is zero GCC is right and sor[1] may be returned unitialized. Fix by initializing "sor" to zero to return -1 instead of uninitialized value. Ok: Taylor R Campbell <riastradh@> amdgpu: Map BAR 2, not BAR 5, on pre-bonaire chips. PR kern/58384 amdgpu: Map consecutive pages, not the same one over and over again. PR kern/58385 linux/bitops: Fix overestimate for BITS_TO_LONGS(9) Fortunately, this seems harmless except for allocating excessive buffer memory. Pointed out by nonaka@, OK riastradh@.
linux/bitops: Fix overestimate for BITS_TO_LONGS(9) Fortunately, this seems harmless except for allocating excessive buffer memory. Pointed out by nonaka@, OK riastradh@.
Move Linux atomic bitops from linux/atomic.h to linux/bitops.h.
provide BITS_PER_TYPE Author: Maya Rashish <maya@NetBSD.org>
Add a BIT_MASK in bits.h, move it to common so bitops.h can sideload match linux. Author: Maya Rashish <maya@NetBSD.org>
define BITS_PER_LONG. use compiler-defined macro instead of sizeof. Author: Maya Rashish <maya@NetBSD.org>
Remove duplicate definition of BITS_PER_BYTE Author: Maya Rashish <maya@NetBSD.org>
sign_extend64, GENMASK_ULL, for_each_clear_bit
Add BITS_PER_BYTE and BIT_ULL. Fix type of BIT.
Merge changes from current as of 20200406
Pull up following revision(s) (requested by maya in ticket #548): sys/external/bsd/drm2/dist/drm/i915/intel_display.c: revision 1.28 sys/external/bsd/drm2/dist/drm/i915/i915_drv.h: revision 1.30 sys/external/bsd/common/include/linux/bitops.h: revision 1.9 sys/external/bsd/drm2/dist/drm/i915/intel_drv.h: revision 1.11 sys/external/bsd/drm2/dist/drm/i915/i915_gem_gtt.h: revision 1.8 sys/external/bsd/drm2/dist/drm/i915/i915_gem_gtt.c: revision 1.16 sys/external/bsd/drm2/dist/drm/i915/i915_gem_execbuffer.c: revision 1.9 sys/external/bsd/drm2/dist/drm/i915/i915_dma.c: revision 1.28 sys/external/bsd/drm2/dist/drm/i915/i915_cmd_parser.c: revision 1.19 sys/external/bsd/drm2/dist/drm/i915/intel_pm.c: revision 1.20 sys/external/bsd/drm2/dist/drm/i915/intel_ringbuffer.c: revision 1.11 sys/external/bsd/drm2/dist/drm/i915/intel_ringbuffer.h: revision 1.7 sys/external/bsd/drm2/dist/drm/i915/i915_reg.h: revision 1.14 sys/external/bsd/drm2/dist/drm/i915/i915_cmd_parser.c: revision 1.20 sys/external/bsd/drm2/dist/drm/i915/i915_gem_context.c: revision 1.10 sys/external/bsd/drm2/dist/drm/i915/i915_drv.c: revision 1.17 Add what appears to be the fixes to CVE-2019-0154, CVE-2019-0155. This commit requires review, but I'd also like it to be tested by others while it is being reviewed. CVE-2019-0155: It was discovered that the Intel i915 graphics chipsets allowed userspace to modify page table entries via writes to MMIO from the Blitter Command Streamer and expose kernel memory information. A local attacker could use this to expose sensitive information or possibly elevate privileges. CVE-2019-0154: It was discovered that the Intel i915 graphics chipsets could cause a system hang when userspace performed a read from GT memory mapped input output (MMIO) when the product is in certain low power states. A local attacker could use this to cause a denial of service. From upstream commits to linux-4.4.y: ------------------- From 6d0cfddc7afc715835f0e17827106f832b14dd2a Mon Sep 17 00:00:00 2001 From: Jon Bloomfield <jon.bloomfield%intel.com@localhost> Date: Thu, 12 Jul 2018 19:53:10 +0100 Subject: [PATCH] drm/i915/gtt: Add read only pages to gen8_pte_encode We can set a bit inside the ppGTT PTE to indicate a page is read-only; writes from the GPU will be discarded. We can use this to protect pages and in particular support read-only userptr mappings (necessary for importing PROT_READ vma). ------------------- From 774b68aa2105c70b40c3b1777feb7ab500d716dd Mon Sep 17 00:00:00 2001 From: Jon Bloomfield <jon.bloomfield%intel.com@localhost> Date: Mon, 6 Aug 2018 14:10:48 -0700 Subject: [PATCH] drm/i915/gtt: Read-only pages for insert_entries on bdw+ Hook up the flags to allow read-only ppGTT mappings for gen8+ v2: Include a selftest to check that writes to a readonly PTE are dropped v3: Don't duplicate cpu_check() as we can just reuse it, and even worse don't wholesale copy the theory-of-operation comment from igt_ctx_exec without changing it to explain the intention behind the new test! v4: Joonas really likes magic mystery values ------------------- From 3fd1c2e65c60c1c513155e1d1d74138b141aa8a3 Mon Sep 17 00:00:00 2001 From: Chris Wilson <chris%chris-wilson.co.uk@localhost> Date: Thu, 12 Jul 2018 19:53:12 +0100 Subject: [PATCH] drm/i915/gtt: Disable read-only support under GVT GVT is not propagating the PTE bits, and is always setting the read-write bit, thus breaking read-only support. ------------------- From e5e3c0154c19f2d8213e0af88b7a10d9de7fbafd Mon Sep 17 00:00:00 2001 From: Jon Bloomfield <jon.bloomfield%intel.com@localhost> Date: Fri, 20 Apr 2018 14:26:01 -0700 Subject: [PATCH] drm/i915: Rename gen7 cmdparser tables We're about to introduce some new tables for later gens, and the current naming for the gen7 tables will no longer make sense. v2: rebase ------------------- From 3122671a5df3ee13f5cf22b7bdacf422b7b4319a Mon Sep 17 00:00:00 2001 From: Jon Bloomfield <jon.bloomfield%intel.com@localhost> Date: Fri, 8 Jun 2018 08:53:46 -0700 Subject: [PATCH] drm/i915: Disable Secure Batches for gen6+ Retroactively stop reporting support for secure batches through the api for gen6+ so that older binaries trigger the fallback path instead. Older binaries use secure batches pre gen6 to access resources that are not available to normal usermode processes. However, all known userspace explicitly checks for HAS_SECURE_BATCHES before relying on the secure batch feature. Since there are no known binaries relying on this for newer gens we can kill secure batches from gen6, via I915_PARAM_HAS_SECURE_BATCHES. v2: rebase (Mika) v3: rebase (Mika) ------------------- From 544fd7d9d4cfe32357beab2f1dc543637d42e69f Mon Sep 17 00:00:00 2001 From: Jon Bloomfield <jon.bloomfield%intel.com@localhost> Date: Fri, 8 Jun 2018 10:05:26 -0700 Subject: [PATCH] drm/i915: Remove Master tables from cmdparser The previous patch has killed support for secure batches on gen6+, and hence the cmdparsers master tables are now dead code. Remove them. ------------------- From 17e89f38212d8b3cba470efca91b997ac03c592c Mon Sep 17 00:00:00 2001 From: Jon Bloomfield <jon.bloomfield%intel.com@localhost> Date: Wed, 1 Aug 2018 09:33:59 -0700 Subject: [PATCH] drm/i915: Add support for mandatory cmdparsing The existing cmdparser for gen7 can be bypassed by specifying batch_len=0 in the execbuf call. This is safe because bypassing simply reduces the cmd-set available. In a later patch we will introduce cmdparsing for gen9, as a security measure, which must be strictly enforced since without it we are vulnerable to DoS attacks. Introduce the concept of 'required' cmd parsing that cannot be bypassed by submitting zero-length bb's. v2: rebase (Mika) v2: rebase (Mika) v3: fix conflict on engine flags (Mika) ------------------- From 77524398bccea3592a25cbe92a9a54fa555013af Mon Sep 17 00:00:00 2001 From: Jon Bloomfield <jon.bloomfield%intel.com@localhost> Date: Tue, 22 May 2018 13:59:06 -0700 Subject: [PATCH] drm/i915: Support ro ppgtt mapped cmdparser shadow buffers For Gen7, the original cmdparser motive was to permit limited use of register read/write instructions in unprivileged BB's. This worked by copying the user supplied bb to a kmd owned bb, and running it in secure mode, from the ggtt, only if the scanner finds no unsafe commands or registers. For Gen8+ we can't use this same technique because running bb's from the ggtt also disables access to ppgtt space. But we also do not actually require 'secure' execution since we are only trying to reduce the available command/register set. Instead we will copy the user buffer to a kmd owned read-only bb in ppgtt, and run in the usual non-secure mode. Note that ro pages are only supported by ppgtt (not ggtt), but luckily that's exactly what we need. Add the required paths to map the shadow buffer to ppgtt ro for Gen8+ v2: IS_GEN7/IS_GEN (Mika) v3: rebase v4: rebase v5: rebase ------------------- From 2ac501479a1325d00aca5012887ebfece8358032 Mon Sep 17 00:00:00 2001 From: Jon Bloomfield <jon.bloomfield%intel.com@localhost> Date: Wed, 1 Aug 2018 09:45:50 -0700 Subject: [PATCH] drm/i915: Allow parsing of unsized batches In "drm/i915: Add support for mandatory cmdparsing" we introduced the concept of mandatory parsing. This allows the cmdparser to be invoked even when user passes batch_len=0 to the execbuf ioctl's. However, the cmdparser needs to know the extents of the buffer being scanned. Refactor the code to ensure the cmdparser uses the actual object size, instead of the incoming length, if user passes 0. ------------------- From 57c2c8f58ca07e8045f020e4e2548ac3bc3a5aab Mon Sep 17 00:00:00 2001 From: Jon Bloomfield <jon.bloomfield%intel.com@localhost> Date: Mon, 23 Apr 2018 11:12:15 -0700 Subject: [PATCH] drm/i915: Add gen9 BCS cmdparsing For gen9 we enable cmdparsing on the BCS ring, specifically to catch inadvertent accesses to sensitive registers Unlike gen7/hsw, we use the parser only to block certain registers. We can rely on h/w to block restricted commands, so the command tables only provide enough info to allow the parser to delineate each command, and identify commands that access registers. Note: This patch deliberately ignores checkpatch issues in favour of matching the style of the surrounding code. We'll correct the entire file in one go in a later patch. v3: rebase (Mika) v4: Add RING_TIMESTAMP registers to whitelist (Jon) ------------------- From d88d2d3fc6076760e903e78135f5bef028e6e813 Mon Sep 17 00:00:00 2001 From: Jon Bloomfield <jon.bloomfield%intel.com@localhost> Date: Fri, 21 Sep 2018 13:18:09 -0700 Subject: [PATCH] drm/i915/cmdparser: Add support for backward jumps To keep things manageable, the pre-gen9 cmdparser does not attempt to track any form of nested BB_START's. This did not prevent usermode from using nested starts, or even chained batches because the cmdparser is not strictly enforced pre gen9. Instead, the existence of a nested BB_START would cause the batch to be emitted in insecure mode, and any privileged capabilities would not be available. For Gen9, the cmdparser becomes mandatory (for BCS at least), and so not providing any form of nested BB_START support becomes overly restrictive. Any such batch will simply not run. We make heavy use of backward jumps in igt, and it is much easier to add support for this restricted subset of nested jumps, than to rewrite the whole of our test suite to avoid them. Add the required logic to support limited backward jumps, to instructions that have already been validated by the parser. Note that it's not sufficient to simply approve any BB_START that jumps backwards in the buffer because this would allow an attacker to embed a rogue instruction sequence within the operand words of a harmless instruction (say LRI) and jump to that. We introduce a bit array to track every instr offset successfully validated, and test the target of BB_START against this. If the target offset hits, it is re-written to the same offset in the shadow buffer and the BB_START cmd is allowed. Note: This patch deliberately ignores checkpatch issues in the cmdtables, in order to match the style of the surrounding code. We'll correct the entire file in one go in a later patch. v2: set dispatch secure late (Mika) v3: rebase (Mika) v4: Clear whitelist on each parse Minor review updates (Chris) v5: Correct backward jump batching v6: fix compilation error due to struct eb shuffle (Mika) ------------------- From 362917ebcfacbd9c2b5172d5a5fe8cbef3ab838f Mon Sep 17 00:00:00 2001 From: Jon Bloomfield <jon.bloomfield%intel.com@localhost> Date: Thu, 20 Sep 2018 09:45:10 -0700 Subject: [PATCH] drm/i915/cmdparser: Ignore Length operands during command matching Some of the gen instruction macros (e.g. MI_DISPLAY_FLIP) have the length directly encoded in them. Since these are used directly in the tables, the Length becomes part of the comparison used for matching during parsing. Thus, if the cmd being parsed has a different length to that in the table, it is not matched and the cmd is accepted via the default variable length path. Fix by masking out everything except the Opcode in the cmd tables ------------------- From 1433b8d41b1aa346e100b839c19fc033871ac5a6 Mon Sep 17 00:00:00 2001 From: Uma Shankar <uma.shankar%intel.com@localhost> Date: Tue, 7 Aug 2018 21:15:35 +0530 Subject: [PATCH] drm/i915: Lower RM timeout to avoid DSI hard hangs In BXT/APL, device 2 MMIO reads from MIPI controller requires its PLL to be turned ON. When MIPI PLL is turned off (MIPI Display is not active or connected), and someone (host or GT engine) tries to read MIPI registers, it causes hard hang. This is a hardware restriction or limitation. Driver by itself doesn't read MIPI registers when MIPI display is off. But any userspace application can submit unprivileged batch buffer for execution. In that batch buffer there can be mmio reads. And these reads are allowed even for unprivileged applications. If these register reads are for MIPI DSI controller and MIPI display is not active during that time, then the MMIO read operation causes system hard hang and only way to recover is hard reboot. A genuine process/application won't submit batch buffer like this and doesn't cause any issue. But on a compromised system, a malign userspace process/app can generate such batch buffer and can trigger system hard hang (denial of service attack). The fix is to lower the internal MMIO timeout value to an optimum value of 950us as recommended by hardware team. If the timeout is beyond 1ms (which will hit for any value we choose if MMIO READ on a DSI specific register is performed without PLL ON), it causes the system hang. But if the timeout value is lower than it will be below the threshold (even if timeout happens) and system will not get into a hung state. This will avoid a system hang without losing any programming or GT interrupts, taking the worst case of lowest CDCLK frequency and early DC5 abort into account. ------------------- From 284d38667f7ed7171fd8f168c42490f9087c824c Mon Sep 17 00:00:00 2001 From: Imre Deak <imre.deak%intel.com@localhost> Date: Mon, 9 Jul 2018 18:24:27 +0300 Subject: [PATCH] drm/i915/gen8+: Add RC6 CTX corruption WA In some circumstances the RC6 context can get corrupted. We can detect this and take the required action, that is disable RC6 and runtime PM. The HW recovers from the corrupted state after a system suspend/resume cycle, so detect the recovery and re-enable RC6 and runtime PM. v2: rebase (Mika) v3: - Move intel_suspend_gt_powersave() to the end of the GEM suspend sequence. - Add commit message. v4: - Rebased on intel_uncore_forcewake_put(i915->uncore, ...) API change. v5: rebased on gem/gt split (Mika) ------------------- From 6dd52bae8a01af77236b88917e84e84dbcfe06db Mon Sep 17 00:00:00 2001 From: Ben Hutchings <ben%decadent.org.uk@localhost> Date: Mon, 11 Nov 2019 08:13:24 -0800 Subject: [PATCH] drm/i915/cmdparser: Fix jump whitelist clearing When a jump_whitelist bitmap is reused, it needs to be cleared. Currently this is done with memset() and the size calculation assumes bitmaps are made of 32-bit words, not longs. So on 64-bit architectures, only the first half of the bitmap is cleared. If some whitelist bits are carried over between successive batches submitted on the same context, this will presumably allow embedding the rogue instructions that we're trying to reject. Use bitmap_zero() instead, which gets the calculation right. Use the original linux function rather than my wrong translation. - ...Include the header to have it. Thanks Riastradh!
Add what appears to be the fixes to CVE-2019-0154, CVE-2019-0155. This commit requires review, but I'd also like it to be tested by others while it is being reviewed. CVE-2019-0155: It was discovered that the Intel i915 graphics chipsets allowed userspace to modify page table entries via writes to MMIO from the Blitter Command Streamer and expose kernel memory information. A local attacker could use this to expose sensitive information or possibly elevate privileges. CVE-2019-0154: It was discovered that the Intel i915 graphics chipsets could cause a system hang when userspace performed a read from GT memory mapped input output (MMIO) when the product is in certain low power states. A local attacker could use this to cause a denial of service. From upstream commits to linux-4.4.y: ------------------- From 6d0cfddc7afc715835f0e17827106f832b14dd2a Mon Sep 17 00:00:00 2001 From: Jon Bloomfield <jon.bloomfield@intel.com> Date: Thu, 12 Jul 2018 19:53:10 +0100 Subject: [PATCH] drm/i915/gtt: Add read only pages to gen8_pte_encode We can set a bit inside the ppGTT PTE to indicate a page is read-only; writes from the GPU will be discarded. We can use this to protect pages and in particular support read-only userptr mappings (necessary for importing PROT_READ vma). ------------------- From 774b68aa2105c70b40c3b1777feb7ab500d716dd Mon Sep 17 00:00:00 2001 From: Jon Bloomfield <jon.bloomfield@intel.com> Date: Mon, 6 Aug 2018 14:10:48 -0700 Subject: [PATCH] drm/i915/gtt: Read-only pages for insert_entries on bdw+ Hook up the flags to allow read-only ppGTT mappings for gen8+ v2: Include a selftest to check that writes to a readonly PTE are dropped v3: Don't duplicate cpu_check() as we can just reuse it, and even worse don't wholesale copy the theory-of-operation comment from igt_ctx_exec without changing it to explain the intention behind the new test! v4: Joonas really likes magic mystery values ------------------- From 3fd1c2e65c60c1c513155e1d1d74138b141aa8a3 Mon Sep 17 00:00:00 2001 From: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu, 12 Jul 2018 19:53:12 +0100 Subject: [PATCH] drm/i915/gtt: Disable read-only support under GVT GVT is not propagating the PTE bits, and is always setting the read-write bit, thus breaking read-only support. ------------------- From e5e3c0154c19f2d8213e0af88b7a10d9de7fbafd Mon Sep 17 00:00:00 2001 From: Jon Bloomfield <jon.bloomfield@intel.com> Date: Fri, 20 Apr 2018 14:26:01 -0700 Subject: [PATCH] drm/i915: Rename gen7 cmdparser tables We're about to introduce some new tables for later gens, and the current naming for the gen7 tables will no longer make sense. v2: rebase ------------------- From 3122671a5df3ee13f5cf22b7bdacf422b7b4319a Mon Sep 17 00:00:00 2001 From: Jon Bloomfield <jon.bloomfield@intel.com> Date: Fri, 8 Jun 2018 08:53:46 -0700 Subject: [PATCH] drm/i915: Disable Secure Batches for gen6+ Retroactively stop reporting support for secure batches through the api for gen6+ so that older binaries trigger the fallback path instead. Older binaries use secure batches pre gen6 to access resources that are not available to normal usermode processes. However, all known userspace explicitly checks for HAS_SECURE_BATCHES before relying on the secure batch feature. Since there are no known binaries relying on this for newer gens we can kill secure batches from gen6, via I915_PARAM_HAS_SECURE_BATCHES. v2: rebase (Mika) v3: rebase (Mika) ------------------- From 544fd7d9d4cfe32357beab2f1dc543637d42e69f Mon Sep 17 00:00:00 2001 From: Jon Bloomfield <jon.bloomfield@intel.com> Date: Fri, 8 Jun 2018 10:05:26 -0700 Subject: [PATCH] drm/i915: Remove Master tables from cmdparser The previous patch has killed support for secure batches on gen6+, and hence the cmdparsers master tables are now dead code. Remove them. ------------------- From 17e89f38212d8b3cba470efca91b997ac03c592c Mon Sep 17 00:00:00 2001 From: Jon Bloomfield <jon.bloomfield@intel.com> Date: Wed, 1 Aug 2018 09:33:59 -0700 Subject: [PATCH] drm/i915: Add support for mandatory cmdparsing The existing cmdparser for gen7 can be bypassed by specifying batch_len=0 in the execbuf call. This is safe because bypassing simply reduces the cmd-set available. In a later patch we will introduce cmdparsing for gen9, as a security measure, which must be strictly enforced since without it we are vulnerable to DoS attacks. Introduce the concept of 'required' cmd parsing that cannot be bypassed by submitting zero-length bb's. v2: rebase (Mika) v2: rebase (Mika) v3: fix conflict on engine flags (Mika) ------------------- From 77524398bccea3592a25cbe92a9a54fa555013af Mon Sep 17 00:00:00 2001 From: Jon Bloomfield <jon.bloomfield@intel.com> Date: Tue, 22 May 2018 13:59:06 -0700 Subject: [PATCH] drm/i915: Support ro ppgtt mapped cmdparser shadow buffers For Gen7, the original cmdparser motive was to permit limited use of register read/write instructions in unprivileged BB's. This worked by copying the user supplied bb to a kmd owned bb, and running it in secure mode, from the ggtt, only if the scanner finds no unsafe commands or registers. For Gen8+ we can't use this same technique because running bb's from the ggtt also disables access to ppgtt space. But we also do not actually require 'secure' execution since we are only trying to reduce the available command/register set. Instead we will copy the user buffer to a kmd owned read-only bb in ppgtt, and run in the usual non-secure mode. Note that ro pages are only supported by ppgtt (not ggtt), but luckily that's exactly what we need. Add the required paths to map the shadow buffer to ppgtt ro for Gen8+ v2: IS_GEN7/IS_GEN (Mika) v3: rebase v4: rebase v5: rebase ------------------- From 2ac501479a1325d00aca5012887ebfece8358032 Mon Sep 17 00:00:00 2001 From: Jon Bloomfield <jon.bloomfield@intel.com> Date: Wed, 1 Aug 2018 09:45:50 -0700 Subject: [PATCH] drm/i915: Allow parsing of unsized batches In "drm/i915: Add support for mandatory cmdparsing" we introduced the concept of mandatory parsing. This allows the cmdparser to be invoked even when user passes batch_len=0 to the execbuf ioctl's. However, the cmdparser needs to know the extents of the buffer being scanned. Refactor the code to ensure the cmdparser uses the actual object size, instead of the incoming length, if user passes 0. ------------------- From 57c2c8f58ca07e8045f020e4e2548ac3bc3a5aab Mon Sep 17 00:00:00 2001 From: Jon Bloomfield <jon.bloomfield@intel.com> Date: Mon, 23 Apr 2018 11:12:15 -0700 Subject: [PATCH] drm/i915: Add gen9 BCS cmdparsing For gen9 we enable cmdparsing on the BCS ring, specifically to catch inadvertent accesses to sensitive registers Unlike gen7/hsw, we use the parser only to block certain registers. We can rely on h/w to block restricted commands, so the command tables only provide enough info to allow the parser to delineate each command, and identify commands that access registers. Note: This patch deliberately ignores checkpatch issues in favour of matching the style of the surrounding code. We'll correct the entire file in one go in a later patch. v3: rebase (Mika) v4: Add RING_TIMESTAMP registers to whitelist (Jon) ------------------- From d88d2d3fc6076760e903e78135f5bef028e6e813 Mon Sep 17 00:00:00 2001 From: Jon Bloomfield <jon.bloomfield@intel.com> Date: Fri, 21 Sep 2018 13:18:09 -0700 Subject: [PATCH] drm/i915/cmdparser: Add support for backward jumps To keep things manageable, the pre-gen9 cmdparser does not attempt to track any form of nested BB_START's. This did not prevent usermode from using nested starts, or even chained batches because the cmdparser is not strictly enforced pre gen9. Instead, the existence of a nested BB_START would cause the batch to be emitted in insecure mode, and any privileged capabilities would not be available. For Gen9, the cmdparser becomes mandatory (for BCS at least), and so not providing any form of nested BB_START support becomes overly restrictive. Any such batch will simply not run. We make heavy use of backward jumps in igt, and it is much easier to add support for this restricted subset of nested jumps, than to rewrite the whole of our test suite to avoid them. Add the required logic to support limited backward jumps, to instructions that have already been validated by the parser. Note that it's not sufficient to simply approve any BB_START that jumps backwards in the buffer because this would allow an attacker to embed a rogue instruction sequence within the operand words of a harmless instruction (say LRI) and jump to that. We introduce a bit array to track every instr offset successfully validated, and test the target of BB_START against this. If the target offset hits, it is re-written to the same offset in the shadow buffer and the BB_START cmd is allowed. Note: This patch deliberately ignores checkpatch issues in the cmdtables, in order to match the style of the surrounding code. We'll correct the entire file in one go in a later patch. v2: set dispatch secure late (Mika) v3: rebase (Mika) v4: Clear whitelist on each parse Minor review updates (Chris) v5: Correct backward jump batching v6: fix compilation error due to struct eb shuffle (Mika) ------------------- From 362917ebcfacbd9c2b5172d5a5fe8cbef3ab838f Mon Sep 17 00:00:00 2001 From: Jon Bloomfield <jon.bloomfield@intel.com> Date: Thu, 20 Sep 2018 09:45:10 -0700 Subject: [PATCH] drm/i915/cmdparser: Ignore Length operands during command matching Some of the gen instruction macros (e.g. MI_DISPLAY_FLIP) have the length directly encoded in them. Since these are used directly in the tables, the Length becomes part of the comparison used for matching during parsing. Thus, if the cmd being parsed has a different length to that in the table, it is not matched and the cmd is accepted via the default variable length path. Fix by masking out everything except the Opcode in the cmd tables ------------------- From 1433b8d41b1aa346e100b839c19fc033871ac5a6 Mon Sep 17 00:00:00 2001 From: Uma Shankar <uma.shankar@intel.com> Date: Tue, 7 Aug 2018 21:15:35 +0530 Subject: [PATCH] drm/i915: Lower RM timeout to avoid DSI hard hangs In BXT/APL, device 2 MMIO reads from MIPI controller requires its PLL to be turned ON. When MIPI PLL is turned off (MIPI Display is not active or connected), and someone (host or GT engine) tries to read MIPI registers, it causes hard hang. This is a hardware restriction or limitation. Driver by itself doesn't read MIPI registers when MIPI display is off. But any userspace application can submit unprivileged batch buffer for execution. In that batch buffer there can be mmio reads. And these reads are allowed even for unprivileged applications. If these register reads are for MIPI DSI controller and MIPI display is not active during that time, then the MMIO read operation causes system hard hang and only way to recover is hard reboot. A genuine process/application won't submit batch buffer like this and doesn't cause any issue. But on a compromised system, a malign userspace process/app can generate such batch buffer and can trigger system hard hang (denial of service attack). The fix is to lower the internal MMIO timeout value to an optimum value of 950us as recommended by hardware team. If the timeout is beyond 1ms (which will hit for any value we choose if MMIO READ on a DSI specific register is performed without PLL ON), it causes the system hang. But if the timeout value is lower than it will be below the threshold (even if timeout happens) and system will not get into a hung state. This will avoid a system hang without losing any programming or GT interrupts, taking the worst case of lowest CDCLK frequency and early DC5 abort into account. ------------------- From 284d38667f7ed7171fd8f168c42490f9087c824c Mon Sep 17 00:00:00 2001 From: Imre Deak <imre.deak@intel.com> Date: Mon, 9 Jul 2018 18:24:27 +0300 Subject: [PATCH] drm/i915/gen8+: Add RC6 CTX corruption WA In some circumstances the RC6 context can get corrupted. We can detect this and take the required action, that is disable RC6 and runtime PM. The HW recovers from the corrupted state after a system suspend/resume cycle, so detect the recovery and re-enable RC6 and runtime PM. v2: rebase (Mika) v3: - Move intel_suspend_gt_powersave() to the end of the GEM suspend sequence. - Add commit message. v4: - Rebased on intel_uncore_forcewake_put(i915->uncore, ...) API change. v5: rebased on gem/gt split (Mika) ------------------- From 6dd52bae8a01af77236b88917e84e84dbcfe06db Mon Sep 17 00:00:00 2001 From: Ben Hutchings <ben@decadent.org.uk> Date: Mon, 11 Nov 2019 08:13:24 -0800 Subject: [PATCH] drm/i915/cmdparser: Fix jump whitelist clearing When a jump_whitelist bitmap is reused, it needs to be cleared. Currently this is done with memset() and the size calculation assumes bitmaps are made of 32-bit words, not longs. So on 64-bit architectures, only the first half of the bitmap is cleared. If some whitelist bits are carried over between successive batches submitted on the same context, this will presumably allow embedding the rogue instructions that we're trying to reject. Use bitmap_zero() instead, which gets the calculation right.
Sync with HEAD
Sync with HEAD Resolve a couple of conflicts (result of the uimin/uimax changes)
file bitops.h was added on branch phil-wifi on 2019-06-10 22:07:44 +0000
file bitops.h was added on branch pgoyette-compat on 2018-09-06 06:56:08 +0000
Give find_first/next_set/zero_bit a chance to work. Self-review comments on the draft thrown together in a hurry two weeks ago: - I bet I screwed up for_each_set_bit or something. - There might be several bits wrong in this __find_next_bit routine! - for_each_set_bit is busted. - Maybe I should test this stuff before I commit it. - Hey, cool, buffer overflow here. - What was I thinking. - how did this even - Was I drunk? I'm never drunk. - I don't even drink. - It wasn't even that late at night...
Move hweight8 next to its cousins.
Add find_first_bit, find_next_bit, for_each_set_bit.
Implement find_next_zero_bit. Define find_first_zero_bit in terms of it.
Add fls to <linux/bitops.h>.
Add hweight64.
... Provide GENMASK Author: coypu <coypu@sdf.org> Committer: Taylor R Campbell <riastradh@NetBSD.org>
move bitops.h so we can include it from kernel.h match linux side-loading of this header. Author: coypu <coypu@sdf.org> Committer: Taylor R Campbell <riastradh@NetBSD.org>