#StackBounty: #boot #drivers #kernel #modprobe softdep for vfio-pci wont work

Bounty: 200

I’m trying to do passthrough so my devices are grabbed by vfio-pci before any other module. Here’s my /etc/modprobe.d/01-vfio-pci.conf:

softdep nouveau pre: vfio-pci
softdep nvidiafb pre: vfio-pci
softdep snd_hda_intel pre: vfio-pci
softdep nvidia-gpu pre: vfio-pci
softdep i2c_nvidia_gpu pre: vfio-pci
softdep xhci_hcd pre: vfio-pci
options vfio-pci ids=10de:2184,10de:1aeb,10de:1aec,10de:1aed,1022:145f

but here are the devices after boot:

07:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU116 [GeForce GTX 1660] [10de:2184] (rev a1) (prog-if 00 [VGA controller])
    Subsystem: NVIDIA Corporation TU116 [GeForce GTX 1660] [10de:1324]
    Flags: fast devsel, IRQ 10
    Memory at f6000000 (32-bit, non-prefetchable) [disabled] [size=16M]
    Memory at d0000000 (64-bit, prefetchable) [disabled] [size=256M]
    Memory at e0000000 (64-bit, prefetchable) [disabled] [size=32M]
    I/O ports at f000 [disabled] [size=128]
    Expansion ROM at f7000000 [disabled] [size=512K]
    Capabilities: <access denied>
    Kernel driver in use: vfio-pci
    Kernel modules: nvidiafb, nouveau

07:00.1 Audio device [0403]: NVIDIA Corporation Device [10de:1aeb] (rev a1)
    Subsystem: NVIDIA Corporation Device [10de:1324]
    Flags: fast devsel, IRQ 11
    Memory at f7080000 (32-bit, non-prefetchable) [disabled] [size=16K]
    Capabilities: <access denied>
    Kernel driver in use: vfio-pci
    Kernel modules: snd_hda_intel

07:00.2 USB controller [0c03]: NVIDIA Corporation Device [10de:1aec] (rev a1) (prog-if 30 [XHCI])
    Subsystem: NVIDIA Corporation Device [10de:1324]
    Flags: fast devsel, IRQ 47
    Memory at e2000000 (64-bit, prefetchable) [size=256K]
    Memory at e2040000 (64-bit, prefetchable) [size=64K]
    Capabilities: <access denied>
    Kernel driver in use: xhci_hcd

07:00.3 Serial bus controller [0c80]: NVIDIA Corporation Device [10de:1aed] (rev a1)
    Subsystem: NVIDIA Corporation Device [10de:1324]
    Flags: bus master, fast devsel, latency 0, IRQ 61
    Memory at f7084000 (32-bit, non-prefetchable) [size=4K]
    Capabilities: <access denied>
    Kernel driver in use: nvidia-gpu
    Kernel modules: i2c_nvidia_gpu

08:00.3 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] Zeppelin USB 3.0 Host controller [1022:145f] (prog-if 30 [XHCI])
    Subsystem: Gigabyte Technology Co., Ltd Zeppelin USB 3.0 Host controller [1458:5007]
    Flags: bus master, fast devsel, latency 0, IRQ 48
    Memory at f7200000 (64-bit, non-prefetchable) [size=1M]
    Capabilities: <access denied>
    Kernel driver in use: xhci_hcd

As you can see, only some are grabbed. But they’re not grabbed by this modprobe rule I added, it works without it.

lz@z:~$ cat /etc/initramfs-tools/modules
# List of modules that you want to include in your initramfs.
# They will be loaded at boot time in the order below.
#
# Syntax:  module_name [args ...]
#
# You must run update-initramfs(8) to effect this change.
#
# Examples:
#
# raid1
# sd_mod
vfio 
vfio_iommu_type1 
vfio_virqfd 
options vfio_pci ids=10de:2184,10de:1aeb,10de:1aec,10de:1aed,1022:145f
vfio_pci ids=10de:2184,10de:1aeb,10de:1aec,10de:1aed,1022:145f
vfio_pci

lz@z:~$ cat /etc/modules
# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.

