The write/read should be paired, this can avoid the
NULL-deref while the guest reads the fw_cfg port.

Signed-off-by: Li Qiang <liq3ea@gmail.com>
---
 hw/nvram/fw_cfg.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
index d79a568f54..6de7809f1a 100644
--- a/hw/nvram/fw_cfg.c
+++ b/hw/nvram/fw_cfg.c
@@ -434,6 +434,11 @@ static bool fw_cfg_data_mem_valid(void *opaque, hwaddr addr,
     return addr == 0;
 }
 
+static uint64_t fw_cfg_ctl_mem_read(void *opaque, hwaddr addr, unsigned size)
+{
+    return 0;
+}
+
 static void fw_cfg_ctl_mem_write(void *opaque, hwaddr addr,
                                  uint64_t value, unsigned size)
 {
@@ -468,6 +473,7 @@ static bool fw_cfg_comb_valid(void *opaque, hwaddr addr,
 }
 
 static const MemoryRegionOps fw_cfg_ctl_mem_ops = {
+    .read = fw_cfg_ctl_mem_read,
     .write = fw_cfg_ctl_mem_write,
     .endianness = DEVICE_BIG_ENDIAN,
     .valid.accepts = fw_cfg_ctl_mem_valid,
-- 
2.11.0

Hi

On Wed, Sep 12, 2018 at 9:22 AM Li Qiang <liq3ea@gmail.com> wrote:
>
> The write/read should be paired, this can avoid the
> NULL-deref while the guest reads the fw_cfg port.
>
> Signed-off-by: Li Qiang <liq3ea@gmail.com>

Do you have a reproducer and/or a backtrace?
memory_region_dispatch_write() checks if ops->write != NULL.

> ---
>  hw/nvram/fw_cfg.c | 6 ++++++
>  1 file changed, 6 insertions(+)
>
> diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
> index d79a568f54..6de7809f1a 100644
> --- a/hw/nvram/fw_cfg.c
> +++ b/hw/nvram/fw_cfg.c
> @@ -434,6 +434,11 @@ static bool fw_cfg_data_mem_valid(void *opaque, hwaddr addr,
>      return addr == 0;
>  }
>
> +static uint64_t fw_cfg_ctl_mem_read(void *opaque, hwaddr addr, unsigned size)
> +{
> +    return 0;
> +}
> +
>  static void fw_cfg_ctl_mem_write(void *opaque, hwaddr addr,
>                                   uint64_t value, unsigned size)
>  {
> @@ -468,6 +473,7 @@ static bool fw_cfg_comb_valid(void *opaque, hwaddr addr,
>  }
>
>  static const MemoryRegionOps fw_cfg_ctl_mem_ops = {
> +    .read = fw_cfg_ctl_mem_read,
>      .write = fw_cfg_ctl_mem_write,
>      .endianness = DEVICE_BIG_ENDIAN,
>      .valid.accepts = fw_cfg_ctl_mem_valid,
> --
> 2.11.0
>
>


-- 
Marc-André Lureau

Hi,

Marc-André Lureau <marcandre.lureau@gmail.com> 于2018年9月12日周三 下午3:16写道：

> Hi
>
> On Wed, Sep 12, 2018 at 9:22 AM Li Qiang <liq3ea@gmail.com> wrote:
> >
> > The write/read should be paired, this can avoid the
> > NULL-deref while the guest reads the fw_cfg port.
> >
> > Signed-off-by: Li Qiang <liq3ea@gmail.com>
>
> Do you have a reproducer and/or a backtrace?
> memory_region_dispatch_write() checks if ops->write != NULL.
>

As far as I can see, the fw_cfg_mem is not used in x86 and used in arm.
And from my impression, this will NULL read will be a issue. So I just
omit the 'read' field in fw_cfg_comb_mem_ops(this is used for x86) to
emulate the
issue.

When using gdb, I got the following backtrack.

Thread 5 "qemu-system-x86" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffca15b700 (LWP 7637)]
0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x0000555555872492 in memory_region_oldmmio_read_accessor
(mr=0x5555567fa870, addr=1, value=0x7fffca158510, size=1, shift=0,
mask=255, attrs=...) at /home/liqiang02/qemu-devel/qemu/memory.c:409
#2  0x000055555586f2dd in access_with_adjusted_size (addr=addr@entry=1,
value=value@entry=0x7fffca158510, size=size@entry=1,
access_size_min=<optimized out>, access_size_max=<optimized out>,
    access_fn=0x555555872440 <memory_region_oldmmio_read_accessor>,
mr=0x5555567fa870, attrs=...) at
/home/liqiang02/qemu-devel/qemu/memory.c:593
#3  0x0000555555873e90 in memory_region_dispatch_read1 (attrs=..., size=1,
pval=0x7fffca158510, addr=1, mr=0x5555567fa870) at
/home/liqiang02/qemu-devel/qemu/memory.c:1404
#4  memory_region_dispatch_read (mr=mr@entry=0x5555567fa870, addr=1,
pval=pval@entry=0x7fffca158510, size=1, attrs=attrs@entry=...) at
/home/liqiang02/qemu-devel/qemu/memory.c:1423
#5  0x0000555555821e42 in flatview_read_continue (fv=fv@entry=0x7fffbc03f370,
addr=addr@entry=1297, attrs=..., buf=<optimized out>, buf@entry=0x7ffff7fee000
"", len=len@entry=1, addr1=<optimized out>, l=<optimized out>,
mr=0x5555567fa870)
    at /home/liqiang02/qemu-devel/qemu/exec.c:3293
