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.