blob: 540e301666b053d3b8d879200e2de35b4749ab9e (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
|
graphic: 0.826
other: 0.808
KVM: 0.786
instruction: 0.769
device: 0.749
network: 0.709
assembly: 0.684
mistranslation: 0.659
socket: 0.652
boot: 0.626
semantic: 0.601
vnc: 0.586
ide_dma_cb: Assertion `prep_size >= 0 && prep_size <= n * 512' failed.
To reproduce run the QEMU with the following command line:
```
qemu-system-x86_64 -cdrom hypertrash.iso -nographic -m 100 -enable-kvm -net none -drive id=disk,file=hda.img,if=none -device ahci,id=ahci -device ide-hd,drive=disk,bus=ahci.0
```
QEMU Version:
```
# qemu-5.0.0
$ ./configure --target-list=x86_64-softmmu --enable-sanitizers; make
$ x86_64-softmmu/qemu-system-x86_64 --version
QEMU emulator version 5.0.0
Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers
```
To create disk image run:
```
dd if=/dev/zero of=hda.img bs=1024 count=1024
```
ACK. I do not have time to fix this bug at the moment under the belief that it's likely low-priority and only "misbehaving guests" can trigger it. Some advice:
1. Do not use IDE in production deployments after initial installation, if you can help it. Use a performant virtio solution.
2. If anyone would like to fix this problem, I will be more than happy to point you to the exact lines of code that cause the problem. I think the fix will be easy, but testing will be time-consuming as it involves understanding error behavior of real hardware that I don't personally have the setup to quickly test or verify.
From memory: the problem is that ide_dma_cb expects that it was able to prepare at least one sector's worth of scatter-gather list to begin DMA, but it's possible to give malformed SG lists where IDE is unable to process the remainder of a sector in a list.
It was not clear to me at the time when I first investigated this what a real controller would do if it got an incomplete sector and how it should signal that.
It was also not clear to me if the sg_prepare function for the pci bmdma controller would ever encounter a situation where further entries in the list might be received "later" and we should "wait" for them.
If this bug is more dangerous than a self-inflicted DOS, please let me know and I'll re-prioritize. Patches, email and IRC chats welcome.
--js
|