vfio 
vfio_iommu_type1 
vfio_pci ids=10de:2184,10de:1aeb,10de:1aec,10de:1aed,1022:145f


Get this bounty!!!

#StackBounty: #linux #kernel #performance-tuning #arp #packet Is there is any tool/way to find out why packet is getting dropped due to…

Bounty: 50

My developer hypothesis is packet is getting dropped at arp layer. We increased the default value of neigh.default.gc_thresh3 1024 –> 2048 and now everything looks good. But I want to understand is there is a way to figure it out arp packet loss.I try to search for systemtap/tools but didn’t find anything. Any help is really appreciated.

net.ipv4.neigh.default.gc_thresh3=<n>


Get this bounty!!!

#StackBounty: #kernel #touchscreen #xinput #stylus xinput list "UNKNOWN"

Bounty: 100

I am trying to get the stylus working properly on a One Netbook One Mix 3s tiny laptop.

This laptop is compatible with microsoft pens (I.e. it’s using n-trig technology) but as far as I can tell the touchscreen is not actually made by Wacom.

On the newest Ubuntu version (19.0?) the touchscreen and stylus is not supported at all. In other versions of the distribution (for example 18.04.3 LTS) the touchscreen works great, but the stylus is detected as “clicking” as in it’s as if you are holding the mouse button down when it is anywhere in the vicinity of the screen.

The output of xinput list looks like this:

ubuntu@ubuntu:~$ xinput list
⎡ Virtual core pointer                      id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
⎜   ↳ HAILUCK CO.,LTD USB KEYBOARD Mouse        id=12   [slave  pointer  (2)]
⎜   ↳ GXTP7386:00 27C6:0113 UNKNOWN             id=16   [slave  pointer  (2)]
⎜   ↳ GXTP7386:00 27C6:0113                     id=15   [slave  pointer  (2)]
⎣ Virtual core keyboard                     id=3    [master keyboard (2)]
    ↳ Virtual core XTEST keyboard               id=5    [slave  keyboard (3)]
    ↳ Power Button                              id=8    [slave  keyboard (3)]
    ↳ Video Bus                                 id=7    [slave  keyboard (3)]
    ↳ Power Button                              id=6    [slave  keyboard (3)]
    ↳ Sleep Button                              id=9    [slave  keyboard (3)]
    ↳ HAILUCK CO.,LTD USB KEYBOARD Wireless Radio Control   id=11   [slave  keyboard (3)]
    ↳ HAILUCK CO.,LTD USB KEYBOARD              id=10   [slave  keyboard (3)]
    ↳ HAILUCK CO.,LTD USB KEYBOARD Consumer Control id=14   [slave  keyboard (3)]
    ↳ GXTP7386:00 27C6:0113 Keyboard            id=17   [slave  keyboard (3)]
    ↳ AT Translated Set 2 keyboard              id=18   [slave  keyboard (3)]
    ↳ HAILUCK CO.,LTD USB KEYBOARD System Control   id=13   [slave  keyboard (3)]

On 18.04.3. Notice that one of the devices is called UNKNOWN. Also the device with a similar name, at id 15, I know for a fact is the touchscreen. So I am pretty sure the UNKNOWN one is supposed to be the pen.

A different computer made by the same company (the 2s) had a similar problem with the pen not working. It was solved by Adya on github who released a custom kernel module:
https://bbs.archlinux.org/viewtopic.php?id=242893

This is the same behavior except on that computer, the pen didn
t show up at all on xinput list. The fact that there is this UNKNOWN device makes me think the problem is a little different. Furthermore, some people on forums claimed that the pen worked well with KDE neon. I tested it and it wasn’t detected at all. Perhaps because KDE neon is on a different version. Anyway, it seems like a shame if the newer version of Ubuntu is less compatible than the older one. I will try 18.04.2 and see if the pen support is different there.

Can anyone tell me what the differences are between the different Ubuntu releases? Is there any hope of fixing these issues and getting it running well on all future releases any time soon?

