00:28DemiMarie: Is there a library that I can use to obtain information about every known DRM format?
00:30DemiMarie: For each format, I’d like to have enough information to validate dmabuf and shm requests
00:33bl4ckb0ne: what kind of infos
00:44DemiMarie: Ideally, I'd have high-level operations bool check_wl_shm_params(uint32_t format, uint32_t width, uint32_t height, uint32_t stride, uint32_t size); and similar for dmabuf.
00:46DemiMarie: actually this should probably be on #_oftc_#wayland:matrix.org
01:09DemiMarie: Is validating dmabuf width, height, and stride Mesa's job, the kernel's job, or a Wayland compositor's job?
06:18emersion: DemiMarie: there is https://pixfmtdb.emersion.fr
06:19emersion: it's still missing some formats
06:19emersion: and I wanted to make a library out of it
06:20DemiMarie: emersion: what about the database in the kernel?
06:20DemiMarie: That said, a library based on your work would be amazing.
06:21emersion: i have an earlier prototype which extracts info from that kernel tablr
06:21emersion: table*
06:22emersion: but I abandoned it because it's missing info to do something other than validation (e.g. display these layouts and automatically compute compatible formats) and it's a pain to extract
06:23DemiMarie: If I am writing a proxy, do I need anything other than validation?
06:23DemiMarie: In particular, how should I handle dmabuf?
06:24DemiMarie: Can I validate it myself (preferred) or do I need to leave that to the host compositor?
06:25DemiMarie: My concern is modifiers.
06:25DemiMarie: For shm the validation is easy and I will likely make an MR to wlroots.
06:25emersion: right, modifiers are the main hurdle if you want to validate
06:25DemiMarie: Can it still be done?
06:26emersion: well, there is always a way
06:26DemiMarie: Practically :)
06:26emersion: but that would require investigating each modifier in kernel code
06:26DemiMarie: Yuck
06:26emersion: maybe some are missing validation
06:26emersion: maybe some are reverse engineered
06:27DemiMarie:wonders if the kernel code gets it all correct
06:27emersion: maybe some nobody knows more details
06:27emersion: I'm not sure how much validation matters
06:28DemiMarie: My concern is that the guest can lie about width, height, format, or stride.
06:28emersion: the GPU would read zeros on out of bounds access with robustness?
06:28DemiMarie: Will compositors turn that on?
06:28emersion: maybe accessing other buffers by chance is still possible though
06:29DemiMarie: That's my concern indeed.
06:29emersion: clients wouldn't be able to extract the data though
06:29DemiMarie: Still an issue in Qubes OS as it allows spoofing
06:29emersion: well if you don't turn it on it's GPU reset
06:30DemiMarie: Can I expect that all compositors will, in fact, use it?
06:31DemiMarie: If GPU buffer accesses are bounds-checked at runtime then import-time validation is far less important.
06:31emersion: I don't know of a compositor that enables it but I haven't checked in detail
06:32DemiMarie: I do know that the Vulkan specification prohibits any security vulnerabilities here.
06:32DemiMarie: If the compositor uses Vulkan.
06:33DemiMarie: Should I make a defensive copy into buffers I allocate?
06:35DemiMarie: I'm actually surprised that robustBufferAccess isn't turned on. Maybe I need to do some tests.
13:48jfalempe: tzimmermann: thanks for your drm_client setup series. That means I would able to call a drm_log_client_setup() from drm_client_setup() ? So we can choose on the kernel command line between fbdev emulation and drm_log ?
14:09tzimmermann: jfalempe, yes.
14:10tzimmermann: IMHO we should later provide kconfig options to enable each client, and an option of selecting a default
15:59DemiMarie: emersion: I wonder if the kernel should provide a generic validation ioctl.
16:00DemiMarie: What about requiring future additions to drm_fourcc.h to include enough information?
16:00DemiMarie:considers forcing a copy to LINEAR at each end
16:03Company: (nvidia doesn't support LINEAR afaik)
16:04karolherbst: nvidia supports rendering to linear, just not if there is a depth buffer attached
16:16DemiMarie: I was actually thinking of just using a copy command.
16:19DemiMarie: How likely are things to break if I only advertise LINEAR and then disconnect any client that tries to use something that is not LINEAR?
16:20zamundaaa[m]: karolherbst: only with Vulkan
16:20zamundaaa[m]: Rendering to linear with OpenGL does not work
16:22karolherbst: ohh, I see
16:22karolherbst: I was talking from a hardware perspective here
16:31DemiMarie: zamundaaa: can you copy to linear?
16:31zamundaaa[m]: No
16:31zamundaaa[m]: The driver may do it internally in EGL afaik
16:32zamundaaa[m]: But clients that import dmabufs to render to them can't do the same
16:32DemiMarie: Is this with Nvidia proprietary driver or the open drivers?
16:32zamundaaa[m]: Proprietary
16:32DemiMarie: What about Nouveau?
16:33karolherbst: I think nvk has a workaround for that
16:33DemiMarie: In Qubes OS proprietary drivers won’t be supported.
16:33karolherbst: but the gl driver will also not allow this to happen
16:33zamundaaa[m]: Afaik Mesa works around this
16:33karolherbst: somewhat yes
16:33karolherbst: but you can make it run into the issue if you try hard enough
16:34DemiMarie: The reason for the restriction is that I need to be able to validate all buffer imports.
16:34karolherbst: but as long as you don't have a linear depth buffer, nouveau should be fine to render to linear
16:35DemiMarie: I know how to validate linear, but not nonlinear modifiers.
16:36DemiMarie: Does Mesa validate imported buffers in any way?