01:52 DemiMarie: Does playing restricted content require Wayland compositor integration?
02:13 Company: something has to happen when I press PrntScrn
02:46 zamundaaa[m]: Demi: yes, mostly
02:47 zamundaaa[m]: There's some embedded platforms where video playback is routed weirdly and is put in an underlay by the display hw
02:47 zamundaaa[m]: For those, the compositor "just" needs to punch a hole into the other planes, to make the video visible
02:48 DemiMarie: zamundaaa: Thank you! That doesn't apply to me, so indeed it is required.
02:50 DemiMarie: The reason I ask is that if playing restricted content won't work anyway, I'd rather just fail any attempt to use it.
02:52 DemiMarie: There is no legitimate reason to use the functionality, so I want to block it (at the native context level) to reduce attack surface.
02:53 DemiMarie: zamundaaa: What happens if someone tries to play back restricted content without the compositor knowing? Do they just get garbage displayed on screen?
02:53 zamundaaa[m]: Depends on how it's implemented in the hardware
02:55 zamundaaa[m]: Afaik the common thing is that you just get black though
02:56 zamundaaa[m]: But I don't have much experience on the topic, so that might be wrong
02:59 Company: Vulkan kills your device if you try to read restricted data, no?
03:01 DemiMarie: Company: in that case dmabuf import of a restricted buffer had better fail.
03:02 DemiMarie: In this case the compositor has no idea the buffer is restricted.
03:04 Company: reading the spec, it's an invalid usage and the behavior in those cases is undefined
03:05 Company: which usually means SEGV or other fun signals
03:06 Company: in Vulkan you MUST always use the right protection flags for all accesses to protected data
03:06 Company: the only thing I didn't check is if import is allowed to fail
03:06 Company: but grep the vulkan spec for *_PROTECTED_BIT, it's named the same everywhere
03:07 DemiMarie: Company: how does one deal with imported buffers? I thought Wayland clients were not allowed to crash the compositor, and if they cab it's a security vulnerability.
03:07 Company: compositors make sure that the dmabuf is valid before importing it I would assume
03:08 Company: but no idea how they do that, I just write the clients
03:13 zamundaaa[m]: Judging by some old MRs on Mesa I just found, you actually get garbage out if you read from a restricted buffer without a matching context
03:14 zamundaaa[m]: And import does not fail in that case
03:14 zamundaaa[m]: That's for AMD and Intel, might not be generic
03:14 DemiMarie: zamundaaa: garbage out is acceptable from a security perspective.
03:15 DemiMarie: What matters is that it doesn't cause undefined behavior in the compositor.
03:16 DemiMarie: I think the spec is written that way because accessing restricted buffers without a proper context has no legitimate uses.
03:26 Company: usually, if the spec isn't clear on something, it's because the vendors disagreed on something
03:26 mareko: garbage out is the hw behavior, you get the same data that shaders get
03:27 mareko: or maybe random data
08:32 jani: daniels: sima: I could use some help with the gitlab pipeline here https://gitlab.freedesktop.org/drm/maintainer-tools/-/merge_requests/64
08:33 daniels: done
08:35 jani: daniels: many thanks, I got a follow-up which I asked there, and this discussion split to IRC and gitlab is getting silly :)
08:51 jani: daniels: works now, thanks again for saving me a bunch of time head scratching!
09:11 jfalempe: sima, tzimmermann: can one of you take a look at https://patchwork.freedesktop.org/series/136377/ please ?
09:12 sima: jfalempe, will do
09:14 jfalempe: Also I wanted to have drm_log works with fbcon, so that drm_log will display the boot logs, and when userspace is started, fbcon will take over, but currently the fbdev emulation takes the screen unconditionnaly just after driver registration.
09:14 jfalempe: sima: thx
09:15 tzimmermann: jfalempe, done
09:16 jfalempe: tzimmermann: thx too!
09:16 tzimmermann: jfalempe, that's a hard problem
09:16 tzimmermann: after the driver registered, it's there for use
09:17 tzimmermann: that is also the earliest time you could reliably use drm_log
09:18 tzimmermann: you'd need the login prompt to tell the driver that there's now an input prompt waiting and thereby make it switch to the console infrastructure
09:18 tzimmermann: maybe console binding could solve that issue
09:19 jfalempe: yes that was my idea, to wait for the prompt before doing the probe in drm_client.
09:19 tzimmermann: but that's unrelated to drm
09:19 tzimmermann: rather install both clients (fbdev, log) and switch between them
09:21 jfalempe: how do you switch ? currently drm_log is registered first, so when fbdev emulation is initialized, it steal the display, and drm_log writes to its framebuffer, but it won't make it to the screen.
09:21 tzimmermann: jfalempe, there's drm_client_dev_restore() that picks a drm client
09:22 tzimmermann: upon restoring the kernel DRM client
09:22 tzimmermann: (if there's no userspace compositor)
09:22 tzimmermann: it's first-come-first-served
09:22 jfalempe: tzimmermann: thx I will look into that.
09:23 tzimmermann: it could select a client by some sort of priority
09:23 tzimmermann: but that might not be such a great idea after all
09:23 tzimmermann: the kernel fbcon really is special
09:23 tzimmermann: IMHO
09:24 jfalempe: yes, if it's too complex, I will just make drm_log not build if fbcon is enabled.
09:25 tzimmermann: personally, i'd not want to swap outputs after text-mode booting
09:25 sima: might need a few layers I guess
09:25 jfalempe: but that means you'll need userspace console, and a few other things, to really use drm_log.
09:25 sima: like give drm_log priority, but if there's fbdev chardev open, then give drm_fbdev priority
09:26 tzimmermann: jfalempe, exactly
09:26 sima: for fbcon we'd probably need to wire the "is userspace using this" all the way through vt->console->fbcon->fbdev->drm which is ... ugh
09:26 tzimmermann: but using drm_log is not a means in itself
09:27 jfalempe: sima: yes too much layers to go through.
09:27 tzimmermann: it might be better to write a drm console and kill fbdev-emulation entirely
09:27 sima: would still need to go vt->console->drmcon
09:28 tzimmermann: sima, no i mean don't do drm_log; do drm_con instead
09:28 tzimmermann: same as fbcon, but without all the fbdev inbetween
09:28 sima: hm yeah might work better
09:28 sima: and if someone wants to keep fbdev chardev around, there we know when it's in use
09:28 jfalempe: tzimmermann: I think we shouldn't do the same mistake as fbcon, I will prefer having console and log separated
09:29 tzimmermann: jfalempe, i see this as a desing mistake
09:29 sima: but then, just put the drm con in userspace where it should be, if we create a new one
09:29 tzimmermann: console input and output belong together
09:29 tzimmermann: there's no separation between 'log' and 'user'
09:30 sima: there is? dmesg-console vs vt-console
09:30 tzimmermann: sima, yes it's possible to control the messages that go to the console
09:30 sima: it's just that vt-console also cosplays as a dmesg-console, which is where all the pain starts
09:30 tzimmermann: but that's different from having a console that does not print console messages at all
09:31 jfalempe: if you have a shell, you can always run dmesg if you want to see the kernel message.
09:31 sima: yeah, dmesg randomly destroying my vim/screen/whatever shell tool is annoying :-)
09:31 jfalempe: I don't see the point in having kernel message flooding your terminal
09:31 tzimmermann: jfalempe, but there's a reason why some dmesg messages end up on the vt-console
09:32 tzimmermann: and changing that is also a significant change policy
09:32 tzimmermann: jfalempe, some users want to know when sometihng bad happens
09:32 tzimmermann: and that policy is controlable
09:33 jfalempe: you can run "dmesg -w &" to do the same ?
09:33 tzimmermann: breaking that seems like a recipe for flamewars and disgruntled users
09:33 tzimmermann: it's not about can-or-cannot
09:33 jfalempe: yes this is what I want to avoid.
09:33 sima: then I guess userspace console should emulate that, if it's needed
09:33 tzimmermann: it's about 'the kernel automatically tells me when a major error happend'
09:34 sima: but if we end up with CONFIG_VT=y still, it's a bit silly imo
09:35 jfalempe: the end goal is having CONFIG_VT=n, and we should find a way to get there step by step, without hurting users.
09:35 tzimmermann: jfalempe, and any userspace console would have to emulate the current behavior
09:35 sima: yeah for CONFIG_VT=n I think it's drm_panic + drm_log for early boot + userspace console that is close enough to the current thing
09:36 tzimmermann: keeping the dmesg logs entirely off the console is not going to fly with many people
09:36 jfalempe: it would be nice to enable drm_log and keep fbcon, and then switch to userspace console. but that looks too complex.
09:37 jfalempe: tzimmermann: yes but that should be possible in userspace.
09:37 jfalempe: I don't think kmscon does that, but that shouldn't be hard to implement.
09:38 jfalempe: I think that makes much sense for headless servers, where you usally only have fbcon currently.
09:39 tzimmermann: wouldn't it be better to implement drm_log in userspace entirely?
09:40 tzimmermann: as feature in plymouth, or something like that?
09:40 sima: I thought the reasons for kernel was that userspace doesn't have something running early enough
09:40 tzimmermann: sima, right
09:40 sima: but yeah if plymouth can do it and it's enough ...
09:41 tzimmermann: sima, if an in-kernel client can use the drm driver, so could a client in userspace
09:42 tzimmermann: if the userspace cannot do that, is it only a problem in the system's setup
09:42 tzimmermann: ?
09:45 sima: yeah ... I think one issue was that simpledrm loads early, and plymouth only after the real drm driver because it fails to cope with the display driver change
09:46 jfalempe: plymouth can already display boot logs, but only after userspace is started. and it usually waits for the real driver to be loaded, so it's too late to debug early boot issues.
10:48 tzimmermann: that's a shortcoming in plymouth
10:48 tzimmermann: sima, that plymouth problem was related to fbdev emulation
10:49 tzimmermann: if plymouth opened /dev/fb, the firmware driver could not be unloaded
10:49 tzimmermann: but without unloading, plymouth would not close /dev/fb
10:50 tzimmermann: so the system stopped booting
10:50 tzimmermann: hence, plymouth started late
10:50 tzimmermann: to avoid that
10:52 sima: tzimmermann, hm I thought we've fixed those lifetime issues?
10:52 sima: at least I thought an open fbdev chardev shouldn't keep the driver/fbdev alive or stuck
10:53 tzimmermann: AFAIK, fbdev support has been disabled within plymouth
10:53 tzimmermann: sima, could be. that fbdev bug was from before simpledrm, when efifb was widely in use
10:54 tzimmermann: and with efifb, it would likely still happen today
10:55 sima: I thought you've done patches to fix up the fbdev removal?
10:56 tzimmermann: sima, i did what i could
10:57 tzimmermann: but fbdev hardware cannot be unplugged easily because of direct framebuffer-mmap that every userspace expects
10:59 tzimmermann: i'd not expect fbdev userspace to be able to deal with the SIGBUS that comes from writing to an unplugged framebuffer
11:02 sima: oh same on drm, we replace it with a dummy mapping of one page
11:08 tzimmermann: ah, so that would now work
11:08 tzimmermann: or we only do that on drm?
11:08 tzimmermann: but not fbdev?
11:22 sima: tzimmermann, well not even for drm, I think only amd or maybe ttm has this implemented
11:22 sima: but that was the idea at least ...
11:23 tzimmermann: BOs in shmem and dma don't go away, so many drivers are not affected
11:24 tzimmermann: so this might really not be a problem in drm
11:24 tzimmermann: dunno about i915
13:48 glehmann: alyssa: what's the issue with zink in the ddx/ddy MR?
13:56 alyssa: glehmann: no issue, I just didn't finish the patch because there were Too Many Bitcasts
13:56 alyssa: similar for gallivm, I didn't finish that one because of AoS/SoA shenanigans
13:57 alyssa: (the patch for e.g. bifrost was nontrivial too but I wrote that driver so I knew what to do. I haven't done much with zink or gallivm)
14:22 tzimmermann: sima, jfalempe, about these in-kernel drm clients: right now each driver runs the fbdev client. i'd like to make that a generic call to instanciate a default in-kernel client. users could then select the active client in .config/cmdline. the client would be fbdev, drm_log, drm_con, whatever. this could also be controlled via sysfs, so a session manager in userspace could switch among clients. the suggested
14:22 tzimmermann: drm_log-to-fbdev handover could be implemented this way
14:24 sima: tzimmermann, if we end up with only fbdev or drm-log (and maybe not even that) we don't need that much fancy
14:24 sima: so I'm leaning towards figuring out how much we really need first
14:25 sima: instead of a lot of complexity
14:25 tzimmermann: it's not complex
14:25 sima: if every distro has their different mix, it's going to be a mess I fear
14:25 tzimmermann: right
14:25 sima: I more mean all the different clients and possibly interactions
14:25 sima: the cmdlin/sysfs/config selector isn't much
14:25 tzimmermann: but currently everything is fbcon
14:26 tzimmermann: i don't see much use for drm_log on typical linux distros TBH
14:26 tzimmermann: maybe in some embedded systems
14:27 tzimmermann: where a console is not wanted
14:27 sima: I think/hope that it's either fbcon or drm-panic+kmscon+plymouth
14:27 jfalempe: yes, if you don't have a keyboard connected, drm_log is enough.
14:27 sima: the latter would at most have a drm_client for fbdev chardev support, if anyone needs that
14:28 jfalempe: but for general distro, in the long run, I see drm_panic, drm_log + userspace console, as being far superior as fbcon.
14:28 tzimmermann: but fbdev chardev makes things complicated
14:28 sima: tzimmermann, just thinking ... does that even work still without config_vt?
14:28 tzimmermann: because how would you display it if kmscon is active
14:28 tzimmermann: sima, it should
14:29 sima: pretty sure everyone hardcodes the assumption there's a vt
14:29 tzimmermann: config_vt is only for fbcon
14:29 sima: with stuff like setting KD_GRAPHICS/TEXT
14:29 sima: tzimmermann, I mean the fbdev using userspace programms might freak out if there's no vt
14:29 tzimmermann: sima, ok. why do you think that?
14:30 sima: tzimmermann, fbdev chardev I think is doable, since we can switch from drm-log to fbdev client if someone opens it
14:30 sima: tzimmermann, well it was the case for compositors at least
14:31 sima: and if you run a fbdev program from the vt console, you have to set KD_GRAPHICS or fbcon will overwrite what's on screen
14:31 sima: so I'd expect at least some apps to blow up
14:31 tzimmermann: sima, i see
14:31 sima: maybe worth testing SDL, if that goes boom I think you can just drop fbdev chardev for config_vt=n
14:31 tzimmermann: but maybe let's refer these users to the old fbdev emulation
14:32 sima: old fbdev emulation?
14:32 tzimmermann: the current one with fbcon
14:32 sima: yeah if they just run with fbcon and config_vt=y then it's all the same
14:33 sima: but the underlying fbdev emulation would work without fbcon/vt
14:33 tzimmermann: i mean, if the system has the new drm_panic+kmscon setup, let's just drop fbdev
14:33 sima: yeah
14:33 tzimmermann: if someone wants fbdev, they shoul dnot run kmscon at all
14:33 sima: might be easier to emulate with fuse if someone really cares :-)
14:34 jfalempe: sima: I think the fbdev emulation can work without fbcon/vt, but it conflicts with drm_log currently.
14:35 tzimmermann: jfalempe, that's why i proposed to make it user-configurable
14:35 tzimmermann: right now, we'd have to adapt every single driver
14:35 tzimmermann: it would be nicer to hide everything behind a standard DRM call that inits whatever is the current default
14:37 sima: tzimmermann, I think we could just rename the current _fbdev_generic to _client or something like that
14:37 sima: since currently we only have one client
14:37 sima: sprinkling drm_log/con/whatever client init calls over all drivers is definitely not good
14:38 sima: drm-panic is different because it needs really special support, so that's unavoidable
14:38 tzimmermann: sima, we have a client for ttm, one for shmem, one for dma, plus several others for specific drivers
14:38 tzimmermann: maybe 10 overall
14:38 jfalempe: sima: my first RFC doesn't need anything from driver: https://patchwork.freedesktop.org/series/136789/
14:39 sima: tzimmermann, yeah but those are for buffer management differences and stuff like that
14:39 sima: hm ...
14:39 sima: so one issue with lots of in-kernel clients is that people are already annoyed about the preallocate fbdev buffer
14:39 sima: so more gets more annoying
14:39 tzimmermann: it's still distinct code with slight differences
14:39 tzimmermann: the good news is that they are finally all build on top of drm_client_dev
14:40 tzimmermann: since v6.9 or so
14:40 jfalempe: sima: I've also moved the client() probe to the first time we need to draw, so that when you boot with quiet, if no logs are written, the framebuffer is not allocated for drm_log.
14:41 tzimmermann: so we can now build an fbdev client that handles all of them; and only leave some details of buffer management to the drivers or memory managers
14:41 sima: jfalempe, uh ... I think we had funny cases where that means you can't allocate anymore because it's all gone
14:42 jfalempe: ah I see, if you need contiguous memory, and your system has too much fragmentation ?
14:43 jfalempe: in this case, just remove quiet from the command line ;)
14:43 sima: yeah, because fbcon is preallocated you can switch even when your compositor wasted everything else already
14:44 sima: but if it's not preallocated anymore, then switch to fbcon becomes unreliable
14:44 sima: which is about the only big upside of fbcon compared to kmscon
14:44 jfalempe: I don't think you want to switch to drm_log, it's only for boot log.
14:44 sima: yeah for drm_log it makes sense
14:44 sima: I think ..
14:48 jfalempe: tzimmermann: I've tested the new vga-bmc connector on a poweredge 640, and it works great. it also fix a regression introduced by "2bae076f3e352 drm/mgag200: Set .detect_ctx() and enable connector polling"
14:48 tzimmermann: jaflempe, thanks for testing
14:48 jfalempe: since this commit, BMC was showing "no video", and your series fixes it.
14:49 tzimmermann: jfalempe, glad to hear
14:49 tzimmermann: i hope this design now sticks
14:50 jfalempe: Yes, that's simpler and easier for userspace to handle. it's just as if we plugged another monitor for BMC.
14:50 tzimmermann: regular g200 is still on regular vga
14:50 jfalempe: I'm not sure there are still regular G200 users.
14:50 tzimmermann: jfalempe, i sometimes use it for testing :)
14:51 jfalempe: tzimmermann: oh :)
14:51 tzimmermann: and it's essential for free
14:52 tzimmermann: there's also a pcie variant of the g550. so it might be worth porting that support into the driver. the pcie card might be in use today
14:54 jfalempe: if there are users, maybe.
14:55 jfalempe: I will check aspeed BMC next, on Friday, (I will be ooo tomorrow).
14:55 tzimmermann: jfalempe, great! thanks a lot