#iommu — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #iommu, aggregated by home.social.
-
so i tried to make a nested proxmox vgpu thingy. but it doesnt work cause when i enabled viommu on the vm the nvidia driver fails(RmInitAdapter failed) but when i disable viommu mdev doesnt work cause it needs /sys/kernel/iommu_groups/ which only exsists with iommu. i fucking hate this bullshit.
#proxmox #vgpu #viommu #iommu #gpu #nvidia #server #homelab #selfhosting #vm #qemu #pciepassthrough #mdev
-
so i tried to make a nested proxmox vgpu thingy. but it doesnt work cause when i enabled viommu on the vm the nvidia driver fails(RmInitAdapter failed) but when i disable viommu mdev doesnt work cause it needs /sys/kernel/iommu_groups/ which only exsists with iommu. i fucking hate this bullshit.
#proxmox #vgpu #viommu #iommu #gpu #nvidia #server #homelab #selfhosting #vm #qemu #pciepassthrough #mdev
-
Tried using SR-IOV and IOMMU on my computer and it clearly did not like that as it prevented me from getting into the UEFI or boot menu from POST. The GRUB entry for the UEFI Firmware Settings thing worked, but after turning them off I had to shut my computer down fully as a reboot didn't fix it.
-
Tried using SR-IOV and IOMMU on my computer and it clearly did not like that as it prevented me from getting into the UEFI or boot menu from POST. The GRUB entry for the UEFI Firmware Settings thing worked, but after turning them off I had to shut my computer down fully as a reboot didn't fix it.
-
Tried using SR-IOV and IOMMU on my computer and it clearly did not like that as it prevented me from getting into the UEFI or boot menu from POST. The GRUB entry for the UEFI Firmware Settings thing worked, but after turning them off I had to shut my computer down fully as a reboot didn't fix it.
-
Tried using SR-IOV and IOMMU on my computer and it clearly did not like that as it prevented me from getting into the UEFI or boot menu from POST. The GRUB entry for the UEFI Firmware Settings thing worked, but after turning them off I had to shut my computer down fully as a reboot didn't fix it.
-
Tried using SR-IOV and IOMMU on my computer and it clearly did not like that as it prevented me from getting into the UEFI or boot menu from POST. The GRUB entry for the UEFI Firmware Settings thing worked, but after turning them off I had to shut my computer down fully as a reboot didn't fix it.
-
-
-
-
-
PSA for anyone using #QEMU #KVM for #SingleGPUPassthrough
Guides are all over the net suggesting hooks scripts invoking pci devices, unloading/loading kernel modules, and other unnecessary things. Here's my current hook script for starting the VM:systemctl stop display-managerThat's it. And the reverse for teardown:
systemctl start display-manager#IOMMU groups still apply, and you need to pass the correct PCI devices to your VM, but everything else is handled automatically.
Disclaimer that this is how it works currently for my AMD card. I did have a working setup with my NVIDIA card that did unload/load kernel modules, however it seems things have come a long way since I set that up.
-
PSA for anyone using #QEMU #KVM for #SingleGPUPassthrough
Guides are all over the net suggesting hooks scripts invoking pci devices, unloading/loading kernel modules, and other unnecessary things. Here's my current hook script for starting the VM:systemctl stop display-managerThat's it. And the reverse for teardown:
systemctl start display-manager#IOMMU groups still apply, and you need to pass the correct PCI devices to your VM, but everything else is handled automatically.
Disclaimer that this is how it works currently for my AMD card. I did have a working setup with my NVIDIA card that did unload/load kernel modules, however it seems things have come a long way since I set that up.
-
Отражаем атаку на IOMMU
Что вы знаете об атаках на графические процессоры? Наверняка ничего приятного: они крайне распространены на мобильных устройствах, классические «песочницы» от них не защищают, и компрометация лишь одного драйвера может поставить под угрозу все ядро… Меня зовут Денис Молодяков, и я — лид команды графики в KasperskyOS. Идея этого текста возникла во время одного моего выступления на конференции по системной разработке. Тогда из зала задали вопрос, который касался безопасности работы драйверов GPU. Слушатель ссылался на кейсы с «подламыванием» механизма управления видеопамятью драйверов на Android для интегрированных ускорителей семейства ARM Mali и спросил, как наша ОС сможет этому противостоять. Поэтому в данном материале я подробно расскажу о сути этой коварной атаки, а также рассмотрю и другие типы атак через GPU. В заключение я смоделирую подобные сценарии для нашей микроядерной KasperskyOS и покажу, как мы их митигируем.
https://habr.com/ru/companies/kaspersky/articles/992032/
#IOMMU #DMA #GPU #kasperskyos #кибербезопасность #атаки #кибератаки #процессоры
-
Отражаем атаку на IOMMU
Что вы знаете об атаках на графические процессоры? Наверняка ничего приятного: они крайне распространены на мобильных устройствах, классические «песочницы» от них не защищают, и компрометация лишь одного драйвера может поставить под угрозу все ядро… Меня зовут Денис Молодяков, и я — лид команды графики в KasperskyOS. Идея этого текста возникла во время одного моего выступления на конференции по системной разработке. Тогда из зала задали вопрос, который касался безопасности работы драйверов GPU. Слушатель ссылался на кейсы с «подламыванием» механизма управления видеопамятью драйверов на Android для интегрированных ускорителей семейства ARM Mali и спросил, как наша ОС сможет этому противостоять. Поэтому в данном материале я подробно расскажу о сути этой коварной атаки, а также рассмотрю и другие типы атак через GPU. В заключение я смоделирую подобные сценарии для нашей микроядерной KasperskyOS и покажу, как мы их митигируем.
https://habr.com/ru/companies/kaspersky/articles/992032/
#IOMMU #DMA #GPU #kasperskyos #кибербезопасность #атаки #кибератаки #процессоры
-
Отражаем атаку на IOMMU
Что вы знаете об атаках на графические процессоры? Наверняка ничего приятного: они крайне распространены на мобильных устройствах, классические «песочницы» от них не защищают, и компрометация лишь одного драйвера может поставить под угрозу все ядро… Меня зовут Денис Молодяков, и я — лид команды графики в KasperskyOS. Идея этого текста возникла во время одного моего выступления на конференции по системной разработке. Тогда из зала задали вопрос, который касался безопасности работы драйверов GPU. Слушатель ссылался на кейсы с «подламыванием» механизма управления видеопамятью драйверов на Android для интегрированных ускорителей семейства ARM Mali и спросил, как наша ОС сможет этому противостоять. Поэтому в данном материале я подробно расскажу о сути этой коварной атаки, а также рассмотрю и другие типы атак через GPU. В заключение я смоделирую подобные сценарии для нашей микроядерной KasperskyOS и покажу, как мы их митигируем.
https://habr.com/ru/companies/kaspersky/articles/992032/
#IOMMU #DMA #GPU #kasperskyos #кибербезопасность #атаки #кибератаки #процессоры
-
Riot Games deckt kritische Motherboard-Schwachstelle auf
Die Lücke erlaubt es Angreifern mit spezieller Hardware, unerkannt Schadcode zu implementieren – selbst wenn die vorgesehenen Sicherheitsmechanismen aktiviert sind.
https://www.all-about-security.de/riot-games-deckt-kritische-motherboard-schwachstelle-auf/
-
🎯 Threat Intelligence
===================Executive summary: Riot Games' Vanguard team discovered a critical weakness in the pre-boot trust model on a range of modern motherboards that can let hardware-based DMA devices inject or manipulate code before the OS initializes. The issue centers on failures or gaps in the firmware's use of IOMMU-based pre-boot DMA protection.
Technical details:
• The vulnerability affects the early boot path where firmware/UEFI initializes platform hardware. Devices that gain access to system memory before the OS is running can obtain higher privileges and persistence.
• DMA devices (specialized PCIe cards or similar hardware) perform Direct Memory Access bypassing CPU-mediated protections. The expected mitigation is an IOMMU that enforces address translations and blocks unauthorized DMA mappings during pre-boot.
• Vanguard's research describes cases where the firmware's "Pre-Boot DMA Protection" did not reliably engage the IOMMU checks, allowing DMA access to system memory while security features like Secure Boot and VBS appeared nominally enabled.🔹 Attack Chain Analysis
• Initial Access / Early Boot Compromise: Malicious DMA hardware attaches and asserts memory mappings before OS initialization.
• Execution / Privilege Escalation: Early-loaded code executes with elevated privileges relative to the OS and can modify firmware or kernel-critical structures.
• Persistence / Evasion: Compromised pre-OS components can hide from OS-level integrity checks and anti-cheat hooks.Analysis: The root issue is a trust gap: the OS and kernel-mode defenses assume that platform firmware correctly initialized and enforced DMA isolation. If firmware-level pre-boot protections fail, early-loading hardware can subvert kernel perimeter assumptions.
Detection (as reported): Vanguard will enforce stricter boot integrity checks and surface VAN:Restriction prompts to users on platforms judged to be affected. Detection focuses on validating pre-boot DMA protections and kernel perimeter integrity at earliest possible runtime.
Mitigation (as reported): The primary operational response described is firmware updates for affected motherboards delivered or recommended via Vanguard's VAN:Restriction workflow. The article also reiterates that Secure Boot, VBS, and a properly functioning IOMMU are effective when correctly engaged.
Limitations and uncertainties: The disclosure does not list specific vendor models, CVE identifiers, or technical IoCs for public consumption. The scope and exact enumeration of affected motherboard models were not published in the disclosed text.
🔹 vanguard #iommu #pre_boot_dma #firmware_security #anticheat
🔗 Source: https://www.riotgames.com/en/news/vanguard-security-update-motherboard
-
any idea how to turn on #IOMMU protection on a #framework 12? Got this one error in the gnome security report :)
-
any idea how to turn on #IOMMU protection on a #framework 12? Got this one error in the gnome security report :)
-
any idea how to turn on #IOMMU protection on a #framework 12? Got this one error in the gnome security report :)
-
any idea how to turn on #IOMMU protection on a #framework 12? Got this one error in the gnome security report :)
-
any idea how to turn on #IOMMU protection on a #framework 12? Got this one error in the gnome security report :)
-
Is there a good resource for knowing which #gpu and #motherboard combinations (hardware and #bios) should work for #pciepassthrough #iommu under #proxmox for #llm ?
-
Is there a good resource for knowing which #gpu and #motherboard combinations (hardware and #bios) should work for #pciepassthrough #iommu under #proxmox for #llm ?
-
Is there a good resource for knowing which #gpu and #motherboard combinations (hardware and #bios) should work for #pciepassthrough #iommu under #proxmox for #llm ?
-
Is there a good resource for knowing which #gpu and #motherboard combinations (hardware and #bios) should work for #pciepassthrough #iommu under #proxmox for #llm ?
-
Is there a good resource for knowing which #gpu and #motherboard combinations (hardware and #bios) should work for #pciepassthrough #iommu under #proxmox for #llm ?
-
You connect your monitors to a USB-C/Thunderbolt dock, all to then have the screens turn off erratically, or devices connected over USB acting up by turning off at random times? Sounds familiar? You are not alone!
What if I told that this is because you have not told the kernel that you need IOMMU enabled on your machine? This is particularly true if your monitors also have docks themselves, and the sheer IO overhead is overwhelming your system. How to solve it?
First, check your device BIOS and see if there is an option to enable IOMMU. Then proceed to enable IOMMU on the kernel:
For AMD: "amd_iommu=on iommu=pt"
For Intel: "intel_iommu=on iommu=pt"On Fedora, we use grubby to update our kernel arguments:
sudo grubby --args="amd_iommu=on iommu=pt" --update-kernel=ALLReboot and enjoy a much stabler USB, multi-monitor peripherals handling! The reason it's not ON by default is that there is a tiny overhead in memory usage. Read more about IOMMU: https://en.wikipedia.org/wiki/Input%E2%80%93output_memory_management_unit
-
You connect your monitors to a USB-C/Thunderbolt dock, all to then have the screens turn off erratically, or devices connected over USB acting up by turning off at random times? Sounds familiar? You are not alone!
What if I told that this is because you have not told the kernel that you need IOMMU enabled on your machine? This is particularly true if your monitors also have docks themselves, and the sheer IO overhead is overwhelming your system. How to solve it?
First, check your device BIOS and see if there is an option to enable IOMMU. Then proceed to enable IOMMU on the kernel:
For AMD: "amd_iommu=on iommu=pt"
For Intel: "intel_iommu=on iommu=pt"On Fedora, we use grubby to update our kernel arguments:
sudo grubby --args="amd_iommu=on iommu=pt" --update-kernel=ALLReboot and enjoy a much stabler USB, multi-monitor peripherals handling! The reason it's not ON by default is that there is a tiny overhead in memory usage. Read more about IOMMU: https://en.wikipedia.org/wiki/Input%E2%80%93output_memory_management_unit
-
You connect your monitors to a USB-C/Thunderbolt dock, all to then have the screens turn off erratically, or devices connected over USB acting up by turning off at random times? Sounds familiar? You are not alone!
What if I told that this is because you have not told the kernel that you need IOMMU enabled on your machine? This is particularly true if your monitors also have docks themselves, and the sheer IO overhead is overwhelming your system. How to solve it?
First, check your device BIOS and see if there is an option to enable IOMMU. Then proceed to enable IOMMU on the kernel:
For AMD: "amd_iommu=on iommu=pt"
For Intel: "intel_iommu=on iommu=pt"On Fedora, we use grubby to update our kernel arguments:
sudo grubby --args="amd_iommu=on iommu=pt" --update-kernel=ALLReboot and enjoy a much stabler USB, multi-monitor peripherals handling! The reason it's not ON by default is that there is a tiny overhead in memory usage. Read more about IOMMU: https://en.wikipedia.org/wiki/Input%E2%80%93output_memory_management_unit
-
You connect your monitors to a USB-C/Thunderbolt dock, all to then have the screens turn off erratically, or devices connected over USB acting up by turning off at random times? Sounds familiar? You are not alone!
What if I told that this is because you have not told the kernel that you need IOMMU enabled on your machine? This is particularly true if your monitors also have docks themselves, and the sheer IO overhead is overwhelming your system. How to solve it?
First, check your device BIOS and see if there is an option to enable IOMMU. Then proceed to enable IOMMU on the kernel:
For AMD: "amd_iommu=on iommu=pt"
For Intel: "intel_iommu=on iommu=pt"On Fedora, we use grubby to update our kernel arguments:
sudo grubby --args="amd_iommu=on iommu=pt" --update-kernel=ALLReboot and enjoy a much stabler USB, multi-monitor peripherals handling! The reason it's not ON by default is that there is a tiny overhead in memory usage. Read more about IOMMU: https://en.wikipedia.org/wiki/Input%E2%80%93output_memory_management_unit
-
You connect your monitors to a USB-C/Thunderbolt dock, all to then have the screens turn off erratically, or devices connected over USB acting up by turning off at random times? Sounds familiar? You are not alone!
What if I told that this is because you have not told the kernel that you need IOMMU enabled on your machine? This is particularly true if your monitors also have docks themselves, and the sheer IO overhead is overwhelming your system. How to solve it?
First, check your device BIOS and see if there is an option to enable IOMMU. Then proceed to enable IOMMU on the kernel:
For AMD: "amd_iommu=on iommu=pt"
For Intel: "intel_iommu=on iommu=pt"On Fedora, we use grubby to update our kernel arguments:
sudo grubby --args="amd_iommu=on iommu=pt" --update-kernel=ALLReboot and enjoy a much stabler USB, multi-monitor peripherals handling! The reason it's not ON by default is that there is a tiny overhead in memory usage. Read more about IOMMU: https://en.wikipedia.org/wiki/Input%E2%80%93output_memory_management_unit
-
Man I prolly have hard-rebooted my #Proxmox server almost or over 10 times now probably - all bcos, somehow, after adding a PCI device (passthrough), particularly a SATA card to my #TrueNAS VM, each time I boot it up Proxmox would just... hang forever and become inaccessible despite still "running".
The error it spits out is:Pool 'rpool' has encountered an uncorrectable I/O failure and has been suspended
This move away from #ESXi is a lot more painful than I imagined.
---
Update: Might have found the culprit, and that it possibly has to do with its #IOMMU group number. That is, on Proxmox, even when you think you're sharing the one PCI device you've selected, you're actually also sharing the entire IOMMU group sharing the same number, which in my case is like... almost everything else.
I'm just perplexed by how ESXi was able to passthrough the device just fine, on the exact same hardware setup? I really don't wanna go back tho, but I'm not sure if there's even a solution to this, since I couldn't really move this SATA card anywhere else.
🔗 https://forum.proxmox.com/threads/proxmox-freeze-when-launching-gpu-passthroughed-vm.104801
RE: https://sakurajima.social/notes/a1vvx0jo6u -
Man I prolly have hard-rebooted my #Proxmox server almost or over 10 times now probably - all bcos, somehow, after adding a PCI device (passthrough), particularly a SATA card to my #TrueNAS VM, each time I boot it up Proxmox would just... hang forever and become inaccessible despite still "running".
The error it spits out is:Pool 'rpool' has encountered an uncorrectable I/O failure and has been suspended
This move away from #ESXi is a lot more painful than I imagined.
---
Update: Might have found the culprit, and that it possibly has to do with its #IOMMU group number. That is, on Proxmox, even when you think you're sharing the one PCI device you've selected, you're actually also sharing the entire IOMMU group sharing the same number, which in my case is like... almost everything else.
I'm just perplexed by how ESXi was able to passthrough the device just fine, on the exact same hardware setup? I really don't wanna go back tho, but I'm not sure if there's even a solution to this, since I couldn't really move this SATA card anywhere else.
🔗 https://forum.proxmox.com/threads/proxmox-freeze-when-launching-gpu-passthroughed-vm.104801
RE: https://sakurajima.social/notes/a1vvx0jo6u -
Man I prolly have hard-rebooted my #Proxmox server almost or over 10 times now probably - all bcos, somehow, after adding a PCI device (passthrough), particularly a SATA card to my #TrueNAS VM, each time I boot it up Proxmox would just... hang forever and become inaccessible despite still "running".
The error it spits out is:Pool 'rpool' has encountered an uncorrectable I/O failure and has been suspended
This move away from #ESXi is a lot more painful than I imagined.
---
Update: Might have found the culprit, and that it possibly has to do with its #IOMMU group number. That is, on Proxmox, even when you think you're sharing the one PCI device you've selected, you're actually also sharing the entire IOMMU group sharing the same number, which in my case is like... almost everything else.
I'm just perplexed by how ESXi was able to passthrough the device just fine, on the exact same hardware setup? I really don't wanna go back tho, but I'm not sure if there's even a solution to this, since I couldn't really move this SATA card anywhere else.
🔗 https://forum.proxmox.com/threads/proxmox-freeze-when-launching-gpu-passthroughed-vm.104801
RE: https://sakurajima.social/notes/a1vvx0jo6u -
Man I prolly have hard-rebooted my #Proxmox server almost or over 10 times now probably - all bcos, somehow, after adding a PCI device (passthrough), particularly a SATA card to my #TrueNAS VM, each time I boot it up Proxmox would just... hang forever and become inaccessible despite still "running".
The error it spits out is:Pool 'rpool' has encountered an uncorrectable I/O failure and has been suspended
This move away from #ESXi is a lot more painful than I imagined.
---
Update: Might have found the culprit, and that it possibly has to do with its #IOMMU group number. That is, on Proxmox, even when you think you're sharing the one PCI device you've selected, you're actually also sharing the entire IOMMU group sharing the same number, which in my case is like... almost everything else.
I'm just perplexed by how ESXi was able to passthrough the device just fine, on the exact same hardware setup? I really don't wanna go back tho, but I'm not sure if there's even a solution to this, since I couldn't really move this SATA card anywhere else.
🔗 https://forum.proxmox.com/threads/proxmox-freeze-when-launching-gpu-passthroughed-vm.104801
RE: https://sakurajima.social/notes/a1vvx0jo6u -
Man I prolly have hard-rebooted my #Proxmox server almost or over 10 times now probably - all bcos, somehow, after adding a PCI device (passthrough), particularly a SATA card to my #TrueNAS VM, each time I boot it up Proxmox would just... hang forever and become inaccessible despite still "running".
The error it spits out is:Pool 'rpool' has encountered an uncorrectable I/O failure and has been suspended
This move away from #ESXi is a lot more painful than I imagined.
---
Update: Might have found the culprit, and that it possibly has to do with its #IOMMU group number. That is, on Proxmox, even when you think you're sharing the one PCI device you've selected, you're actually also sharing the entire IOMMU group sharing the same number, which in my case is like... almost everything else.
I'm just perplexed by how ESXi was able to passthrough the device just fine, on the exact same hardware setup? I really don't wanna go back tho, but I'm not sure if there's even a solution to this, since I couldn't really move this SATA card anywhere else.
🔗 https://forum.proxmox.com/threads/proxmox-freeze-when-launching-gpu-passthroughed-vm.104801
RE: https://sakurajima.social/notes/a1vvx0jo6u -
I have 2 Western Digital Blue 4 TB drives that I pulled from my main PC (that I built 8 years ago) and put them into a 2U server. I am going to run them in RAID0 and see how long they last.
They are hybrid and actually have 8GB SSD cache each. It is an experiment to see them on a dedicated PCI SATA card that is assigned to a VM on #proxmox (as the hypervisor) running the ProxMox Backup Server OS on the VM. Of course, I had to enable #iommu.
What could possibly go wrong? #yolo
-
I have 2 Western Digital Blue 4 TB drives that I pulled from my main PC (that I built 8 years ago) and put them into a 2U server. I am going to run them in RAID0 and see how long they last.
They are hybrid and actually have 8GB SSD cache each. It is an experiment to see them on a dedicated PCI SATA card that is assigned to a VM on #proxmox (as the hypervisor) running the ProxMox Backup Server OS on the VM. Of course, I had to enable #iommu.
What could possibly go wrong? #yolo
-
I have 2 Western Digital Blue 4 TB drives that I pulled from my main PC (that I built 8 years ago) and put them into a 2U server. I am going to run them in RAID0 and see how long they last.
They are hybrid and actually have 8GB SSD cache each. It is an experiment to see them on a dedicated PCI SATA card that is assigned to a VM on #proxmox (as the hypervisor) running the ProxMox Backup Server OS on the VM. Of course, I had to enable #iommu.
What could possibly go wrong? #yolo
-
I have 2 Western Digital Blue 4 TB drives that I pulled from my main PC (that I built 8 years ago) and put them into a 2U server. I am going to run them in RAID0 and see how long they last.
They are hybrid and actually have 8GB SSD cache each. It is an experiment to see them on a dedicated PCI SATA card that is assigned to a VM on #proxmox (as the hypervisor) running the ProxMox Backup Server OS on the VM. Of course, I had to enable #iommu.
What could possibly go wrong? #yolo
-
I have 2 Western Digital Blue 4 TB drives that I pulled from my main PC (that I built 8 years ago) and put them into a 2U server. I am going to run them in RAID0 and see how long they last.
They are hybrid and actually have 8GB SSD cache each. It is an experiment to see them on a dedicated PCI SATA card that is assigned to a VM on #proxmox (as the hypervisor) running the ProxMox Backup Server OS on the VM. Of course, I had to enable #iommu.
What could possibly go wrong? #yolo
-
DaMAgeCard: как индустрия карт памяти SD воскресила DMA-атаки
Размеры медиа-файлов кардинально растут, а вместе с ними растут и требования к скорости носителей. Копировать сотни гигабайт RAW-изображений с обычной, даже высокоскоростной SD-карты стандарта UHS-II стало слишком долго. И вот жалобы фотографов на то, что кофе успевает остыть, пока все данные будут скопированы с карты, дошли до председателей SD Association и CompactFlash Association, и те приняли решительные меры: выпустили стандарт SD Express (и CFexpress ). Наша команда ( Positive Labs ) занимается исследованием безопасности программно-аппаратных систем и системного ПО. Поэтому мы внимательно наблюдали за развитием событий еще с 2018 года — с момента публикации стандарта, который обещал огромный прирост скорости за счет подключения карты к шине PCIe. Но мы следили не только за бенчмарками скорости, хотя она, конечно, внушительная. Наличие PCIe потенциально опасно из-за возможности доступа к памяти устройства, а это очень интересный вектор атак.Вот только до недавнего времени производители контроллеров и пользовательских устройств не спешили с поддержкой стандарта SD Express. Мы уже даже было обрадовались, что они научились на своих ошибках, и теперь не хотят давать внешним устройствам доступ к памяти (спойлер: нет ). А пока расскажем, почему уделяем столько внимания почтенной шине PCI.
https://habr.com/ru/companies/pt/articles/863536/
#dmaатака #sd_express #bus_master #pci #cardbus #firewire #expresscard #thunderbolt #схемотехника #iommu
-
DaMAgeCard: как индустрия карт памяти SD воскресила DMA-атаки
Размеры медиа-файлов кардинально растут, а вместе с ними растут и требования к скорости носителей. Копировать сотни гигабайт RAW-изображений с обычной, даже высокоскоростной SD-карты стандарта UHS-II стало слишком долго. И вот жалобы фотографов на то, что кофе успевает остыть, пока все данные будут скопированы с карты, дошли до председателей SD Association и CompactFlash Association, и те приняли решительные меры: выпустили стандарт SD Express (и CFexpress ). Наша команда ( Positive Labs ) занимается исследованием безопасности программно-аппаратных систем и системного ПО. Поэтому мы внимательно наблюдали за развитием событий еще с 2018 года — с момента публикации стандарта, который обещал огромный прирост скорости за счет подключения карты к шине PCIe. Но мы следили не только за бенчмарками скорости, хотя она, конечно, внушительная. Наличие PCIe потенциально опасно из-за возможности доступа к памяти устройства, а это очень интересный вектор атак.Вот только до недавнего времени производители контроллеров и пользовательских устройств не спешили с поддержкой стандарта SD Express. Мы уже даже было обрадовались, что они научились на своих ошибках, и теперь не хотят давать внешним устройствам доступ к памяти (спойлер: нет ). А пока расскажем, почему уделяем столько внимания почтенной шине PCI.
https://habr.com/ru/companies/pt/articles/863536/
#dmaатака #sd_express #bus_master #pci #cardbus #firewire #expresscard #thunderbolt #схемотехника #iommu
-
DaMAgeCard: как индустрия карт памяти SD воскресила DMA-атаки
Размеры медиа-файлов кардинально растут, а вместе с ними растут и требования к скорости носителей. Копировать сотни гигабайт RAW-изображений с обычной, даже высокоскоростной SD-карты стандарта UHS-II стало слишком долго. И вот жалобы фотографов на то, что кофе успевает остыть, пока все данные будут скопированы с карты, дошли до председателей SD Association и CompactFlash Association, и те приняли решительные меры: выпустили стандарт SD Express (и CFexpress ). Наша команда ( Positive Labs ) занимается исследованием безопасности программно-аппаратных систем и системного ПО. Поэтому мы внимательно наблюдали за развитием событий еще с 2018 года — с момента публикации стандарта, который обещал огромный прирост скорости за счет подключения карты к шине PCIe. Но мы следили не только за бенчмарками скорости, хотя она, конечно, внушительная. Наличие PCIe потенциально опасно из-за возможности доступа к памяти устройства, а это очень интересный вектор атак.Вот только до недавнего времени производители контроллеров и пользовательских устройств не спешили с поддержкой стандарта SD Express. Мы уже даже было обрадовались, что они научились на своих ошибках, и теперь не хотят давать внешним устройствам доступ к памяти (спойлер: нет ). А пока расскажем, почему уделяем столько внимания почтенной шине PCI.
https://habr.com/ru/companies/pt/articles/863536/
#dmaатака #sd_express #bus_master #pci #cardbus #firewire #expresscard #thunderbolt #схемотехника #iommu
-
Пытаюсь решить проблему с OBS, которая уже давно меня напрягает.
При запуске OBS, через какое - то время отрубается мышь (проводная/без проводная). Спустя еще какое-то время, вешается звуковой сервер, а еще погодя начинаются лаги в гуи.
При этом в логе херачат записи переполнения буфера и
'AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0010 address=0xbeac5000 flags=0x0000]'
Отключил в UEFI - IOMMU, и пока ничего еще не отвалилось. Осталось разобраться с переполнением буфера
#obs #amd #iommu #archlinux #xhci_hcd -
Пытаюсь решить проблему с OBS, которая уже давно меня напрягает.
При запуске OBS, через какое - то время отрубается мышь (проводная/без проводная). Спустя еще какое-то время, вешается звуковой сервер, а еще погодя начинаются лаги в гуи.
При этом в логе херачат записи переполнения буфера и
'AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0010 address=0xbeac5000 flags=0x0000]'
Отключил в UEFI - IOMMU, и пока ничего еще не отвалилось. Осталось разобраться с переполнением буфера
#obs #amd #iommu #archlinux #xhci_hcd -
Пытаюсь решить проблему с OBS, которая уже давно меня напрягает.
При запуске OBS, через какое - то время отрубается мышь (проводная/без проводная). Спустя еще какое-то время, вешается звуковой сервер, а еще погодя начинаются лаги в гуи.
При этом в логе херачат записи переполнения буфера и
'AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0010 address=0xbeac5000 flags=0x0000]'
Отключил в UEFI - IOMMU, и пока ничего еще не отвалилось. Осталось разобраться с переполнением буфера
#obs #amd #iommu #archlinux #xhci_hcd -
#virtualization #qemu #kvm #iommu
Конспект "Practical Notes on the Virtualization Stack - QEMU, KVM, IOMMU, and more".
http://lastweek.io/pubs/virt_note.pdfАвтор документа - инженер (научный сотрудник Yizhou Shan) Huawei Cloud.
На сайте есть занятных материалов по виртуализации (и не только).
-
#virtualization #qemu #kvm #iommu
Конспект "Practical Notes on the Virtualization Stack - QEMU, KVM, IOMMU, and more".
http://lastweek.io/pubs/virt_note.pdfАвтор документа - инженер (научный сотрудник Yizhou Shan) Huawei Cloud.
На сайте есть занятных материалов по виртуализации (и не только).
-
#virtualization #qemu #kvm #iommu
Конспект "Practical Notes on the Virtualization Stack - QEMU, KVM, IOMMU, and more".
http://lastweek.io/pubs/virt_note.pdfАвтор документа - инженер (научный сотрудник Yizhou Shan) Huawei Cloud.
На сайте есть занятных материалов по виртуализации (и не только).
