Sync upstream changes - #8
Open
github-actions[bot] wants to merge 42 commits into
Open
Conversation
Fixes the following error: `ERROR: Object <[DependencyHolder] holds [PkgConfigDependency]: <PkgConfigDependency vulkan: True []>> of type PkgConfigDependency does not support the `+` operator.` Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1620>
The same issue happened in Mesa https://gitlab.freedesktop.org/mesa/mesa/-/commit/4ae192a3d9f7861f40fc90ff4ebb4bf4112a9c80 part of https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40862 Signed-off-by: Sergi Blanch Torne <sergi.blanch.torne@collabora.com> Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1612>
v2: remove debug leftovers (tintou) Closes: https://gitlab.freedesktop.org/virgl/virglrenderer/-/work_items/656 Signed-off-by: Gert Wollny <gert.wollny@collabora.com> Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1622>
Since the check against the 32 used mask results in undefined behaviour the check does not protect against values that are larger than 31, the maxium allowed number of images and SSBOs. So check th eupper bound too. Closes: https://gitlab.freedesktop.org/virgl/virglrenderer/-/work_items/658 Signed-off-by: Gert Wollny <gert.wollny@collabora.com> Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1622>
Closes: https://gitlab.freedesktop.org/virgl/virglrenderer/-/work_items/657 Signed-off-by: Gert Wollny <gert.wollny@collabora.com> Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1622>
Motivation is for platforms such as iOS whose strict sanndbox does not allow for fork() or process spawning. New option "render-server-mode" enables 'thread' which will spawn the render server as a thread. The other option "render-server-worker" is still used to specify how the context communicates with the render server. When the rendering server is "thread" then the worker MUST ALSO be "thread". Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1626>
This change: - amend missing global optind reset for getopt_long - close client connection first to unblock server teardown - update config.h.meson for the new def - hide process-isolated server behind defs to suppress compiler warnings Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1626>
v2 (zzyiwei): drop render_log_init changes Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1626>
Callers of `virgl_logv` always use a '\n' at the end but callers of `virgl_prefixed_logv` does not. The default log handler will not print a new line so this makes the two logv implementations consistent. Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1626>
Closes: https://gitlab.freedesktop.org/virgl/virglrenderer/-/work_items/666 Signed-off-by: Gert Wollny <gert.wollny@collabora.com> Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1632>
Do not ignore pixel read failure. Signed-off-by: Corentin Noël <corentin.noel@collabora.com> Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1633>
In case of a ReadBuffer failure, this ensure that we won't return garbage memory to the client. Signed-off-by: Corentin Noël <corentin.noel@collabora.com> Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1633>
vkr_metal_get_device() exports the underlying MTLDevice via vkExportMetalObjectsEXT() with a VkExportMetalDeviceInfoEXT. Per VK_EXT_metal_objects, the export intent must be declared at instance creation, otherwise the export is a spec violation (VUID-VkExportMetalObjectsInfoEXT-pNext-06791), flagged by the validation layer (MoltenVK happens to tolerate it). Chain a VkExportMetalObjectCreateInfoEXT with exportObjectType VK_EXPORT_METAL_OBJECT_TYPE_METAL_DEVICE_BIT_EXT into the VkInstanceCreateInfo pNext on macOS. Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1635>
macOS shm_open() rejects O_CLOEXEC with EINVAL -- it only accepts O_RDONLY, O_RDWR, O_CREAT, O_EXCL and O_TRUNC. As a result os_create_anonymous_file() always failed on macOS and returned -1, breaking any caller that relies on it (e.g. the proxy render-server context shmem: proxy_context_init_shmem -> alloc_memfd), which surfaced as "failed to pre-initialize context" and RESOURCE_CREATE_BLOB failures. Drop O_CLOEXEC from the shm_open() flags and set close-on-exec explicitly with fcntl(F_SETFD, FD_CLOEXEC) after a successful open. Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1634>
Fixes: fe078e3 ("drm: Add DRM context helpers") Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1636>
The shared memory is guest-writeable, so the guest always has control over its contents. Trusting the guest to select the number of bytes to unmap is a bad idea. For instance, if contiguous bytes after the mapping happen to be mapped, they could be unmapped as well. A subsequent mmap() could then reuse the same address space before other code dereferences the memory, resulting in use after free. Found by Claude Opus 4.8. Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1637>
If a command handler fails while still leaving a response buffer set, drm_context_submit_cmd_dispatch() will leave the response buffer associated with the struct drm_context. If a subsequent call doesn't allocate a new response buffer, and succeeds, the response will be copied into the stale response buffer. However, the copy is made using _this_ command's hdr_off, without any new bounds check. This gives the guest a very powerful nonlinear out-of-bounds write primitive: it can a guest-controlled amount of data with guest-controlled contents at guest-controlled offset. This is almost certainly enough to get code execution. Fix this by freeing the response buffer before returning from drm_context_submit_cmd_dispatch(). A new response buffer will only be allocated after drm_context_rsp() has checked hdr->rsp_off to be in bounds. This is too subtle and subsequent bounds checks will be added later. Found by Claude Opus 4.8. Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1637>
Relying on drm_context_rsp() to validate rsp->hdr_off is too fragile. It's too easy to have a mismatch between the buffer length and the validated offset, as the previous commit showed. Repeat the bounds check before performing the copy. This has an assert(false) if it fails, as the bounds check should have been done earlier. Discovered by Claude Opus 4.8. Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1637>
… conditions match for imported resources" Fixes: 3716881 ("vrend: Ensure sampler view and framebuffer attachment swizzle conditions match for imported resources") Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1652>
The guest could cause an unbounded buffer allocation. Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1643>
Avoid NULL deref. Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1643>
The amdgpu renderer may not allocate all AMDGPU_HW_IP_NUM rings. If it allocates fewer, a too-large ring ID will access outside the bounds of the ctx->timelines array. This results in an information leak or, if the last_fence_fd field of the out of bounds drm_timeline struct is 0 or more, memory corruption. Found by Claude Opus 4.8. I looked at the fix it provided and wrote my own. Fixes: d27e04e ("drm: add amdgpu native-context implementation") Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1639>
If virgl_egl_image_from_bo fails, gbm_bo is set to NULL while storage_bits has VREND_STORAGE_GBM_BUFFER. When this resource is imported to venus, NULL is passed to gbm_bo_get_handle and host crashes. Signed-off-by: Toshinari Morikawa <morikawa.toshinari@jp.panasonic.com> Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1644>
An IO variable may technically fit into thenumber of available variable slots, array actually require more than one IO slot, so check the range against the maximum number of supported IO slots. Closes: https://gitlab.freedesktop.org/virgl/virglrenderer/-/work_items/659 Signed-off-by: Gert Wollny <gert.wollny@collabora.com> Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1623>
There was no check that the number of request IDs provided by the guest fit in the guest-provided request buffer. Add the missing check. Found by Claude Opus 4.8. I adapted its fix. Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1641>
If the guest tries to submit more than 128 IDs at once, fail the request. This avoids stack overflow, which is undefined behavior in C. Found by Claude Opus 4.8. I lightly modified the fix. Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1641>
Use after close is always wrong; the result could be an ioctl on a bad FD. Found and fixed by Claude Opus 4.8. Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1641>
The default value for boolean options should be a boolean, not a string. Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1653>
Ensures that non-DRM ioctls are not issued. I don't know if there are any that could cause a problem, but it is much better to be safe. Fixes: b481690 ("drm: Add msm native context implementation") Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1638>
If the payload for a DRM_MSM_SUBMITQUEUE_NEW ioctl was too small, reading args->id would be out of bounds. If the direction did not include IOC_OUT, args->id would be left uninitialized by the kernel. Validate the payload size and ioctl direction for every ioctl command. The size is checked to be large enough to prevent out-of-bounds accesses. The direction is checked to ensure that: 1. The kernel will read the payload, rather than ignoring it. 2. If the ioctl should write to its argument, the kernel will perform the write. Fixes: b481690 ("drm: Add msm native context implementation") Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1638>
It failed due to being called on the wrong fd. Found by Claude Opus 4.8. Fixes: beab181 ("drm/msm: Do not ignore lseek() failure") Fixes: e6bab14 ("drm/msm: Add error path gem_close()") Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1638>
Claude Opus 4.8 clains that this should have been checked by the kernel in DRM_IOCTL_MSM_SUBMITQUEUE_NEW before inserting the hash table entry, but this is too subtle and I don't trust it to be right. Add a bounds check before calling the ioctl and another bounds check at the point of use. Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1638>
The payload buffer is only 1-byte aligned, but the buffer provided by the generic dispatch code is 8-byte aligned. Originally, that buffer was read-only, but this is no longer the case. Therefore, use the original buffer so that it can safely be cast to a struct pointer. Fixes: b481690 ("drm: Add msm native context implementation") Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1638>
The same issue happened in Mesa https://gitlab.freedesktop.org/mesa/mesa/-/commit/dcfc90a8fc0d59309e8c37926b9a2c6334356271 part of https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41871 Signed-off-by: Sergi Blanch Torne <sergi.blanch.torne@collabora.com> Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1628>
Signed-off-by: Valentine Burley <valentine.burley@collabora.com> Part-of: <https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1628>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
10 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Automated sync from upstream repository