Update: Sure enough on Ubuntu 18.04.2, the stylus is working. xinput list gives the same except where there is UNKNOWN we have “Pen pen(0)”. Will all the future Ubuntu releases not support this touchscreen? Can we just take some kinds of settings from somewhere and put them in the new versions?

Update to update: after installing Ubuntu 18.04.2 the pen is again set to UNKNOWN in xinput. It is still detected but behaves badly (always clicking). I have confirmed that id 16 is the pen using libinput

Edit: In Xournalpp, under devices, GXTP7386:00 Pen pen(0) DOES show up. That means somewhere this computer knows there’s a pen… but xinput doesn’t know where it is…


Get this bounty!!!

#StackBounty: #drivers #kernel #suspend #acpi How to find acpi drivers for specific acpi device / Solving kernel suspend bug

Bounty: 400

I’m following https://wiki.ubuntu.com/DebuggingKernelSuspend and it says that I have to reboot the system with

sudo sh -c "sync && echo 1 > /sys/power/pm_trace && pm-suspend"

and find the lines that says hash matches in dmesg rigth after reboot (what does that mean?)

Well, I found two:

[    3.583591] ima: Allocated hash algorithm: sha1
[    3.593050] input: AT Raw Set 2 keyboard as /devices/platform/i8042/serio0/input/input4
[    3.638808]   Magic number: 0:929:176
[    3.638867] acpi device:39: hash matches
[    3.638893] acpi device:0c: hash matches
[    3.639073] rtc_cmos 00:01: setting system clock to 2016-01-01 12:09:51 UTC (1451650191)

Looks like the problem is in these two acpi devices. The article doesn’t say what to do in this case. If the problem was in a PCIe device I could simply unload its module, but what should I do in this case? Does an acpi device have a module? If so, how to find its module? And what hash matches mean?

UPDATE:

Here’s my lspci:

00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM Registers (rev 02)
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 620 (rev 02)
00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller (rev 21)
00:14.2 Signal processing controller: Intel Corporation Sunrise Point-LP Thermal subsystem (rev 21)
00:15.0 Signal processing controller: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #0 (rev 21)
00:15.1 Signal processing controller: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #1 (rev 21)
00:16.0 Communication controller: Intel Corporation Sunrise Point-LP CSME HECI #1 (rev 21)
00:1c.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #3 (rev f1)
00:1c.4 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #5 (rev f1)
00:1d.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #9 (rev f1)
00:1e.0 Signal processing controller: Intel Corporation Sunrise Point-LP Serial IO UART Controller #0 (rev 21)
00:1f.0 ISA bridge: Intel Corporation Sunrise Point-LP LPC Controller (rev 21)
00:1f.2 Memory controller: Intel Corporation Sunrise Point-LP PMC (rev 21)
00:1f.3 Audio device: Intel Corporation Sunrise Point-LP HD Audio (rev 21)
00:1f.4 SMBus: Intel Corporation Sunrise Point-LP SMBus (rev 21)
01:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter (rev 32)
3b:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM961/PM961


Get this bounty!!!

#StackBounty: #linux #exploit #privilege-escalation #kernel Methods root can use to elevate itself to kernel mode

Bounty: 350

When most Linux users hear “root”, they think of the maximum possible privilege on a computer. Some even think that root runs in ring 0. But in reality, root is just a regular user running in ring 3, albeit one which the kernel trusts (many sensitive kernel operations are guarded with checks along the lines of if (!uid_eq(current_uid(), GLOBAL_ROOT_UID)) return -EPERM; to prevent abuse, which simply returns an error if uid != 0).

On most Linux systems, the kernel trusts root so much that it can easily exploit the kernel and gain access to ring 0 at will. However, it is often possible with security tools such as grsecurity, SELinux, etc, to prevent this by reducing root’s dangerous abilities, and enforcing these restrictions on the kernel level.

