>>> On 09.08.18 at 11:50, <andrew.coop...@citrix.com> wrote:
> Firstly, there is no 'offset' boundary check on the non-32-bit write path
> before the call to vlapic_read_aligned(), which allows an attacker to read
> beyond the end of vlapic->regs->data[], which is only 1024 bytes long.
>
> However, as the backing memory is a domheap page, and misaligned accesses get
> chunked down to single bytes across page boundaries, I can't spot any
> XSA-worthy problems which occur from the overrun.
>
> On real hardware, bad accesses don't instantly crash the machine. Their
> behaviour is undefined, but the domain_crash() prohibits sensible testing.
> Behave more like other x86 MMIO and terminate bad accesses with appropriate
> defaults.
>
> While making these changes, clean up and simplify the the smaller-access
> handling. In particular, avoid pointer based mechansims for 1/2-byte reads so
> as to avoid forcing the value to be spilled to the stack.
>
> add/remove: 0/0 grow/shrink: 0/2 up/down: 0/-175 (-175)
> function old new delta
> vlapic_read 211 142 -69
> vlapic_write 304 198 -106
>
> Finally, there are a plethora of read/write functions in the vlapic namespace,
> so rename these to vlapic_mmio_{read,write}() to make their purpose more
> clear.
>
> Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com>
Reviewed-by: Jan Beulich <jbeul...@suse.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
