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