Branch: refs/heads/master
Home: https://github.com/tianocore/edk2
Commit: b342070ce63075e7691cbd086ef8567cb02c372e
https://github.com/tianocore/edk2/commit/b342070ce63075e7691cbd086ef8567cb02c372e
Author: Sami Mujawar <sami.muja...@arm.com>
Date: 2024-07-31 (Wed, 31 Jul 2024)
Changed paths:
M OvmfPkg/VirtioBlkDxe/VirtioBlk.c
Log Message:
-----------
OvmfPkg: Use heap memory for virtio-blk request
The storage space for virtio-blk request header being shared
with the host was from the stack as the request structure was
a local function variable.
A bug in the VMM can corrupt the stack space, and such issues
can be very hard to debug.
Note: This is only an issue with a normal guest VM (non-CCA).
A CCA guest VM would perform bounce buffering for sharing the
data and therefore not have this issue.
Instead of using the stack for sharing the data with the host,
memory can be allocated from the heap pool. However, pool
allocations are not any safer in terms of pages being shared
between different allocations, and so mapping a pool allocation
for DMA may expose it to potential corruption by the VMM in
exactly the same way. The only difference is the potential
impact on program behaviour, which is much higher with the
stack.
Additionally, for guest-side corruption heap allocations can
take advantage by turning on heap guard to help find the bug.
Therefore, minor improvement can be achieved by allocating
memory for the virtio-blk request header from the heap for
sharing with the host.
Cc: Ard Biesheuvel <ardb+tianoc...@kernel.org>
Cc: Jiewen Yao <jiewen....@intel.com>
Cc: Gerd Hoffmann <kra...@redhat.com>
Signed-off-by: Sami Mujawar <sami.muja...@arm.com>
Commit: 1fc55a3933b0d17430c2857629ee54abefaad7eb
https://github.com/tianocore/edk2/commit/1fc55a3933b0d17430c2857629ee54abefaad7eb
Author: Sami Mujawar <sami.muja...@arm.com>
Date: 2024-07-31 (Wed, 31 Jul 2024)
Changed paths:
M OvmfPkg/VirtioScsiDxe/VirtioScsi.c
Log Message:
-----------
OvmfPkg: Use heap memory for virtio-scsi request
The storage space for virtio-scsi request header being shared
with the host was from the stack as the request structure was
a local function variable.
A bug in the VMM can corrupt the stack space, and such issues
can be very hard to debug.
Note: This is only an issue with a normal guest VM (non-CCA).
A CCA guest VM would perform bounce buffering for sharing the
data and therefore not have this issue.
Instead of using the stack for sharing the data with the host,
memory can be allocated from the heap pool. However, pool
allocations are not any safer in terms of pages being shared
between different allocations, and so mapping a pool allocation
for DMA may expose it to potential corruption by the VMM in
exactly the same way. The only difference is the potential
impact on program behaviour, which is much higher with the
stack.
Additionally, for guest-side corruption heap allocations can
take advantage by turning on heap guard to help find the bug.
Therefore, minor improvement can be achieved by allocating
memory for the virtio-scsi request header from the heap for
sharing with the host.
Cc: Ard Biesheuvel <ardb+tianoc...@kernel.org>
Cc: Jiewen Yao <jiewen....@intel.com>
Cc: Gerd Hoffmann <kra...@redhat.com>
Signed-off-by: Sami Mujawar <sami.muja...@arm.com>
Compare: https://github.com/tianocore/edk2/compare/02f7ecbbb2da...1fc55a3933b0
To unsubscribe from these emails, change your notification settings at
https://github.com/tianocore/edk2/settings/notifications
_______________________________________________
edk2-commits mailing list
edk2-commits@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-commits