#6  0x0000555555822006 in flatview_read (fv=0x7fffbc03f370, addr=1297,
attrs=..., buf=0x7ffff7fee000 "", len=1) at
/home/liqiang02/qemu-devel/qemu/exec.c:3331
#7  0x000055555582211f in address_space_read_full (as=<optimized out>,
addr=addr@entry=1297, attrs=..., buf=buf@entry=0x7ffff7fee000 "",
len=len@entry=1) at /home/liqiang02/qemu-devel/qemu/exec.c:3344
#8  0x000055555582225a in address_space_rw (as=<optimized out>,
addr=addr@entry=1297, attrs=..., attrs@entry=..., buf=buf@entry=0x7ffff7fee000
"", len=len@entry=1, is_write=is_write@entry=false)
    at /home/liqiang02/qemu-devel/qemu/exec.c:3374
#9  0x0000555555886239 in kvm_handle_io (count=1, size=1,
direction=<optimized out>, data=<optimized out>, attrs=..., port=1297) at
/home/liqiang02/qemu-devel/qemu/accel/kvm/kvm-all.c:1731
#10 kvm_cpu_exec (cpu=cpu@entry=0x5555566e9990) at
/home/liqiang02/qemu-devel/qemu/accel/kvm/kvm-all.c:1971
#11 0x000055555585d3de in qemu_kvm_cpu_thread_fn (arg=0x5555566e9990) at
/home/liqiang02/qemu-devel/qemu/cpus.c:1257
#12 0x00007fffdbd58494 in start_thread () from
/lib/x86_64-linux-gnu/libpthread.so.0
#13 0x00007fffdba9aacf in clone () from /lib/x86_64-linux-gnu/libc.so.6

So I send out this path.

But this time when I not use gdb, there is no segmentation.

So this may not a issue.

If who has a arm environment, he can try this, the PoC is just easy. just
read the 0x510 port with word.

Thanks,
Li Qiang


