Since commit 5d971f9e67 we don't accept mismatching sizes
in memory_region_access_valid(). This gives troubles when
a device is on an ISA bus, because the CPU is free to use
8/16-bit accesses on the bus (or up to 32-bit on EISA bus),
regardless what range is valid for the device.

Monkey-patch the ISA device MemoryRegionOps to force it
to accepts 8/16/32-bit accesses. This should be reverted
after the release and fixed in a more elegant manner.

Related bug reports:

- https://lore.kernel.org/xen-devel/20200630170913.123646-1-anthony.perard@citrix.com/T/
- https://bugs.debian.org/964793
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964247
- https://bugs.launchpad.net/bugs/1886318

Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
---
 hw/isa/isa-bus.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/hw/isa/isa-bus.c b/hw/isa/isa-bus.c
index 58fde178f9..c8aed2f55f 100644
--- a/hw/isa/isa-bus.c
+++ b/hw/isa/isa-bus.c
@@ -132,6 +132,20 @@ static inline void isa_init_ioport(ISADevice *dev, uint16_t ioport)
 
 void isa_register_ioport(ISADevice *dev, MemoryRegion *io, uint16_t start)
 {
+    if (io->ops->valid.min_access_size > 1 ||
+        io->ops->valid.max_access_size < 4) {
+        warn_report_once("Monkey-patching ISA I/O access sizes "
+                         "(side effect of CVE-2020-13754, only for QEMU v5.1)");
+        /*
+         * To be backward compatible with IBM-PC bus, ISA bus must accept
+         * 8-bit accesses.
+         */
+        io->ops->valid.min_access_size = 1;
+        /*
+         * EISA bus must accept 32-bit accesses.
+         */
+        io->ops->valid.max_access_size = 4;
+    }
     memory_region_add_subregion(isabus->address_space_io, start, io);
     isa_init_ioport(dev, start);
 }
-- 
2.21.3

On Tue, 21 Jul 2020 at 13:31, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
>
> Since commit 5d971f9e67 we don't accept mismatching sizes
> in memory_region_access_valid(). This gives troubles when
> a device is on an ISA bus, because the CPU is free to use
> 8/16-bit accesses on the bus (or up to 32-bit on EISA bus),
> regardless what range is valid for the device.
>
> Monkey-patch the ISA device MemoryRegionOps to force it
> to accepts 8/16/32-bit accesses. This should be reverted
> after the release and fixed in a more elegant manner.

Do we need something similar for isa_register_portio_list(),
or is that function OK ?

Do we have a view on what the 'more elegant manner' would look like?

thanks
-- PMM

On 7/21/20 2:41 PM, Peter Maydell wrote:
> On Tue, 21 Jul 2020 at 13:31, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
>>
>> Since commit 5d971f9e67 we don't accept mismatching sizes
>> in memory_region_access_valid(). This gives troubles when
>> a device is on an ISA bus, because the CPU is free to use
>> 8/16-bit accesses on the bus (or up to 32-bit on EISA bus),
>> regardless what range is valid for the device.
>>
>> Monkey-patch the ISA device MemoryRegionOps to force it
>> to accepts 8/16/32-bit accesses. This should be reverted
>> after the release and fixed in a more elegant manner.
> 
> Do we need something similar for isa_register_portio_list(),
> or is that function OK ?
> 
> Do we have a view on what the 'more elegant manner' would look like?

What I suggested on IRC is a isabus->address_space_io is not assigned
by the bus creator but created internally as a MemoryRegion container
accepting 8/16 (ISA bus) or 8/16/32-bit (EISA bus) accesses from the I/O
address space, and this MR uses memory::access_with_adjusted_size()
(or similar) to access the registered portio devices.

We already have isa_address_space_io() to access
isabus->address_space_io.

isa_bus_new() could takes an 'is_eisa' boolean argument to select
between the adjusting MR.

> 
> thanks
> -- PMM
>