I would like to enumerate a list of methods by which root could exploit the kernel to gain access to kernel mode and ring 0. So far, these are the methods I have thought or learned of by which this could happen, along with potential mitigations:

  • ioperm() and iopl() can set I/O port permissions and can be abused to write to arbitrary regions of memory, including memory where the kernel resides. These syscalls can be disabled by removing them from the syscall table or with grsecurity.
  • Root can just modify the kernel image in /boot or through the block device. A MAC can restrict root’s access to both of these.
  • /dev/{k,}mem are designed to allow rw access to arbitrary memory. These can be disabled completely in the kernel config, by using grsecurity, or with a MAC.
  • Some MSRs can be used to write to arbitrary memory. Denying writing to MSRs either by disabling them in the kernel config or with grsecurity mitigates this issue.
  • kexec allows root to select an alternate kernel to boot into. This is an optional kernel feature, so simply compiling the kernel without kexec support is enough to make this a non-issue.
  • sysfs provides low level access to much of the hardware, which can hijack a poorly locked-down BIOS/UEFI on many vulnerable systems to gain ring 0, or even ring -2 access. A MAC can restrict access to /sys, and various tools can detect vulnerabilities in UEFI/BIOS.
  • If root is allowed to load ACPI tables at runtime (DSDT, SSDT, etc), it can cause the kernel to execute AML, which is ACPI bytecode, and change how the kernel behaves and reacts to the hardware it runs on. I know little about ACPI and AML, but this sounds like an absolute recipe for disaster. Disabling loadable ACPI table support in the kernel should mitigate this.
  • Loading malicious kernel modules can directly hijack the kernel. This can be trivially defeated by requiring module signing, or by building a kernel without module support.

Obviously, I will be using principal of least privilege for root, rather than trying to blacklist all the possible ways it can break out of its chains. That doesn’t change the fact that it is still extremely useful, and interesting, to understand all the ways it can abuse the kernel’s trust.

And so that brings me to my question: Are there any other methods which root can use to gain access to ring 0, without using 0days and without exploiting opsec mistakes, which I have not covered here?


Get this bounty!!!

#StackBounty: #boot #kernel #virtualbox #secure-boot Looking for a mokutil workaround to sign virtualbox kernel modules

Bounty: 200

I’ve been having some problems managing the Secure Boot setup on my machine which has an Asus X99 motherboard.

I’ve successfully generated a MOK with openssl, and then used it to sign the kernel module for my WiFi card (bcmwl-kernel-source/wl.ko) and enrolled the key into shim (if I understand correctly?) using MokManager. I got MokManager to run by adding an EFI boot record for it, and then using the EFI to start it at boot time. I couldn’t get mokutil to work though, and had to manually copy the key over to the /boot partition, reboot, and choose “Enroll Key From Disk” and do it like that. But once that was done, the kernel module for the wifi driver loads and works under Secure Boot without any problems.

So signing and verifying and loading kernel modules in Secure Boot mode does work.

It looks as though the failure of mokutil is to do with some sort of motherboard/firmware bug with the X99 (as well as some other models, according to the Fedora bug report):

mokutil – failing for almost all options

https://bugzilla.redhat.com/show_bug.cgi?id=1263992

Here’s some example output from mokutil on my machine:

alex@alex-dev-desktop:~$ mokutil --sb-state
SecureBoot enabled
alex@alex-dev-desktop:~$ sudo mokutil --password
input password: 
input password again: 
Failed to write MokPW: Invalid argument
alex@alex-dev-desktop:~$ sudo mokutil --import MOK.der 
SKIP: MOK.der is already enrolled
alex@alex-dev-desktop:~$ sudo mokutil --list-enrolled |grep Issuer
    Issuer: C=GB, ST=London, L=London, O=ghostaldev, CN=Secure Boot Signing/emailAddress=<my email>
    Issuer: C=GB, ST=Isle of Man, L=Douglas, O=Canonical Ltd., CN=Canonical Ltd. Master Certificate Authority
alex@alex-dev-desktop:~$ sudo mokutil --import SOMENEWKEY.der
input password: 
input password again: 
Failed to enroll new keys
alex@alex-dev-desktop:~$ sudo mokutil --disable-validation
password length: 8~16
input password: 
input password again: 
Failed to request new MokSB state
alex@alex-dev-desktop:~$ 

As shown, the key I used to sign my wifi driver is in the enrolled keys list, alongside Canonicals, but using mokutil to enrol keys doesn’t work. It seems that all commands that write any data for controlling MokManager fail.