>
> > ---
> >  hw/nvram/fw_cfg.c | 6 ++++++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
> > index d79a568f54..6de7809f1a 100644
> > --- a/hw/nvram/fw_cfg.c
> > +++ b/hw/nvram/fw_cfg.c
> > @@ -434,6 +434,11 @@ static bool fw_cfg_data_mem_valid(void *opaque,
> hwaddr addr,
> >      return addr == 0;
> >  }
> >
> > +static uint64_t fw_cfg_ctl_mem_read(void *opaque, hwaddr addr, unsigned
> size)
> > +{
> > +    return 0;
> > +}
> > +
> >  static void fw_cfg_ctl_mem_write(void *opaque, hwaddr addr,
> >                                   uint64_t value, unsigned size)
> >  {
> > @@ -468,6 +473,7 @@ static bool fw_cfg_comb_valid(void *opaque, hwaddr
> addr,
> >  }
> >
> >  static const MemoryRegionOps fw_cfg_ctl_mem_ops = {
> > +    .read = fw_cfg_ctl_mem_read,
> >      .write = fw_cfg_ctl_mem_write,
> >      .endianness = DEVICE_BIG_ENDIAN,
> >      .valid.accepts = fw_cfg_ctl_mem_valid,
> > --
> > 2.11.0
> >
> >
>
>
> --
> Marc-André Lureau
>

On 09/12/18 10:02, Li Qiang wrote:
> Hi,
> 
> Marc-André Lureau <marcandre.lureau@gmail.com> 于2018年9月12日周三 下午3:16写道：
> 
>> Hi
>>
>> On Wed, Sep 12, 2018 at 9:22 AM Li Qiang <liq3ea@gmail.com> wrote:
>>>
>>> The write/read should be paired, this can avoid the
>>> NULL-deref while the guest reads the fw_cfg port.
>>>
>>> Signed-off-by: Li Qiang <liq3ea@gmail.com>
>>
>> Do you have a reproducer and/or a backtrace?
>> memory_region_dispatch_write() checks if ops->write != NULL.
>>
> 
> As far as I can see, the fw_cfg_mem is not used in x86 and used in arm.
> And from my impression, this will NULL read will be a issue. So I just
> omit the 'read' field in fw_cfg_comb_mem_ops(this is used for x86) to
> emulate the
> issue.
> 
> When using gdb, I got the following backtrack.
> 
> Thread 5 "qemu-system-x86" received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7fffca15b700 (LWP 7637)]
> 0x0000000000000000 in ?? ()
> (gdb) bt
> #0  0x0000000000000000 in ?? ()
> #1  0x0000555555872492 in memory_region_oldmmio_read_accessor
> (mr=0x5555567fa870, addr=1, value=0x7fffca158510, size=1, shift=0,
> mask=255, attrs=...) at /home/liqiang02/qemu-devel/qemu/memory.c:409
> #2  0x000055555586f2dd in access_with_adjusted_size (addr=addr@entry=1,
> value=value@entry=0x7fffca158510, size=size@entry=1,
> access_size_min=<optimized out>, access_size_max=<optimized out>,
>     access_fn=0x555555872440 <memory_region_oldmmio_read_accessor>,
> mr=0x5555567fa870, attrs=...) at
> /home/liqiang02/qemu-devel/qemu/memory.c:593
> #3  0x0000555555873e90 in memory_region_dispatch_read1 (attrs=..., size=1,
> pval=0x7fffca158510, addr=1, mr=0x5555567fa870) at
> /home/liqiang02/qemu-devel/qemu/memory.c:1404
> #4  memory_region_dispatch_read (mr=mr@entry=0x5555567fa870, addr=1,
> pval=pval@entry=0x7fffca158510, size=1, attrs=attrs@entry=...) at
> /home/liqiang02/qemu-devel/qemu/memory.c:1423
> #5  0x0000555555821e42 in flatview_read_continue (fv=fv@entry=0x7fffbc03f370,
> addr=addr@entry=1297, attrs=..., buf=<optimized out>, buf@entry=0x7ffff7fee000
> "", len=len@entry=1, addr1=<optimized out>, l=<optimized out>,
> mr=0x5555567fa870)
>     at /home/liqiang02/qemu-devel/qemu/exec.c:3293
> #6  0x0000555555822006 in flatview_read (fv=0x7fffbc03f370, addr=1297,
> attrs=..., buf=0x7ffff7fee000 "", len=1) at
> /home/liqiang02/qemu-devel/qemu/exec.c:3331
> #7  0x000055555582211f in address_space_read_full (as=<optimized out>,
> addr=addr@entry=1297, attrs=..., buf=buf@entry=0x7ffff7fee000 "",
> len=len@entry=1) at /home/liqiang02/qemu-devel/qemu/exec.c:3344
> #8  0x000055555582225a in address_space_rw (as=<optimized out>,
> addr=addr@entry=1297, attrs=..., attrs@entry=..., buf=buf@entry=0x7ffff7fee000
> "", len=len@entry=1, is_write=is_write@entry=false)
>     at /home/liqiang02/qemu-devel/qemu/exec.c:3374
> #9  0x0000555555886239 in kvm_handle_io (count=1, size=1,
> direction=<optimized out>, data=<optimized out>, attrs=..., port=1297) at
> /home/liqiang02/qemu-devel/qemu/accel/kvm/kvm-all.c:1731
> #10 kvm_cpu_exec (cpu=cpu@entry=0x5555566e9990) at
> /home/liqiang02/qemu-devel/qemu/accel/kvm/kvm-all.c:1971
> #11 0x000055555585d3de in qemu_kvm_cpu_thread_fn (arg=0x5555566e9990) at
> /home/liqiang02/qemu-devel/qemu/cpus.c:1257
> #12 0x00007fffdbd58494 in start_thread () from
> /lib/x86_64-linux-gnu/libpthread.so.0
> #13 0x00007fffdba9aacf in clone () from /lib/x86_64-linux-gnu/libc.so.6
> 
> So I send out this path.
> 
> But this time when I not use gdb, there is no segmentation.
> 
> So this may not a issue.
> 
> If who has a arm environment, he can try this, the PoC is just easy. just
> read the 0x510 port with word.

