Sync upstream changes#8
Open
github-actions[bot] wants to merge 22 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>
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
7 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