On Thu, Oct 24, 2019 at 05:08:52AM -0400, Jagannathan Raman wrote:
> +static void remote_ram_destructor(MemoryRegion *mr)
> +{
> + qemu_ram_free(mr->ram_block);
> +}
> +
> +static void remote_ram_init_from_fd(MemoryRegion *mr, int fd, uint64_t size,
> + ram_addr_t offset, Error **errp)
> +{
> + char *name = g_strdup_printf("%d", fd);
> +
> + memory_region_init(mr, NULL, name, size);
> + mr->ram = true;
> + mr->terminates = true;
> + mr->destructor = NULL;
> + mr->align = 0;
> + mr->ram_block = qemu_ram_alloc_from_fd(size, mr, RAM_SHARED, fd, offset,
> + errp);
> + mr->dirty_log_mask = tcg_enabled() ? (1 << DIRTY_MEMORY_CODE) : 0;
> +
> + g_free(name);
> +}
This is not specific to remote/memory.c and could be shared in case
something else in QEMU wants to initialize from an fd.
> +
> +void remote_sysmem_reconfig(MPQemuMsg *msg, Error **errp)
> +{
> + sync_sysmem_msg_t *sysmem_info = &msg->data1.sync_sysmem;
A possible security issue with MPQemuMsg: was the message size
validatedb before we access msg->data1.sync_sysmem?
If not, then we might access uninitialized data. I didn't see if there
is a single place in the code that always zeroes msg, but I think the
answer is no. Accessing uninitialized data could expose the old
contents of the stack/heap to the other process. Information leaks like
this can be used to defeat address-space randomization because the other
process may learn about our memory layout if there are memory addresses
in the uninitialized data.
signature.asc
Description: PGP signature