I don't understand your description of how you managed to trigger this
SIGSEGV.

FWIW, looking at the codebase, there's a good number of static
MemoryRegionOps structures for which the "read_with_attrs" and "read"
members are default-initialized to NULL. It seems unlikely they are all
wrong.

- exec.c:                    notdirty_mem_ops, readonly_mem_ops
- hw/misc/debugexit.c:       debug_exit_ops
- hw/misc/hyperv_testdev.c:  synic_test_sint_ops
- hw/misc/pc-testdev.c:      test_irq_ops, test_flush_ops
- hw/pci-host/designware.c:  designware_pci_host_msi_ops
- hw/rdma/vmw/pvrdma_main.c: uar_ops
- hw/sparc64/sun4u.c:        power_mem_ops

Laszlo

Hi Laszlo,

Laszlo Ersek <lersek@redhat.com> 于2018年9月12日周三 下午6:36写道：

> On 09/12/18 10:02, Li Qiang wrote:
> > Hi,
> >
> > Marc-André Lureau <marcandre.lureau@gmail.com> 于2018年9月12日周三 下午3:16写道：
> >
> >> Hi
> >>
> >> On Wed, Sep 12, 2018 at 9:22 AM Li Qiang <liq3ea@gmail.com> wrote:
> >>>
> >>> The write/read should be paired, this can avoid the
> >>> NULL-deref while the guest reads the fw_cfg port.
> >>>
> >>> Signed-off-by: Li Qiang <liq3ea@gmail.com>
> >>
> >> Do you have a reproducer and/or a backtrace?
> >> memory_region_dispatch_write() checks if ops->write != NULL.
> >>
> >
> > As far as I can see, the fw_cfg_mem is not used in x86 and used in arm.
> > And from my impression, this will NULL read will be a issue. So I just
> > omit the 'read' field in fw_cfg_comb_mem_ops(this is used for x86) to
> > emulate the
> > issue.
> >
> > When using gdb, I got the following backtrack.
> >
> > Thread 5 "qemu-system-x86" received signal SIGSEGV, Segmentation fault.
> > [Switching to Thread 0x7fffca15b700 (LWP 7637)]
> > 0x0000000000000000 in ?? ()
> > (gdb) bt
> > #0  0x0000000000000000 in ?? ()
> > #1  0x0000555555872492 in memory_region_oldmmio_read_accessor
> > (mr=0x5555567fa870, addr=1, value=0x7fffca158510, size=1, shift=0,
> > mask=255, attrs=...) at /home/liqiang02/qemu-devel/qemu/memory.c:409
> > #2  0x000055555586f2dd in access_with_adjusted_size (addr=addr@entry=1,
> > value=value@entry=0x7fffca158510, size=size@entry=1,
> > access_size_min=<optimized out>, access_size_max=<optimized out>,
> >     access_fn=0x555555872440 <memory_region_oldmmio_read_accessor>,
> > mr=0x5555567fa870, attrs=...) at
> > /home/liqiang02/qemu-devel/qemu/memory.c:593
> > #3  0x0000555555873e90 in memory_region_dispatch_read1 (attrs=...,
> size=1,
> > pval=0x7fffca158510, addr=1, mr=0x5555567fa870) at
> > /home/liqiang02/qemu-devel/qemu/memory.c:1404
> > #4  memory_region_dispatch_read (mr=mr@entry=0x5555567fa870, addr=1,
> > pval=pval@entry=0x7fffca158510, size=1, attrs=attrs@entry=...) at
> > /home/liqiang02/qemu-devel/qemu/memory.c:1423
> > #5  0x0000555555821e42 in flatview_read_continue (fv=fv@entry
> =0x7fffbc03f370,
> > addr=addr@entry=1297, attrs=..., buf=<optimized out>, buf@entry
> =0x7ffff7fee000
> > "", len=len@entry=1, addr1=<optimized out>, l=<optimized out>,
> > mr=0x5555567fa870)
> >     at /home/liqiang02/qemu-devel/qemu/exec.c:3293
> > #6  0x0000555555822006 in flatview_read (fv=0x7fffbc03f370, addr=1297,
> > attrs=..., buf=0x7ffff7fee000 "", len=1) at
> > /home/liqiang02/qemu-devel/qemu/exec.c:3331
> > #7  0x000055555582211f in address_space_read_full (as=<optimized out>,
> > addr=addr@entry=1297, attrs=..., buf=buf@entry=0x7ffff7fee000 "",
> > len=len@entry=1) at /home/liqiang02/qemu-devel/qemu/exec.c:3344
> > #8  0x000055555582225a in address_space_rw (as=<optimized out>,
> > addr=addr@entry=1297, attrs=..., attrs@entry=..., buf=buf@entry
> =0x7ffff7fee000
> > "", len=len@entry=1, is_write=is_write@entry=false)
> >     at /home/liqiang02/qemu-devel/qemu/exec.c:3374
> > #9  0x0000555555886239 in kvm_handle_io (count=1, size=1,
> > direction=<optimized out>, data=<optimized out>, attrs=..., port=1297) at
> > /home/liqiang02/qemu-devel/qemu/accel/kvm/kvm-all.c:1731
> > #10 kvm_cpu_exec (cpu=cpu@entry=0x5555566e9990) at
> > /home/liqiang02/qemu-devel/qemu/accel/kvm/kvm-all.c:1971
> > #11 0x000055555585d3de in qemu_kvm_cpu_thread_fn (arg=0x5555566e9990) at
> > /home/liqiang02/qemu-devel/qemu/cpus.c:1257
> > #12 0x00007fffdbd58494 in start_thread () from
> > /lib/x86_64-linux-gnu/libpthread.so.0
> > #13 0x00007fffdba9aacf in clone () from /lib/x86_64-linux-gnu/libc.so.6
> >
> > So I send out this path.
> >
> > But this time when I not use gdb, there is no segmentation.
> >
> > So this may not a issue.
> >
> > If who has a arm environment, he can try this, the PoC is just easy. just
> > read the 0x510 port with word.
>
> I don't understand your description of how you managed to trigger this
> SIGSEGV.
>
> FWIW, looking at the codebase, there's a good number of static
> MemoryRegionOps structures for which the "read_with_attrs" and "read"
> members are default-initialized to NULL. It seems unlikely they are all
> wrong.
>
>
I uses the debugexit.