What I’m trying to do: Sign Virtualbox kernel modules so they run under Secure Boot

When I do sudo apt-get install virtualbox-dkms, I get a terminal GUI prompt telling me I am in secure boot mode, that modules need to be signed and keys enrolled, and asking me to set a password. Under the hood, the package installation looks like it’s attempting to use mokutil, and in the output I see the Failed to enroll new keys message. Using hexdump, it looks as though the vboxdrv.ko module has been signed by some sort of key:

alex@alex-dev-desktop:~$ hexdump -e "16 "%_p" "\n"" /lib/modules/4.15.0-58-generic/updates/vboxdrv.ko |tail -n 27 |head -n 5
......1..q0..m..
.0H001.0,..U...%
mint Secure Boot
 Module Signatur
e key..W+.0.x..(
alex@alex-dev-desktop:~$ 

I’m not sure what key is being used for this, but obviously it’s not a working solution because it’s not enrolled.

I’m looking for a workaround to get these kernel modules signed and loading up under Secure Boot. These are my ideas for potential workarounds (and why I’m stuck):

  • Enrol the key used to sign the virtualbox modules (I don’t know where to find this)
  • Sign them myself with the key I have that is already enrolled (I’ve tried this, but it doesn’t seem to work – I’m not sure if it’s possible to sign a kernel module with multiple keys)
  • Disable kernel module validation in shim (my understanding is that this is what the mokutil --disable-validation command is for, but it doesn’t work, and when I start MokManager, I don’t see an option available for this – only “Continue boot”, “Enroll Key From Disk” and “Enroll Hash From Disk”, no “Change Secure Boot State” option, as shown on this page, for example).

Would really appreciate some help here! 🙂


Get this bounty!!!

#StackBounty: #kernel Linux kernel flavours in modern releases

Bounty: 50

Nowadays (18.04+) there are much more kernel flavours, and not all of them are well described. I see those ones:

  • generic, the default one, with possible -hwe branch;
  • virtual — same as generic but excluding modules-extra. Can have -hwe branch too;
  • kvm;
  • azure, aws, gcp, gke — targeting cloud providers;
  • oem — who is that?;
  • oracle — what Oracle systems?

So, how do I choose? For example, VPS probably doesn’t need generic kernel, virtual would require way less valuable disk space, but maybe kvm is even better? What is the difference in the first place?

Wiki has a page on the subject (https://wiki.ubuntu.com/Kernel/Dev/Flavours), but it is way outdated.


Get this bounty!!!

#StackBounty: #linux #hardware #memory #kernel #dma-attack DMA attacks despite IOMMU isolation

Bounty: 200

If you’re already familiar with PCI behavior and Linux’s handling of DMA buffers, skip to the third section for my actual question. Otherwise read on for a small summary of how PCI devices perform memory accesses, and how the kernel handles communicating with devices using DMA. I’ve included this here both in hopes of providing people asking the same question with useful information, and to give others the chance to correct me in case my understanding is off.

(My understanding of) PCI, IOMMU, and DMA

PCI and PCIe devices have in their configuration space a two byte command register which contains a bitmask for enabling or disabling several different hardware features. Bit 2 is the bus master enable bit which, when set, allows the device to initiate DMA requests. This bit, and any other bits on the command register, is set by software running in supervisor mode (typically by kernel drivers) and, despite being physically stored on the PCI device, cannot be changed by it (perhaps the PCH keeps a shadow copy of each device’s PCI configuration space?). On hardware without an IOMMU, the device can request reads and writes to any legal memory address. This is often called a DMA attack or evil bus mastering, and is an issue on any unprotected system with malicious PCI devices. The IOMMU is supposed to be the solution to improve both security and performance. For reference, I am specifically asking about Intel’s implementation, VT-d (precisely the more modern VT-d2).

Most systems can be configured for DMA remapping, or DMAR. The ACPI tables included in the BIOS often have the DMAR table, which contains a list of addresses which various PCI groups will have all their memory accesses routed to. This is all described in the section 2.5.1.1 of the VT-d specifications. A graphic from the document:

DMA remapping

The Linux kernel DMA API

The DMAR tables are hardcoded by the BIOS. A given PCI device (or rather, a given IOMMU group) is allowed to access only a pre-determined memory range. The kernel is told where that memory is and is instructed not to allocate any memory there which it does not want readable/writable over DMA. The remapping values are reported in the kernel log buffer:

DMAR: Setting identity map for device 0000:00:02.0 [0xad000000 - 0xaf1fffff]
DMAR: Setting identity map for device 0000:00:14.0 [0xa95dc000 - 0xa95e8fff]
DMAR: Setting identity map for device 0000:00:1a.0 [0xa95dc000 - 0xa95e8fff]
DMAR: Setting identity map for device 0000:00:1d.0 [0xa95dc000 - 0xa95e8fff]
DMAR: Prepare 0-16MiB unity mapping for LPC
DMAR: Setting identity map for device 0000:00:1f.0 [0x0 - 0xffffff]
DMAR: Intel(R) Virtualization Technology for Directed I/O
iommu: Adding device 0000:00:00.0 to group 0
iommu: Adding device 0000:00:01.0 to group 1
iommu: Adding device 0000:00:02.0 to group 2
iommu: Adding device 0000:00:14.0 to group 3
iommu: Adding device 0000:00:16.0 to group 4
iommu: Adding device 0000:00:1a.0 to group 5
iommu: Adding device 0000:00:1b.0 to group 6
iommu: Adding device 0000:00:1c.0 to group 7
iommu: Adding device 0000:00:1c.2 to group 8
iommu: Adding device 0000:00:1c.3 to group 9
iommu: Adding device 0000:00:1c.4 to group 10
iommu: Adding device 0000:00:1d.0 to group 11
iommu: Adding device 0000:00:1f.0 to group 12
iommu: Adding device 0000:00:1f.2 to group 12
iommu: Adding device 0000:00:1f.3 to group 12
iommu: Adding device 0000:01:00.0 to group 1
iommu: Adding device 0000:03:00.0 to group 13
iommu: Adding device 0000:04:00.0 to group 14
iommu: Adding device 0000:05:00.0 to group 15

From the bolded lines, we see that group 11 contains (only) device 0000:00:1d.0, which is able to freely access 13 pages of memory in the range of 0xa95dc000 - 0xa95e8fff. All accesses for devices in group 11 will only be able to write there, preventing them from modifying the contents of other DMA buffers, or unrelated OS code. This way, even if the device has its bus master bit set, it does not need to keep track of where it is writing, and it cannot (accidentally or maliciously) write anywhere it is not supposed to.

When a kernel driver wants to interact with a device over DMA, it allocates memory specifically for this purpose using, for example, void *addr = kmalloc(len, GFP_KERNEL | GFP_DMA). This will return, in addr, a virtual memory address pointing to a contiguous section of memory len bytes in size which is suitable for DMA use. This is all described in more detail in the DMA API documentation. The driver is then free to communicate with the PCI device through this shared memory region. The series of events, simplified, may look something like this:

  • OpenCL driver allocates memory, shared with the GPU PCI device, for DMA use.
  • Driver writes some vector data to the DMA address, and goes off to do something else.
  • GPU reads the data over the PCI device, and begins the slow task of processing it.
  • When finished, the GPU writes the finished data to the buffer and fires off an interrupt.
  • Driver stops what it is doing due to the interrupt and reads the rendered graphic from memory.

Does the kernel distrust DMA buffers and handle them securely?

Does the kernel implicitly trust these DMA buffers? Can a malicious or compromised PCI device, writing nowhere other than the designated buffers (the IOMMU prevents it from doing otherwise), compromise the kernel by exploiting the data structures they are sharing? The obvious answer is possibly, because any sharing and parsing of complex data structures using memory unsafe languages carries with it the risk of exploitation. But the kernel developers may assume that these buffers are trusted and put absolutely no effort into securing the kernel from malicious activity in them (unlike, say, the data shared between unprivileged userland and the kernel via copy_from_user() and similar functions). I am starting to think that the answer to whether or not a malicious PCI device can compromise the host despite the IOMMU’s restrictions is probably.

Exploitation of such a vulnerability would work something like this, where buf is in the device-controlled and DMA-writable address space, and dest is elsewhere in kernel memory:

  • Device writes data as struct { size_t len; char data[32]; char foo[32]; } buf.
  • Driver is to copy to data in struct { char data[32]; bool summon_demons; } dest.
  • Device maliciously sets buf.len = sizeof(buf.data) + 1 and buf.foo[0] = 1.
  • Driver copies data insecurely, using memcpy(dest.data, buf.data, buf.len).
  • PCI device gains control over the kernel and your soul in a classic buffer overflow.

Obviously this is a contrived example and while most likely such an obvious bug would not make its way into the kernel in the first place, it illustrates my point, and brings me to my primary question:

Are there any examples of vulnerabilities from improper handling of data structures shared over DMA, or of any specific drivers treating the input from PCI devices as trusted?

Limitations of VT-d as an IOMMU

I am aware of its limitations and don’t want an answer which tries to explain how a device could work around the IOMMU directly or use another loophole to gain control of the system. I know:

  • It cannot adequately protect a system unless x2APIC and Interrupt Remapping are supported.
  • Address Translation Services (ATS) can bypass the IOMMU.
  • Modified PCI expansion ROMs can attack the system on reboot.
  • All devices in a given IOMMU group have access to the same memory.
  • Some BIOSes come with a broken DMAR table, resulting in the IOMMU being disabled.
  • The CSME (“Intel ME”) may be able to disable VT-d via PSF and PAVP.
  • Yet unknown attacks may be capable of disabling or bypassing the IOMMU.

*DMA means Direct Memory Access. It is a hardware feature whereby certain hardware interfaces (like PCIe) are able to request direct access to system memory, without going through the CPU.


Get this bounty!!!

#StackBounty: #regression #nonparametric #kernel-smoothing #mse #kernel Minimizing MISE to find consistent estimator

Bounty: 50

Consider kernel regression estimation of the mean function $m$ of the process

$$y_t = m(x_t) + epsilon_t,$$ where $epsilon_t$‘ s are correlated with covariance function $R(s,t) = exp {-lambda|s-t|}$. In my scenario, $x_t$ is a function of a parameter $alpha$ and $R(s,t)$ is a function of $lambda$.

In a situation where $alpha$ and $lambda$ are known, we minimize the mean integrated squared error (MISE) to find an appropriate $h$.

My question is:
In my scenario, to find the smoothing parameter $h$ and estimate $alpha$ and $lambda$, can I minimize the MISE simultaneously with respect to $h$, $alpha$, and $lambda$? Will the minimizer of $alpha$ and $lambda$ be consistent (maybe under some additional conditions)?

Another option is: if I minimize MISE with respect to $h$ for $alpha$ and $ lambda$ fixed, put back the value of $h$ as an expression of $alpha$ and $lambda$ in MISE, and finally minimize it with respect to $alpha$ and $lambda$ simultaneously, will the estimators of $alpha$ and $lambda$ be consistent (maybe under some additional conditions)?

Or in another way, if I use an iterative algorithm: fix $alpha = alpha_0, lambda = lambda_0$ to find $h=h_0$, put the value of $h=h_0$ in MISE, minimize it with respect to $alpha, lambda$ to get $alpha = alpha_1, lambda = lambda_1$ and so on, how can I prove theoretically that the algorithm converges?

Any suggestions and/or related articles will be greatly appreciated!


Get this bounty!!!

#StackBounty: #kernel #wifi #firmware #yocto Yocto Boot2Qt Build for Colibri iMX6ULL no wifi interface

Bounty: 50

I have built the linux distro Boot2Qt from source with the yocto tools for the board Colibri iMX6ULL which has the integrated wifi chip Marvell W8997-M1216.

I installed the whole linux firmware-stack and i think also the correct kernel modules for the wifi chip.

There is no mlan interface showing up.

What exactly creates the mlan interface?
Is there something else i need to install?


Get this bounty!!!