QEMU command: gdb --args qemu-system-x86_64  -m 2048 -hda
/home/liqiang02/ubuntu1801.img -enable-kvm  -vnc :100 -device isa-debug-exit

guest: inw(0x501)

We can get the following backtrack.

Starting program: /usr/local/bin/qemu-system-x86_64 -m 2048 -hda
/home/liqiang02/ubuntu1801.img -enable-kvm -vnc :100 -device isa-debug-exit
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffcde12700 (LWP 52824)]
[New Thread 0x7fffcd41f700 (LWP 52825)]
WARNING: Image format was not specified for
'/home/liqiang02/ubuntu1801.img' and probing guessed raw.
         Automatically detecting the format is dangerous for raw images,
write operations on block 0 will be restricted.
         Specify the 'raw' format explicitly to remove the restrictions.
[New Thread 0x7fffcca3c700 (LWP 52826)]
[New Thread 0x7fff463ff700 (LWP 52828)]
[Thread 0x7fffcd41f700 (LWP 52825) exited]
[New Thread 0x7fffcd41f700 (LWP 52857)]
[Thread 0x7fffcd41f700 (LWP 52857) exited]
[New Thread 0x7fffcd41f700 (LWP 52935)]

Thread 4 "qemu-system-x86" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffcca3c700 (LWP 52826)]
0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x00005555557c1f81 in memory_region_oldmmio_read_accessor
(mr=0x5555577b32b0, addr=0, value=0x7fffcca39568, size=2, shift=0,
mask=65535, attrs=...) at /home/liqiang02/qemu_max_cpu/qemu-2.8/memory.c:409
#2  0x00005555557c2697 in access_with_adjusted_size (addr=0,
value=0x7fffcca39568, size=2, access_size_min=1, access_size_max=4,
access=0x5555557c1f31 <memory_region_oldmmio_read_accessor>,
mr=0x5555577b32b0, attrs=...)
    at /home/liqiang02/qemu_max_cpu/qemu-2.8/memory.c:592
#3  0x00005555557c4aa2 in memory_region_dispatch_read1 (mr=0x5555577b32b0,
addr=0, pval=0x7fffcca39568, size=2, attrs=...) at
/home/liqiang02/qemu_max_cpu/qemu-2.8/memory.c:1254
#4  0x00005555557c4b26 in memory_region_dispatch_read (mr=0x5555577b32b0,
addr=0, pval=0x7fffcca39568, size=2, attrs=...) at
/home/liqiang02/qemu_max_cpu/qemu-2.8/memory.c:1273
#5  0x00005555557708ba in address_space_read_continue (as=0x5555562cc760
<address_space_io>, addr=1281, attrs=..., buf=0x7ffff7fee000 "", len=2,
addr1=0, l=2, mr=0x5555577b32b0) at
/home/liqiang02/qemu_max_cpu/qemu-2.8/exec.c:2692
#6  0x0000555555770a53 in address_space_read_full (as=0x5555562cc760
<address_space_io>, addr=1281, attrs=..., buf=0x7ffff7fee000 "", len=2) at
/home/liqiang02/qemu_max_cpu/qemu-2.8/exec.c:2743
#7  0x0000555555770b15 in address_space_read (len=2, buf=0x7ffff7fee000 "",
attrs=..., addr=1281, as=0x5555562cc760 <address_space_io>) at
/home/liqiang02/qemu_max_cpu/qemu-2.8/include/exec/memory.h:1527
#8  address_space_rw (as=0x5555562cc760 <address_space_io>, addr=1281,
attrs=..., buf=0x7ffff7fee000 "", len=2, is_write=false) at
/home/liqiang02/qemu_max_cpu/qemu-2.8/exec.c:2757
#9  0x00005555557bea59 in kvm_handle_io (port=1281, attrs=...,
data=0x7ffff7fee000, direction=0, size=2, count=1) at
/home/liqiang02/qemu_max_cpu/qemu-2.8/kvm-all.c:1800
#10 0x00005555557bef5f in kvm_cpu_exec (cpu=0x5555568279c0) at
/home/liqiang02/qemu_max_cpu/qemu-2.8/kvm-all.c:1958
#11 0x00005555557a5d5f in qemu_kvm_cpu_thread_fn (arg=0x5555568279c0) at
/home/liqiang02/qemu_max_cpu/qemu-2.8/cpus.c:998
#12 0x00007fffdbf89494 in start_thread () from
/lib/x86_64-linux-gnu/libpthread.so.0
#13 0x00007fffdbccbacf in clone () from /lib/x86_64-linux-gnu/libc.so.6
(gdb)

Seems the root cause is in 'memory_region_oldmmio_read_accessor '.
Anyway I have sent out another patch to address issue.

Thanks,
Li Qiang



> - exec.c:                    notdirty_mem_ops, readonly_mem_ops
> - hw/misc/debugexit.c:       debug_exit_ops
> - hw/misc/hyperv_testdev.c:  synic_test_sint_ops
> - hw/misc/pc-testdev.c:      test_irq_ops, test_flush_ops
> - hw/pci-host/designware.c:  designware_pci_host_msi_ops
> - hw/rdma/vmw/pvrdma_main.c: uar_ops
> - hw/sparc64/sun4u.c:        power_mem_ops
>
> Laszlo
>

On 9/12/18 7:33 AM, Li Qiang wrote:
>>>>
>>>> Do you have a reproducer and/or a backtrace?
>>>> memory_region_dispatch_write() checks if ops->write != NULL.
>>>>

>> FWIW, looking at the codebase, there's a good number of static
>> MemoryRegionOps structures for which the "read_with_attrs" and "read"
>> members are default-initialized to NULL. It seems unlikely they are all
>> wrong.
>>
>>
> I uses the debugexit.
> 
> QEMU command: gdb --args qemu-system-x86_64  -m 2048 -hda
> /home/liqiang02/ubuntu1801.img -enable-kvm  -vnc :100 -device isa-debug-exit
> 
> guest: inw(0x501)
> 
> We can get the following backtrack.
> 
> Starting program: /usr/local/bin/qemu-system-x86_64 -m 2048 -hda
> /home/liqiang02/ubuntu1801.img -enable-kvm -vnc :100 -device isa-debug-exit

> Thread 4 "qemu-system-x86" received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7fffcca3c700 (LWP 52826)]
> 0x0000000000000000 in ?? ()
> (gdb) bt
> #0  0x0000000000000000 in ?? ()
> #1  0x00005555557c1f81 in memory_region_oldmmio_read_accessor
> (mr=0x5555577b32b0, addr=0, value=0x7fffcca39568, size=2, shift=0,
> mask=65535, attrs=...) at /home/liqiang02/qemu_max_cpu/qemu-2.8/memory.c:409

Doesn't that mean we should fix memory_region_oldmmio_read_accessor() to 
deal with a NULL callback, rather than hacking up a large number of 
devices to supply a no-op callback?

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org