camus has quit [Remote host closed the connection]
camus has joined #dri-devel
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
kts has joined #dri-devel
ella-0 has joined #dri-devel
ella-0_ has quit [Read error: Connection reset by peer]
Danct12 has joined #dri-devel
khfeng has joined #dri-devel
macromorgan has joined #dri-devel
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
<mareko>
MrCooper: GLVND calls into libGL from Mesa (called libGL_mesa.so), and Mesa also has its own copy of libglapi, duplicating GLVND and adding a layer of GL call indirection.
camus has quit [Ping timeout: 480 seconds]
mhenning has joined #dri-devel
camus has joined #dri-devel
Daanct12 has joined #dri-devel
Danct12 has quit [Read error: Connection reset by peer]
saurabhg has joined #dri-devel
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
<mareko>
if we drop support for non-GLVND, we should be able to move glapi into libgallium_dri.so
<mareko>
and once that's done, we can optionally disable the dispatch by returning _mesa_marshal_* from GetProcAddress
<mareko>
*disable=bypass
<orbea>
excluding this performance hit are there any reasons to use non-glvnd over glvnd?
<orbea>
or rather what would the potential blockers be in removing the non-glvnd path?
<airlied>
I think windows doesn't use glvnd
<mareko>
airlied: so it'll be #ifdef'd
<airlied>
yeah you'd have to just figure it out from build time
<mareko>
the static vs shared glapi also complicates things, there is so much stuff...
<jenatali>
airlied: Windows doesn't use glvnd, but it also doesn't really support exporting the actual GL API out of a DLL
<jenatali>
OpenGL32.dll exports GL1.1 entrypoints, everything else needs to be manually retrieved
<jenatali>
mareko: If you move libglapi.so into libgallium_dri.so, doesn't that effectively make all configs into static glapi?
sdutt has quit []
Daanct12 has quit [Remote host closed the connection]
heat has quit [Ping timeout: 480 seconds]
nchery has joined #dri-devel
mhenning has quit [Quit: mhenning]
aravind has joined #dri-devel
<mareko>
yes, currently all drivers are inside libgallium_dri.so, so libglapi has only one user and doesn't have to be "shared" with anything IMO
Duke`` has joined #dri-devel
saurabhg has quit [Ping timeout: 480 seconds]
nchery has quit [Ping timeout: 480 seconds]
saurabhg has joined #dri-devel
itoral has joined #dri-devel
Dr_Who has quit [Read error: Connection reset by peer]
mbrost has joined #dri-devel
rpigott has quit [Read error: Connection reset by peer]
rpigott has joined #dri-devel
fab has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
dviola has joined #dri-devel
dakr has joined #dri-devel
danvet has joined #dri-devel
kts has joined #dri-devel
<mareko>
The dispatch may still be exported to libGL_mesa and libEGL_mesa, but it shouldn't have to be a separate library. It would also mean that non-GLVND support would be dropped.
mbrost has quit [Ping timeout: 480 seconds]
saurabhg has quit [Read error: Connection reset by peer]
fab has quit [Quit: fab]
khfeng has quit [Ping timeout: 480 seconds]
kts has quit [Remote host closed the connection]
kts has joined #dri-devel
frieder has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.5]
saurabhg has joined #dri-devel
lemonzest has joined #dri-devel
lygstate has joined #dri-devel
saurabhg has quit [Ping timeout: 480 seconds]
jkrzyszt has joined #dri-devel
saurabhg has joined #dri-devel
jfalempe has joined #dri-devel
<MrCooper>
mareko: there's no libGL_mesa.so, you probably mean libGLX_mesa.so? FWIW, the corresponding libEGL_mesa.so has no OpenGL API symbols AFAICT
nchery has joined #dri-devel
fab has joined #dri-devel
nchery is now known as Guest1481
nchery has joined #dri-devel
Guest1481 has quit [Ping timeout: 480 seconds]
lynxeye has joined #dri-devel
thellstrom has joined #dri-devel
apinheiro has joined #dri-devel
Haaninjo has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
kts has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
pcercuei has joined #dri-devel
thellstrom1 has joined #dri-devel
thellstrom has quit [Read error: Connection reset by peer]
saurabhg has quit [Ping timeout: 480 seconds]
saurabhg has joined #dri-devel
mvlad has joined #dri-devel
saurabh_1 has joined #dri-devel
epoll has quit [Ping timeout: 480 seconds]
saurabhg has quit [Ping timeout: 480 seconds]
thellstrom1 has quit []
thellstrom has joined #dri-devel
epoll has joined #dri-devel
srslypascal is now known as Guest1486
srslypascal has joined #dri-devel
gbelgurr has joined #dri-devel
gbelgurr has left #dri-devel [#dri-devel]
Guest1486 has quit [Ping timeout: 480 seconds]
gbelgurr has joined #dri-devel
Danct12 has joined #dri-devel
gbelgurr has quit []
fahien has joined #dri-devel
<Kayden>
mareko: dropping non-GLVND seems like a good plan to me, and yeah, I think now that classic is gone shared glapi probably isn't needed either. sounds like you've got a good plan to clean things up. saw the ticket where you'd mentioned glvnd cpu overhead, and...oooof. glad to hear we can get some of that back, and thanks for looking into that
guptasa2_ has joined #dri-devel
devilhorns has joined #dri-devel
saurabh_1 has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
gbelgurr has joined #dri-devel
kts has joined #dri-devel
Haaninjo has quit [Ping timeout: 480 seconds]
gbelgurr_ has joined #dri-devel
gbelgurr has quit []
MaxHeadroom has joined #dri-devel
Haaninjo has joined #dri-devel
FireBurn has quit [Quit: Konversation terminated!]
fahien has quit [Ping timeout: 480 seconds]
guptasa2_ has quit [Ping timeout: 480 seconds]
apinheiro has quit [Ping timeout: 480 seconds]
<Ristovski>
Kayden: is that (glvnd overhead) ticket in mesa? can't find it
<Ristovski>
i've been wondering if there is a perf difference, so far I have been building mesa without glvnd
devilhorns has quit [Remote host closed the connection]
devilhorns has joined #dri-devel
<gbelgurr>
Does this mean, going forward, we will only have GLVND capable of generating libGL.so, libGLX_mesa.so and libEGL_mesa.so for all the drivers?
gbelgurr has left #dri-devel [Leaving]
itoral has quit [Remote host closed the connection]
gbelgurr has joined #dri-devel
kts has joined #dri-devel
thellstrom has joined #dri-devel
<jenatali>
mareko: I've been thinking about removing shared glapi for Windows now that I split the drivers out of OpenGL32.dll to look like Linux's architecture. I couldn't find any more reason for it to exist there and was wondering about Linux
<jenatali>
So, yeah I'd be on-board and can help with making it happen for Windows
<jenatali>
Though I'm about to go on leave for a month and a half so probably not til I'm back from that
kts has quit [Ping timeout: 480 seconds]
fahien has joined #dri-devel
kts has joined #dri-devel
<kusma>
jenatali: Hmm... Do you know if the gs-variant code in the D3D12 driver still works? It seems to me like we're setting primitive types to the GLenum values, whereas they should be enum shader_prim values now...
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
<jenatali>
It should work, yeah
<jenatali>
At least, CI didn't regress which uses it
<kusma>
That seems strange, since enum shader_prim is zero-based, and the GLenum values are aboslutely not...
<kusma>
Oh, they are
<kusma>
the only GLenum that are :D
<kusma>
Seems all other drivers were corrected to use the shader_prim stuff...
<jenatali>
Ah awesome, someone just forgot about us
<kusma>
Ah, no. There's some leftovers in the Intel compiler also
Dr_Who has joined #dri-devel
<jenatali>
IIRC from looking at tessellation there's a difference between the two
<jenatali>
I had a bug for a while in tess where the wrong enum mostly worked but have me wrong results
<kusma>
Seems there's some copy-paste mistakes here also... great :)
abws has joined #dri-devel
zehortigoza has joined #dri-devel
thaytan has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
fxkamd has joined #dri-devel
abws has quit [Quit: abws]
devilhorns has quit [Remote host closed the connection]
Lucretia has quit [Remote host closed the connection]
Lucretia has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
leandrohrb11 is now known as leandrohrb
Jeremy_Rand_Talos_ has joined #dri-devel
<orbea>
"but I do think we want to be able to bump the compiler version once a year or something. IDK how distros and others will feel about that." fwiw this is going to make it impossible or harder for lot of stable distro users to build mesa (debian, centos forks, etc)
<orbea>
i still think the biggest elephant in the room that is not being addressed is the state of the current rust toolchain is a lot of pain for downstream.
thellstrom has quit [Quit: thellstrom]
<orbea>
"So we might actually decide to simply depend on the same rust version Firefox uses, because that's something distributions will have to deal with anyway." just because firefox does it does not mean its good
<kisak>
does built rust code have any runtime dependencies, or is it entirely build time?
<kisak>
sorry, that's unclear, does code built with rust need that rust compiler or newer to be available at runtime.
<orbea>
not entirely sure, but I have seen firefox work without rust installed
<ajax>
orbea: i have difficulty reconciling "i want a stable distro" with "i want to build yesterday's mesa"
<ajax>
in fact
<orbea>
ajax: "hi i have a mesa bug" "can you please try the latest version in case its already fixed?"
<kisak>
I'm not particulary thrilled with the regular backports of llvm that I need to do for radeonsi, and I'm not really interested in picking up maintenance on another compiler, but if it's an irregular build-time update, then that's an easier pill to swallow because I have those separated out into a PPA that shouldn't reach end users.
<ajax>
that sounds like a reason for us to have snapshot builds, tbh
<ajax>
kisak: they tend to be standalone, no runtime (or compiler) needed
<orbea>
ajax: they may still need to build it if they want to test patches given to them by the mesa developers
<ajax>
okay
<orbea>
this was a common occurence when I was using nouveau :P
<ajax>
also "once a year" ends up being roughly the same cadence as rhel's mesa rebase cadence i think
<ajax>
feel free to piggyback off our work...
<ajax>
i dunno. my opinion probably doesn't count so much here _because_ this is my job
<ajax>
but i tend to believe these kinds of teething problems get fixed precisely _by_ projects like mesa adopting them as infrastructure
<orbea>
maybe that is right, personally I' prefer the other way around, but idk that would ever happen
<ajax>
in much the same way that mesa gets fixed by apps and libraries assuming opengl works and is good
<orbea>
and my opinion also probably doesn't go for much here
<ajax>
but
<orbea>
im placing my bets on the gcc work making this less painful
<Frogging101>
You can reply to the mailing list post without having received the original message by clicking the sender's email address at the top, by the way
sdutt has joined #dri-devel
<MrCooper>
orbea: Debian proper doesn't update Mesa in stable releases, so wouldn't be affected (though Debian backports might be, but they already need to backport various dependencies anyway)
<orbea>
MrCooper: i was thinking about the individual users, not the distros
<Vanfanel>
I am an individual Debian user and I very ofter rebuild MESA. That's the good thing: I can have an stable operating system, and easily build libs on it, test things, report bugs using latest git code, and even do some small bugfixes on libs. Not being able to easily build current mesa code would not be a good thing.
bluetail21 has quit []
fab has quit [Quit: fab]
<Frogging101>
Vanfanel: Did you have to upgrade your LLVM or GCC to build the latest Mesa?
<Frogging101>
Mesa bumps its LLVM requirement more often than GCC, I believe. But I think they try to keep it compatible with what the stable distros have got
<Frogging101>
I don't know if we could "bump the compiler version once a year"
<Vanfanel>
Frogging101: Never had to upgrade GCC to build MESA, no.
<orbea>
Speaking from experience upgrading gcc is far easier than upgrading rust
<orbea>
(by hand)
Duke`` has joined #dri-devel
<orbea>
as is updating llvm
lkw has quit [Ping timeout: 480 seconds]
<Frogging101>
Updating LLVM is relatively easy
<Vanfanel>
Really, are we going to need Rust to build MESA anytime soon?
<orbea>
its nothing like spending all day figuring out how to fix the rust build, but then subsequently forgetting to to commit the patches and then never noticing until they are long gone because for some reason they are no longer needed...
<Frogging101>
That's what the thread is about
<Vanfanel>
Also, building MESA on stable Debian or other stable distros is not only important for bug reporting, it's also important because some of us use MESA in different architectures (armhf, aarch64) and without any X11 support built-in, for embedded systems.
<Frogging101>
Rusticl would be the only driver that uses rust to start with, so you could just exclude that one if it won't build
<Frogging101>
If other parts of the codebase pick up Rust, that won't be the case though
<Vanfanel>
Well, I just wanted to point out that stable Debian + current stable MESA is not a crazy idea, @ajax
<MrCooper>
AFAIK updating rust should be trivial with rustup
<kisak>
For my PPA, I'll discontinue updates for the affected Ubuntu release instead of bumping gcc, there's too much of a regression risk for my taste. Luckily, I haven't hit a show stopper there, just disable freedreno tests on bionic.
<MrCooper>
Mesa's CI uses that on top of Debian stable
frieder has quit [Ping timeout: 480 seconds]
<kisak>
s/disable freedreno tests/disable build-time tests due to a freedreno gcc 7 snafu/
<MrCooper>
coincidentally, since Mesa's CI is largely based on Debian stable, can always look at that for how to build current Mesa :)
<jenatali>
FWIW, from a Windows perspective, I don't see any immediate concerns, though I don't plan on picking up rusticl, so I probably won't really care until it starts to invade some more core Mesa code
kts has joined #dri-devel
rgallaispou1 has quit [Read error: Connection reset by peer]
frieder has joined #dri-devel
stuart has joined #dri-devel
fab has joined #dri-devel
frieder has quit [Ping timeout: 480 seconds]
fahien has quit [Ping timeout: 480 seconds]
soreau has quit [Read error: Connection reset by peer]
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #dri-devel
<daniels>
lygstate: it's loading MRs with comments in <2s for me
<daniels>
and I'm not on the same continent as it
<jenatali>
Yeah seems fine to me too
<lygstate>
thanks, it's recovered now..
saurabhg has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
kem has quit [Ping timeout: 480 seconds]
luc4 has joined #dri-devel
carbonfiber has quit [Quit: Connection closed for inactivity]
kem has joined #dri-devel
Vanfanel has quit [Quit: Lost terminal]
lkw has joined #dri-devel
bluetail21 has joined #dri-devel
sdutt has quit []
sdutt has joined #dri-devel
<DemiMarie>
Regarding Rust in Mesa: one nasty problem for GPU virtualization is that (without SR-IOV) there is no way to safely submit an untrusted shader to the GPU for execution that does not involve running a complex compiler pipeline on untrusted input.
<DemiMarie>
Would it be possible to have a GPU version of WebAssembly?
<linkmauve>
DemiMarie, neobrain once compiled Mesa in wasm, see his video at last year’s XDC.
<linkmauve>
It’s still the same compiler pipeline running on the same untrusted input though.
<DemiMarie>
linkmauve: that would help if there was a way to verify the output of the pipeline
<linkmauve>
DemiMarie, verify which properties?
<DemiMarie>
linkmauve: basically “compiling and running this program will not cause harm”
<DemiMarie>
So no undefined behavior, bad memory access, etc
<DemiMarie>
I’m being vague because I do not know what the format should be, and the format will determine the exact properties that need to be checked.
<linkmauve>
DemiMarie, for(;;) do_unoptimisable_operation(); is a valid shader, and you can’t realistically find all shaders which do that.
<DemiMarie>
linkmauve: it is up to the compiler and runtime to insert necessary runtime checks
<ajax>
most of those concerns are just ARB_robustness, right?
<_alice>
What’s up?
<DemiMarie>
linkmauve: for the example you mentioned, this could be solved by either preempting the shader in the middle of its execution, or by having the compiler insert the necessary checks.
<ajax>
(do we even have shader preemption for any hardware)
<DemiMarie>
ajax: this is below the OpenGL and even Vulcan levels
<linkmauve>
Isn’t it usually done with a watchdog, which resets the GPU after it’s been hung for a while?
<DemiMarie>
linkmauve: not acceptable here, hence the suggestion of inserting preemption checks into generated code
<ajax>
DemiMarie: fine: aren't most of those concerns addressed by the hardware functionality that would allow you to expose GL_ARB_robustness, and which i think are effectively mandatory for vulkan?
<ajax>
(you see why i said the shorter thing)
<DemiMarie>
ajax: what about robust image access?
<ajax>
keep adding more extensions to my list until you get there...
<DemiMarie>
also, I had not heard of GL_ARB_robustness until you mentioned it
<ajax>
there's a few of them in that area
<ajax>
mostly originating around the time of webgl, for reasons quite like you're describing
<DemiMarie>
not surprising
<ajax>
i think trying to do the kind of validation you're describing at the (any) IR level is futile
<DemiMarie>
ajax: s/IR/bytecode then
<DemiMarie>
and if you are referring to Rice’s theorem, that is what runtime checks are for
<ajax>
i'm not, i'm saying i think it's the wrong level of abstraction for the task
<DemiMarie>
GLSL source is certainly the wrong abstraction
<DemiMarie>
I want to move the validation as close to the end of the pipeline as possible
fab has quit [Quit: fab]
<DemiMarie>
What do you think the correct abstraction is?
<ajax>
well to the extent that there _is_ such an IR, it's NIR, and it's already as simple as it can be because if it were any simpler it wouldn't implement opengl
<DemiMarie>
Assume that OpenGL is handled via Zink
<ajax>
okay
<ajax>
that changes zero things since zink's ir is nir, but, okay
<DemiMarie>
What I meant is that anything needed for OpenGL but not Vulkan can be left out
<ajax>
i don't think the vk subset of nir is meaningfully smaller than the whole. *shrug*
<DemiMarie>
ajax: then this is useful information
<DemiMarie>
Is the problem that GPUs are fundamentally more complex than CPUs?
cuolin^ has joined #dri-devel
gouchi has joined #dri-devel
gouchi has quit []
<robclark>
DemiMarie: if anything about your GPU is relying on compiler (or anything in userspace) for "safety" you are doing it wrong ;-)
<DemiMarie>
robclark: does that mean that exposing the raw ioctl API to untrusted userspace is safe in practice?
<robclark>
it better be.. userspace is by definition untrusted
lemonzest has quit [Quit: WeeChat 3.5]
mvlad has quit [Remote host closed the connection]
<ajax>
yeah, glsl is quite intentionally structured to avoid the kinds of divergence problems that make it hard to analyze, but you still need to emit instructions. even if you emit them all "correctly" you might still be able to express something like addressing off the end of an image, so you really need hardware to enforce that not happening.
<ajax>
hence robust image access &c
<ajax>
if the ioctl api lets you do unsafe things it's quite likely because that gpu ha[sd] no safe way to do them
<DemiMarie>
robclark: I know it is supposed to be. My question is if it actually is. It ought to be safe to give someone shell access to your laptop as a distinct unprivilege user, but in practice it would be a bad idea.
cuolin^ has quit [Ping timeout: 480 seconds]
<ajax>
but post-kms that's largely not the case
<robclark>
cl and vk w/ extensions gives the shader raw pointers.. at that point you really rely on the hw and the kernel ensuring the hw isolation is used properly
<DemiMarie>
Are there people trying to find vulnerabilities in desktop GPU drivers?
<robclark>
DemiMarie: if it is not safe, that would count as a bug.. bugs do happen occasionally.. but the model from security PoV is that userspace is not trusted. On some older devices, that involved kernel doing cmdstream and shader analysis as needed (but the capabilities of those older GPUs was also much less)
<airlied>
robclark: before we had virtual memory
<robclark>
right
<ajax>
DemiMarie: almost certainly, yes.
<DemiMarie>
robclark: so my question is how often do those bugs happen, and how many people are trying to find them
<DemiMarie>
rough estimates in both cases
* airlied
doesn't see that many CVEs about GPU drivers, which either means it works, or not enough people are searching for vulns in them :-P
<airlied>
I'm mostly inclined towards the latter :-P
<DemiMarie>
And that is the problem
cuolin^ has joined #dri-devel
<robclark>
you can search CVE's I suppose.. I've seen a lot about downstream android kernel drivers (kgsl and kbase).. not so much in upstream driver
<DemiMarie>
On the other hand Android is much more likely to be running malicious apps
<airlied>
yeah and downstream drivers are likely to be an unmitigated mess probably with the exception of nvidia
<jekstrand>
hakzsam: Yeah, it's on my list for this week, maybe.
<airlied>
I think we all just assume the DoSing the GPU is easy :-)
<DemiMarie>
Why are Android GPU drivers generally not upstream?
<airlied>
a) shit b) badly architected shit, c) closed source userspace, in this case you can choose all 3
<karolherbst>
d) dubious business practises
<DemiMarie>
robclark: CVEs are not a good indication because kernel vulns often do not get CVEs
<robclark>
I'm not sure that is true
<DemiMarie>
airlied karolherbst: I hope that Google starts requiring Android devices to have all kernel mode drivers fully upstream. Anything that cannot be upstreamed should be behind a default-on IOMMU and handled in userspace.
<karolherbst>
DemiMarie: I hope they would enforce open source userspace though
<robclark>
that doesn't really change anything about kbase/kgsl
<robclark>
both are behind an (io)mmu
<airlied>
robclark: unless you let the gpu program the iommu :-P
<airlied>
still my favourite optimisation ever
<DemiMarie>
robclark: hence my suggestion about requiring *all* kernel mode drivers to be upstream
<DemiMarie>
if it can’t be upstreamed, you run the driver in userspace and take the performance hit
<robclark>
oh, yeah, I think upstream should be required.. just pointing out that kbase and kgsl have a way to wiggle out of that ;-)
<DemiMarie>
how?
<robclark>
(but running the driver in userspace is a worse idea)
<DemiMarie>
for GPU drivers on Linux I agree
<karolherbst>
DemiMarie: running GPU drivers in userspace is a terrible idea though, for multiple reasons
<DemiMarie>
For microkernel-based systems, or for peripherals other than GPUs, I disagree
<robclark>
the gpu has some form of mmu and/or iommu.. all modern gpu's do
<karolherbst>
most important: impossible to have a secure system
<karolherbst>
DemiMarie: even for microkernel it's not possible
<DemiMarie>
karolherbst: this is false
<airlied>
yeah running it in userspace isn't really going to fix anything
<karolherbst>
how do you configure DMA?
<airlied>
the iommu is there already
<DemiMarie>
karolherbst: every microkernel has ways of doing that
<airlied>
you can still DoS the hardware
<karolherbst>
DemiMarie: it's not secure though
<airlied>
it's not like we are parsing shader strings in the kernel
<DemiMarie>
karolherbst: tell that to the microkernel developers, not me
<karolherbst>
DemiMarie: I did and they usually went away with a "huh.... interesting"
<DemiMarie>
karolherbst: what is the specific exploit?
<karolherbst>
some even say "well, it's root, even linux can read/write all kernel mem" which isn't true :D
<karolherbst>
DemiMarie: DMA usually allows you to access all kernel mem. If you require an IOMMU though you can mitigate that, but tell me that arch where all systems have an IOMMU
<karolherbst>
so you write a nice userspace driver, but it's useless for a lot of systems
<karolherbst>
good job
<karolherbst>
sure.. you can require an IOMMU, but what about the systems who doesn't have that
<DemiMarie>
karolherbst: That is well-known. Microkernel-based systems often have a system initializer that is part of the same image as the kernel, and which assigns different userspace processes access to different resources.
<karolherbst>
DemiMarie: so? you still allow userspace full kernel mem access with that
<karolherbst>
which is a security problem. period
<karolherbst>
you could have only let signed binaries do that though
<karolherbst>
and then it could be fine
<DemiMarie>
karolherbst: I agree that running in userspace may not always be a security *improvement*, but assuming the userspace code is trusted (a bad assumption on Linux) I do not see how it is a security *regression*.
<karolherbst>
this is even hard enforced with secure boot enabled
<DemiMarie>
karolherbst: or only a binary that is bundled with the kernel itself
<DemiMarie>
karolherbst: yes, Linux does not work this way
<karolherbst>
well.. on Linux userspace can't configure DMA
<karolherbst>
if you start doing it out of the sudden it is a security regression
<DemiMarie>
regarding Android, yes I did mean that anything without an in-tree driver should be required to be behind an IOMMU
<DemiMarie>
karolherbst: the VFIO API lets one do just that
<karolherbst>
DemiMarie: well, but you can only access device memory and only those without an active driver, no?
<karolherbst>
because you want to configure stuff for guests
<DemiMarie>
karolherbst: VFIO allows one to drive DMA-capable devices from a userspace process. DPDK works that way.
<karolherbst>
can you access random physical addresses with that?
<DemiMarie>
My point is that provided that the userspace process is sufficiently protected, running driver code in userspace is not worse than running in the kernel
<DemiMarie>
If a kernel mode driver is compromised, that is game over. If a user mode driver is compromised, then (depending on the hardware, IOMMU, etc) it might not be game over.
<karolherbst>
my point is, that we don't want userspace do access arbitrary physical memory, with a few exceptions
<karolherbst>
DemiMarie: if that process can access all physical memory, it's also game over :P
<DemiMarie>
karolherbst: you can ask the hardware to, but the IOMMU will block it
<DemiMarie>
and if there is no IOMMU then trying to attach to the device will fail
<karolherbst>
yeah, then you require an IOMMU again, and sure for those drivers it's good enough
<karolherbst>
it's just not a valid general solution
<karolherbst>
for android and newer devices that might be totally fine and moves the costs to the device manufacturers. That's cool and all.
<karolherbst>
it's just not a valid approach if you don't have an IOMMU
<DemiMarie>
karolherbst: that was my thought indeed
<DemiMarie>
And if a system does not have an IOMMU then I consider it fundamentally broken in most cases.
<DemiMarie>
Same for systems without a hardware CSPRNG
<robclark>
karolherbst: at least the arm gpu's all memory access is via (io)mmu, so kernel is in control of memory access.. but ofc that is relying on kernel to setup the pgtables (ie. you don't want the driver in userspace for obvious reasons)
<karolherbst>
most of those microkernel fans I talk about, they want to implement userspace drivers for _all_ users, and then I tell me why that's a bad idea :D
<karolherbst>
DemiMarie: yeah.. sadly a lot of x86 don't have an IOMMU
<karolherbst>
robclark: right.. it's shared memory, so the kernel has that protected anyway
TMM has joined #dri-devel
<DemiMarie>
karolherbst: so my perspective is that if you properly authenticate/protect/etc the userspace code (which is easy in microkernels), then a userspace driver is not worse than a kernelspace driver
<DemiMarie>
it may not be better, but it is not a regression
<DemiMarie>
(modulo CPU bugs)
<DemiMarie>
You need an IOMMU to get the security improvement, though.
guru_ has joined #dri-devel
oneforall2 has quit [Read error: Connection reset by peer]
<karolherbst>
yeah... in case of authenticated userspace it _might_ be good enough, but those still can have issues. But yeah, in this case it's not really different from a kernel driver. But then you have to make sure your authentication process is tight
<DemiMarie>
karolherbst: in this case the userspace would be authenicated by being part of the same ELF/PE/etc binary as the kernel 🙂
<karolherbst>
well.. yeah, then they are de factor like kernel modules anyway :P
<karolherbst>
just have their own VM
<karolherbst>
(which I think linux people are working on for linux as well)
<karolherbst>
at least I've heard about ideas on giving kernel modules their own VM space
<DemiMarie>
And even if you have to trust some of your drivers, hopefully you have e.g. your network adapters behind an IOMMU
<karolherbst>
yeah... well
<karolherbst>
we now got GPUs which fetch data from nework devices directly :D
<DemiMarie>
karolherbst: that is for certain server hardware I do not care about
<karolherbst>
true
<DemiMarie>
Even if you have to trust all of your drivers, you can still sandbox stuff like the TCP/IP stack, filesystems, Bluetooth and USB protocol implementations, etc
<karolherbst>
anyway.. I think if Linux and micro kernels are written properly they only differ in naming in the end :)
<DemiMarie>
Which is still a win compared to Linux
<karolherbst>
can do the same on linux if you really wanted to
<DemiMarie>
karolherbst: if by that you mean that Linux should become a microkernel then I agree
<karolherbst>
don't have to go that far though
<DemiMarie>
Just moving Bluetooth, 802.11, and USB into userspace would be an enormous win.
<karolherbst>
imagine you would be able to hand each kernel driver its own VM space, what else do you need for isolation?
<emersion>
karolherbst: wouldn't that be intractable? e.g. DRM interacts with a lot of other subsystems
<DemiMarie>
Give it a limited syscall table with only a subset of syscalls, and make sure everything that talks to it considers it untrusted
<emersion>
by "interacts" i mean "calls functions"
<karolherbst>
emersion: yeah.... not sure how that all really works under the hood. I just know that people work on sometihng like that apparently
<emersion>
you'd need to change quite a lot of stuff to replace that with proper IPC
<DemiMarie>
emersion: The first step is making all of those interactions explicit.
<robclark>
yeah, even just think about interaction w/ mm subsys (shrinker/etc).. I'm not sure how that could even work w/ microkernel
<DemiMarie>
Something I have said before is that Linux is two things:
<DemiMarie>
1. A kernel based on a fundamentally insecure and obsolete architecture.
<DemiMarie>
2. A huge amount of good-quality systems software that one would be foolish to try to rewrite from scratch.
<karolherbst>
"good quality systems software" good joke :P
Duke`` has quit [Ping timeout: 480 seconds]
<DemiMarie>
robclark: I suspect things get much easier if one requires all buffers that might be used for DMA to be non-pagable
<karolherbst>
though others are not better and that's the scary part
<DemiMarie>
In the long run I want to see everything formally verified, so that code quality is machine-checked.
<robclark>
yeah, ofc if you ignore hard problems things get simpler
<karolherbst>
I think what I dislike most about this "microkernel solves your security problems" is, that it 1. won't and 2. makes it sound like an easy solution even though it won't be less work than with linux
<emersion>
DemiMarie: that's really not possible
<karolherbst>
so it's nice on paper, but it comes with the same issues
<karolherbst>
developers suck and will mess it up
<DemiMarie>
emersion: formally verifying everything, no, formally verifying the critical components exposed to untrusted input, hopefully
<karolherbst>
ohh no
<karolherbst>
that formal verification fallacy :(
<emersion>
then the code becomes frozen
<DemiMarie>
karolherbst: a microkernel does not solve everything
<karolherbst>
you can't formally verify code
<karolherbst>
period
<karolherbst>
it's a myth
<emersion>
and it takes an enormeous emount of effort to verify very little code
<emersion>
even very simple code
<karolherbst>
the biggest issue is, that you don't look at the instruction level
<karolherbst>
sure.. that _C_ code might do what you think it does, but the instructions probably do more or less
<karolherbst>
and then weirdo side effects you won't see
<karolherbst>
DemiMarie: my point is, a microkernel does not solve _anything_
<karolherbst>
developers suck
<karolherbst>
there will be bugs
<DemiMarie>
karolherbst: A microkernel does not solve all security problems. It just does not _cause_ the security problems microkernels do
<karolherbst>
and I don't see why they are less severe with microkernels
<DemiMarie>
obviously meant monolithic kernels for the second one, duh
<karolherbst>
it's all nice in theory
<karolherbst>
but until today, where is this awesome microkernel?
<DemiMarie>
karolherbst: because a flaw in the TCP/IP stack, Bluetooth protocol implementation, filesystem driver for your USB stick, etc is not instant game over
<karolherbst>
same with microkernels
<karolherbst>
ehh I mean, it can be an instant game over
<karolherbst>
you make it sound like that's impossible
<karolherbst>
but we have JS scripts doing data extraction
<karolherbst>
microkernels won't prevent that crap
<karolherbst>
there will always be a way
<DemiMarie>
If those drivers run in kernel space, then it is game over. If they run in userspace, then there is a chance of them not being.
<karolherbst>
why?
ManMower has joined #dri-devel
<DemiMarie>
because if they run in userspace, then the attacker still has to find another flaw to take over the system
<karolherbst>
why is it different in a microkernel world where userspace can do more than userspace in linux
<karolherbst>
you increase the attack surface through userspace compared to linux
<karolherbst>
which I don't think is a good idea
<karolherbst>
so _why_ is there a lower chance of messing up
<karolherbst>
you all talk about the positive things and just ignore the drawbacks
<DemiMarie>
karolherbst: the difference is that the things I mentioned (IP/Bluetooth/USB etc) can run de-privileged
<karolherbst>
but "de-priviliged" is not true, is it?
<DemiMarie>
karolherbst: it *can* be true
<karolherbst>
micro kernel userspace has more privilegse than linux userspace
<DemiMarie>
karolherbst: that is not necessarily true
<karolherbst>
DemiMarie: well everything *can* be true
<DemiMarie>
some microkernel userspace, yes, but not all of it
<karolherbst>
there can be a bug to allow any userspace to do random crap
<DemiMarie>
karolherbst: my point is that you have to move these things out of the kernel before you can start sandboxing them
<karolherbst>
sandboxing is all nice until your sandbox is broken, now you rely on another complex security feature
<airlied>
it's really a pointless discussion, until there is a microkernels that has the same feature set and can be compared
<karolherbst>
yeah
<karolherbst>
"What if" ...
<karolherbst>
yes, if linux would be totally secure that would be nice
<karolherbst>
:P
<airlied>
when HURD catches up, you can get back to it, otherwise I suggest it's going off topic
<DemiMarie>
airlied: I assume you mean “microkernel with associated userspace”, but yes, this is (very) off-topic.
<karolherbst>
anyway.. it's all perfect in theory until you try to do that and hit impossible to fix problems and you are screwed
lkw has quit [Quit: leaving]
<airlied>
DemiMarie: it's extra off topic for GPUs, since our kernel drivers aren't really a major attack surface
<karolherbst>
take away from that: developers suck and you have to deal with security issues and do it properly
<airlied>
since the graphics stack is architected in a way to leave the known exploitable stuff in userspace anyways
<robclark>
the idea that microkernel's solve anything is really just overlooking the complexity of mm/locking/power/etc.. and kinda pointless because it isn't solving a frequent category of bug.. tbh rust is probably a better direction for solving the issues that u-kernel type sandboxing claims to solve
<karolherbst>
robclark: yep
<karolherbst>
rust deals with the "developers are crap" probem
<karolherbst>
which is fundamental the nr 1. cause of bugs
<robclark>
anyways, I'm always prepared to re-evalulate my stance on microkernels if a decent one ever comes along.. but we've been waiting a pretty long time for that already ;-)
<karolherbst>
the less possibilites you give developers to mess things up _in_code_, the better/more secure your system becomes
<DemiMarie>
Agreed
<airlied>
robclark: won't fuschia solve all our problems :-P
<robclark>
lol
<robclark>
fuschia is a solution in search of a problem ;-)
<karolherbst>
the key take away I have with my rusticl work is, I do all those random memory corruption bugs way less often :D
dviola has quit [Quit: WeeChat 3.6]
luc4 has quit [Remote host closed the connection]
luc4 has joined #dri-devel
krushia has joined #dri-devel
<agd5f>
karolherbst, you should see IOMMU on all new x86 platforms from the last couple of year due to VBS requirements from MS
<karolherbst>
right.. but not on old hardware
<karolherbst>
and what about low budget systems in the future etc.. etc...
<karolherbst>
maybe we can make IOMMUs a hard requierement in like 15 years or so
<karolherbst>
at least we can't do that today
<agd5f>
I think most AMD and Intel system from the last 10 years have an IOMMU at least on the platform, although maybe not enabled by default in the bios
<karolherbst>
not all of them
JohnnyonFlame has joined #dri-devel
<clever>
the last time i played with the iommu, my problems where due to a lack of per-slot pci reset
<clever>
the gpu had to be in a pristine out-of-bios state for the drivers to be able to init it
<clever>
and once tainted by any drivers, it would never init again, until the whole system reset
<clever>
and that made passthru kind of pointless
<karolherbst>
I think broadwell is the first intel gen were at least all CPUs support IOMMUs
<karolherbst>
but yeah.. that's roughtly 8 years
mbrost has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
apinheiro has joined #dri-devel
<mareko>
Kayden: the only way we can reasonably reduce glvnd overhead from within Mesa is to enable glthread by default, drop glapi, and return _mesa_mashal_* from GetProcAddress
<mareko>
*_mesa_marshal_*
<mareko>
and remove non-glvnd paths
<mareko>
there is a dispatch table at the back of glthread, and that's enough
<anholt>
mareko: glvnd has an interface for rewriting its dispatch, it looked like to me.
<Kayden>
enabling glthread by default doesn't feel like the right answer to me, I know that doing so actually dropped performance on a bunch of things
<Kayden>
the problem is how many layers there are and how much overhead that adds to a single GL function, but I don't see why that couldn't be reduced without glthread
<Kayden>
(maybe it requires altering glvnd itself, but I assume that's an option)
<DemiMarie>
Will Zink eventually replace all other OpenGL drivers? That is, will Vulkan eventually be the only “native” API, with everything else being a wrapper around it?
<Kayden>
I don't think so
<DemiMarie>
What is the reason for that?
agners has quit [Quit: WeeChat 3.6]
<Kayden>
personally I think that a lot of the "radv+zink is nearly as fast as radeonsi" commentary is because radv is using ACO and radeonsi is not yet
<Kayden>
if I had to guess
<Kayden>
zink still goes through all the overhead that native gallium drivers have, plus it has to go through vulkan, and while there's been phenominal work done in making it fast, I expect it will still miss out on optimization opportunities that a native driver could take advantage of, and have more overhead
<mangix>
making zink as performant as the native opengl drivers sounds like quite the engineering challenge
<Kayden>
perhaps I'll be wrong about that
<Kayden>
now...does it change the "should I bother writing a new OpenGL driver for new hardware" -> "is it worth the effort?" calculation? absolutely.
<DemiMarie>
Why is the M1 GPU driver an OpenGL driver and not a Vulkan driver?
<DrNick>
because all the critical system software uses OpenGL so it can run on 15 year old GPUs
<DemiMarie>
I see. Would making a Vulkan driver and relying on Zink be easier?
<DemiMarie>
DrNick: is this a good or bad thing?
<DrNick>
no idea
gawin has joined #dri-devel
dakr has quit [Ping timeout: 480 seconds]
<robclark>
probably starting out w/ vk driver is not easier.. since vk requires a lot more compared to gl2
<robclark>
tbh, a gallium driver is as easy or perhaps easier to write than a vk driver
<airlied>
i think they just werent vulkan knowledgable
<airlied>
at the time
<robclark>
the calculus would be a bit different if it was writing a full gl driver vs just a gallium driver
<airlied>
not sure if the plan is to keep working on the gl driver
<airlied>
vulkan vs gallium isnt massively different though
<DemiMarie>
Is there a plan to have a framework for Vulkan the way Gallium is for OpenGL?
<airlied>
writing the compiler is the hard part
<airlied>
DemiMarie: vulkan doesnt work like that reslly
<airlied>
vulkan is the gallium api
<robclark>
mesa does already have shared code for vk where it makes sense
<robclark>
but yeah, a gallium type thing wouldn't make sense for vk
<airlied>
lots of sharing opportunities but not really a framework
luc4 has quit []
gio has quit [Ping timeout: 480 seconds]
<airlied>
I think sometimes alyssa will appear and can answer why the gl in that case
<airlied>
Kayden: I think the problem with most GL drivers is there isn't much incentive to actively add features to them anymore, and if zink can take advantage of vulkan features to do things faster, it might be a win
<airlied>
Kayden: though my main worry with zink would be increased cpu overheads vs a native GL driver,
<airlied>
but then again Intel once stated that gallium would never outrun classic due to overheads :-P
<airlied>
and we had to live with the consequences of that choice for rather longer than necessary!
<jenatali>
Yeah, a good mapping implementation to a good low-level implementation can absolutely be faster than a bad monolithic one
<jenatali>
But topping a good monolithic one is pretty challenging for sure
<airlied>
yeah at least on the arm front I don't think we have many worries from a good monolithic one :-P
<jenatali>
Yeah... same here :P
<Kayden>
there is a lot more common VK code these days thanks to jekstrand's recent work
<mdnavare>
daniels: Kayden: Looking at the mutter commit : https://gitlab.gnome.org/GNOME/mutter/-/commit/8de449dc725e932b2cf171ff0df4c172f9379ff2 here it is disabling modifiers support on i915 only and it talks about memory constraints in multi head case, does anyone know details of what is the concern with multiple monitor/display case so that we can work on i915 kernel to fix that. We need to enable modifiers by default in mutter for i915
<Kayden>
seems more like a toolkit approach rather than a framework approach
<Kayden>
but still nice to see
<karolherbst>
if you have 10 developers working on GL it's definetly a good thing, but if it's like 2 person working on the full driver, it might make more sense to just focus on Vulkan
<karolherbst>
you'll never outpace zinks development, also you withdraw time spent on the vulkan driver
<karolherbst>
it all boils down to "can we actually get to a proper gl driver outperforming zink"
<airlied>
mdnavare: I asked the mutter devs to enable modifiers for clients at least
<DemiMarie>
What if you have 1 dev working on the whole thing?
<karolherbst>
then do vulkan
<karolherbst>
GL doesn't even make sense then
<DemiMarie>
I ask because that seems to be Alyssa’s situation
<karolherbst>
you really want to focus on vk + the compiler
<DemiMarie>
From her blog post it seems that it was to get something on the screen ASAP
<karolherbst>
adding gl into the mix just makes you work less on the compiler side
<karolherbst>
yeah...
<karolherbst>
soo there is the thing.. you can potentially write stuff upfront in a way you can just move it into a vulkan driver, and that's good
<karolherbst>
but you can also get something real quick done with vulkan
<robclark>
gl needs a lot less of the hw features to be enabled to get something on the screen.. plus a lot of times the hard work is figuring out how the hw works, rather than typing the gallium or vk driver code
<karolherbst>
sure about that?
<robclark>
in the end neither is a massive amount of code
<robclark>
yeah
<karolherbst>
well.. meant the first part
<karolherbst>
you will probably fight with the hw 90% of the time, that's for sure
<DemiMarie>
robclark: define massive
<robclark>
if you are just going for gl2 or bare min to get some things working
<karolherbst>
if the target is "do I implement this API completely" then probably sure
<Kayden>
airlied, mdnavare: awesome, thank you, didn't realize that had happened recently! that's going to help us a ton, because right now we're getting linear for on-screen GL apps, which also prevents all fast clears (even internally)...even if you're not ever handing those buffers to KMS
<karolherbst>
but to just get _something_ working?
<mdnavare>
airlied: Yes thanks for pointing that out, is it merged upstream already?
<karolherbst>
the biggest time sink will be the compiler anyway
<airlied>
mdnavare: yes but not sure what release it is/will be in
<Kayden>
it has GNOME 43 set as the milestone
<karolherbst>
I'd even say, assuming you already have a fully capable compiler, writing either GL or a vk driver doesn't take long
<robclark>
DemiMarie: freedreno for 5 gens (not counting code shared by vk driver) is ~53k loc.. that's not really that much
<mdnavare>
Kayden: So this merge request will now be similar to our expirements of reverting the disable modifier udev rules?
<DemiMarie>
karolherbst: if I had to guess (as someone who knows zilch about Mesa’s guts), the goal was “get *a* real-world application (even an old one) working ASAP”, which makes sense
<bnieuwenhuizen>
robclark: that about the same as radv excluding compiler
<airlied>
mdnavare: it won't fix the original problem with modifiers and memory constraints
<mdnavare>
Kayden: And in this case atleast the glmark2 should start using tiled/compressed buffers instead of linear but we still will be passed a linear to KMS right?
<karolherbst>
DemiMarie: not sure if that even matters then
<airlied>
mdnavare: but it should fix apps running
<karolherbst>
robclark: I'd say that's quite a lot actually :P
<mdnavare>
but will still pass linear buffers to the driver right
<mdnavare>
airlied: ?
<robclark>
bnieuwenhuizen: yeah by the time it gets to full featured gallium vs vk driver, I'd expect them to be able the same size.. but gallium driver could also be a lot smaller and just support enough to get gl2
<karolherbst>
maybe it's like 40k loc generated headers or soetmhing?
<robclark>
naw those aren't checked in
<bnieuwenhuizen>
robclark: you could always say "I'm going to support just enough to do gl2.1 on zink"
<robclark>
if I counted the headers it would be a lot more
<Kayden>
mdnavare: if you check the comments in that MR it sounds like they're enabling modifiers again without doing the lots-of-TEST_ONLY-commits solution to see what works. so, I kind of expect incoming bug reports about "if I use wayland on 3 monitors nothing works anymore"
<karolherbst>
robclark: then it's huge
<karolherbst>
afaik for nouveau we have like 10k loc and pass 90% of vk 1.0 unless I missed something
<DemiMarie>
Speaking of Vulkan, one of my worries is that <insert major program that is not too graphics intensive> will wind up using it
<karolherbst>
DemiMarie: like games :P
<karolherbst>
though on the arm soc side that's less of an issue.. probably
<karolherbst>
for now
<airlied>
Kayden: only if you have direct scanout on all 3 monitors
<airlied>
which I think means fullscreen apps
<DemiMarie>
karolherbst: specifically, one of my fears is that software rendering will keep regressing further and further
<mdnavare>
Kayden: Yea so still for a particular modeset if that modifier/format/crtc combination doesnt work, i915 will reject it with atomic check fail
<airlied>
it won't use modifiers for normal wayland
<karolherbst>
DemiMarie: why would software rendering regress?
<airlied>
but yeah mutter needs to add code to do test only commits, it's a known issue
<karolherbst>
ohh you mean apps doing sw rendering
<karolherbst>
yeah, they should stop that
<DemiMarie>
karolherbst: because application writers don’t care
<karolherbst>
wasting CPU cycles even though a GPU can do that a lot cheaper
<karolherbst>
== higher battery runtime
<DemiMarie>
One of the GTK developers flat-out told me that software rendering performance is a non-goal of theirs
<karolherbst>
because it's slow
<karolherbst>
and always will be
<mdnavare>
Kayden: airlied: The recommended dev work in Mutter would be to add test only commit before requesting a modeset with a fb using a particular modifier for a particular crtc combination?
<karolherbst>
ditching SW rendering is the only sane choice you can make as a OS designer
<mdnavare>
airlied: Actually can you elaborate on what exactly was the memory bw issue seen in KMS?
<DemiMarie>
karolherbst: that (implicitly) assumes that a GPU will always be present
<karolherbst>
you can always have a fallback for systems without CPUs
<mdnavare>
airlied: Ah okay lemme read the issues link just saw thanks
<karolherbst>
and if you don't have a GPU, you probably don't care about GUI alltogether
<airlied>
DemiMarie: 4k makes using a cpu kinda pointless
<DemiMarie>
karolherbst: Qubes OS says otherwise
<karolherbst>
not having a GPU but expecting fast 2D drawing? that doesn't make sense
<karolherbst>
DemiMarie: don't punish others for your own mistakes :P
<DemiMarie>
karolherbst: doesn’t need to be fast, just usable
<karolherbst>
if Qubes OS want's to do silly sw rendering, that's their choice, just leave the others alone
<DemiMarie>
karolherbst: mistakes?
<DemiMarie>
karolherbst: what do you recommend we do instead? Serious question.
<Sachiel>
llvm/lavapipe are there if you just want usable
<Kayden>
airlied: ah, I missed that it would only be an issue if it was using direct fullscreen scanout on all 3 displays. so mutter's composited image would still be linear, but all the source data from apps could be tiled/compressed. nice
<karolherbst>
yeah.. not enabling hw accelerated rendering in any OS is a mistake
<karolherbst>
hw accelerated rendering :P
<DemiMarie>
karolherbst: how do you recommend we enable it?
<karolherbst>
well.. that's for you to figure out
<Kayden>
airlied: then if mdnavare can find people to do the TEST_ONLY brute-force-checking system, it could use modifiers for KMS as well, I suppose
<karolherbst>
just saying that I don't care one bit about Qubes OS wanting fast software rendering
<Kayden>
still, that's a huge improvement in the meantime
<airlied>
Kayden: yes pretty much
<DemiMarie>
karolherbst: the reason I am asking is because the people here know vastly more about GPUs than I do.
<karolherbst>
if they want it, they can invest into it
<airlied>
Sachiel: llvmpipe/lavapipe suck at 4K though :-)
<karolherbst>
DemiMarie: well.. we do have GPU drivers, so... just make use of them?
<gawin>
returning to vulkan vs OpenGL: isn't radv with zinc kinda best possible scenario? I have (maybe false) view that vulkan (with layers) can be more unpredictable if hardware can't perfectly match api. (like OpenGL)
<karolherbst>
disabling hw acceleration in Qubes OS is a design choice
<karolherbst>
not because it's necessary
<karolherbst>
it's a "feature" in the literal sense in regards to Qubes OS
<karolherbst>
gawin: hard to say, if you can invest a lot into your GL driver, you can make it fast
<karolherbst>
it really boils down to how much time you spend on improving it
<karolherbst>
and people work on radeonsi _a_lot_ to reduce overheads
<DemiMarie>
karolherbst: it isn’t that we don’t want hw acceleration
<DemiMarie>
we do want it
<mdnavare>
Kayden: airlied: How are these working with AMD in case of atomic modeset with multi headed /multi display set up?
<DemiMarie>
The question is how to get it in a secure way.
<karolherbst>
by fixing bugs
<DemiMarie>
karolherbst: so make some sort of PV GPU protocol and fuzz the heck out of it?
<Kayden>
mdnavare: AFAIK they have enough display bandwidth to hit hit DDB limitations.
<karolherbst>
maybe
<airlied>
mdnavare: I think by luck, they just have less memory bandwidth constraints
<airlied>
DemiMarie: just use virtio-gpu and fuzz the virgl protocol more
<karolherbst>
DemiMarie: but I am sure you could make use of libvirts GL virtualization
<airlied>
it's been fuzzed a few times
<Kayden>
*not hit
<airlied>
though you'd probably want to use venus now rather than virgl
<bnieuwenhuizen>
airlied: we also help a tiny bit in the mesa driver by skipping some modifiers for big images
<karolherbst>
but if you want strict isolation... then yeah.. won't get it
<karolherbst>
airlied: venus?
<bnieuwenhuizen>
though that is more decompression width restrictions than pure bandwidth
<Kayden>
bnieuwenhuizen: ooh, really? I didn't realize that
<karolherbst>
ohh vulkan
<DemiMarie>
airlied: can I put the kernel driver in a mode where it always zeros out buffers before allocating them?
<karolherbst>
... right
<Kayden>
bnieuwenhuizen: maybe I should be doing something similar?
<karolherbst>
DemiMarie: that's a bug and we should fix it :P
<karolherbst>
just people shout "performance penalty" and nobody works on that
<karolherbst>
but it's a bug no matter how you look at it
<karolherbst>
even CVE worthy
<karolherbst>
just nobody cares enough
<DemiMarie>
karolherbst: time to file a CVE for that?
<karolherbst>
yep
<airlied>
karolherbst: do people store secrets in VRAM? :-)
<karolherbst>
write some nice AI, which scans for pictures with credit card info :P
<karolherbst>
and make use of allocated but not cleared VRAM to steal that
<DemiMarie>
karolherbst: exactly
<karolherbst>
should be enough for a CVE
<bnieuwenhuizen>
Kayden: shouldn't be needed but the TEST_COMMIT stuff seems brittle and slow
<karolherbst>
airlied: yeah.. your browser history :P
<DemiMarie>
If perf is the issue just add a sysctl
<karolherbst>
yeah.. or do it async
<karolherbst>
do it when the system is idle
<karolherbst>
only clear memory pages which come from other contexts... etc...
<karolherbst>
you can make that not suck
<karolherbst>
but enough hw has zero bandwidth clears
<jenatali>
That's how Windows works, memory is zeroed when coming from other processes
<DemiMarie>
karolherbst: get the CVE assigned, push out eager zeroing in the security patch, and then tell people who complain about perf regressions to do the work to fix them?
<karolherbst>
DemiMarie: sounds like a plan
<karolherbst>
worked for Intels CPU bugs :P
<karolherbst>
I guess with stuff like mdev/SR-IOV you get proper isolation, but without it I think you'll need kernel patches to fix the data leak problems
<DemiMarie>
karolherbst: I will be very happy when the CVE comes out 🙂
<karolherbst>
yeah.. after 20 years...
<karolherbst>
:D
<karolherbst>
I mean. everybody knows about that issue...
<DemiMarie>
Time for someone to just file it?
<Kayden>
bnieuwenhuizen (+airlied, mdnavare): Yeah, agreed, the TEST_ONLY strategy sounds pretty painful. I wonder if they could just add a heuristic like "You have 3 monitors, let's skip fancy modifiers" or "It failed once, let's fall back to LINEAR and give up until the monitor configuration changes"
<karolherbst>
DemiMarie: yeah.. though for high scores I think you really need to be able to extract sensitive data reliably
<karolherbst>
VRAM has _huge_ bandwidth
<Kayden>
bnieuwenhuizen: i.e. it's fine 90% of the time, and if you hit that 10% case, then sucks-to-be-you, you get slow but working mode
<karolherbst>
which makes a lot of attacks not practical
<bnieuwenhuizen>
Kayden: AFAIU one of the big issues with TEST_ONLY is that you need to do actual allocations for TEST_ONLY so the compositor can't even really test without lots of pain
<karolherbst>
can't just upload it for instance
<Kayden>
oh ouch, didn't realize that
<bnieuwenhuizen>
and yeah the brute force thing is annoying, especially since amdgpu is quite slow for commits
<bnieuwenhuizen>
for the deck we've basically hardcoded plane cases because any search means a missed frame
<karolherbst>
DemiMarie: anyway.. what I'm saying is, that the more impressive the exploit is, the simpler it will be to get it fixed asap
<Kayden>
makes sense
<Kayden>
bnieuwenhuizen: what compositor is steamdeck using anyway? I was looking at gamescope the other day but that seemed to be about XWayland
<airlied>
Kayden: the TEST_ONLY strategy should work fine
<bnieuwenhuizen>
Kayden: gamescope
<airlied>
it's not a major overhead, test only should be fast
<DemiMarie>
karolherbst: could perhaps adapt the exploit for iGPU leak
<bnieuwenhuizen>
it is a wayland compositor that only does xwayland :P
<Kayden>
ah
<airlied>
bnieuwenhuizen: is test only slow on amdgpu or just commits?
<DemiMarie>
bnieuwenhuizen: what??
<airlied>
though I understand test only needs fb allocs which is painful, I think pinchartl was asking about disabling that
<bnieuwenhuizen>
airlied: I thought both, but Josh could give you the latest
<karolherbst>
DemiMarie: not possible on iGPUs though as GPU memory is cleared
<karolherbst>
or what iGPU leak are you talking about?
<bnieuwenhuizen>
DemiMarie: ?
<DemiMarie>
there was a famous iGPU leak vuln a while back
<karolherbst>
DemiMarie: using wayland let's you fix tearing for real
<DemiMarie>
karolherbst: why did they *only* do XWayland?
<karolherbst>
games
<bnieuwenhuizen>
games need it
pcercuei has quit [Quit: dodo]
<karolherbst>
gamescope is the thing used for the steamdeck (mainly)
<bnieuwenhuizen>
and abusing X11 atoms for all the weird stuff is just too easy
<DemiMarie>
Why do no games use Wayland?
<karolherbst>
because they are old and don't get patches
<bnieuwenhuizen>
some games can use wayland, but no game requires it
<karolherbst>
newer SDL2 games might use it though
<karolherbst>
but I've seen games with bundles SDL2 with disabled wayland support
<karolherbst>
so there is that
<DemiMarie>
this is why we need standalone (no compositor support needed) rootless XWayland
<DemiMarie>
so each game can have its own X server, all jailed in a sandbox
<karolherbst>
the X part is the thing I am the least concerned about running games :P
<bnieuwenhuizen>
gamescope runs an xwayland instance per game
<DemiMarie>
bnieuwenhuizen: Oh nice
<mareko>
one area where zink should excel already is qemu
<DemiMarie>
karolherbst: even with flatpak and lockdown options turned on?
<Kayden>
that's really cool.
<karolherbst>
DemiMarie: mhhh.. that's probably good enough then
<DemiMarie>
karolherbst: only if you do not have an easy sandbox escape via X11 🙂
<DemiMarie>
hence why you want to run an X server per client
<DemiMarie>
oh, and XCB is known to be unsafe
<DemiMarie>
if the X server is not trusted
<mareko>
flatpak ships its own Mesa in the sandbox, so you can't really update it, not good for GPU vendors
<Plagman>
or users, really
<mdnavare>
airlied: bnieuwenhuizen: TEST_ONLY should only do the atomic check right , no commits so shouldnt that be fast?
<DemiMarie>
mareko: I thought flatpak was part of the (separately updatable) runtime
<karolherbst>
DemiMarie: trash the X server :P
<bnieuwenhuizen>
mdnavare: "should" vs. "is"
<mdnavare>
airlied: or can mutter do something similar to what we do for link BW in the driver, where we start with highest link rate/lane count and if it fails redo modeset with lower, cant we do that for modifiers in Mutter, start with highest and then keep going down?
<airlied>
mdnavare: that's what TEST_ONLY is meant for
<airlied>
it should start and works it way down until the driver says it will work
<karolherbst>
mareko: well... if that's the case that's very sad, but flatpak can make use of system provded libs
<karolherbst>
yeah and what DemiMarie said
<DemiMarie>
karolherbst: X sucks, yeah, but I want something that I can use for legacy compat without having to implement XWayland support in my compositor
<karolherbst>
flatpaks don't contain all the deps in one image
<mdnavare>
airlied: okay great! If we send this MR for this approach would that get accepted?
<karolherbst>
DemiMarie: I am sure you want to use Xwayland
<airlied>
mdnavare: not sure, but probably worth a try, jadahl is the mutter maintainer
<karolherbst>
supporting XWayland isn't that painful afaik
<DemiMarie>
karolherbst: the problem arises when one is a rootless Wayland compositor backed by another Wayland compositor
<DemiMarie>
or when one wants to support sandboxed X11 applications
<mdnavare>
airlied: Yes saw his comments in your MR as well. And my understanding on this is correct right where with test only it should be able to reject only at the end of atomic check, no need to write anything in commit phase yet, so technically shouldnt miss a frame
<karolherbst>
like e.g. a fake game scanning your vram periodically to steal credit card info
<DemiMarie>
does doing it from a sandboxed flatpak and uploading the data count?
<karolherbst>
the key is: getting sensitive data reliably
<mdnavare>
Kayden: So nopw iwth this MR, glmark2 can use modifiers but for a fullscreen composited image that will still be rendered on linear surface right so would this fix our perf issue?
<karolherbst>
what good does reading out VRAM do you
<karolherbst>
GPUs have x GB of VRAM
<karolherbst>
and 100s of GB/s of bandwidth
<karolherbst>
you can't upload/scan the data quick enough to extract data
<karolherbst>
can't do it by hand either, because it's a massive amount of data
<karolherbst>
also 100% upload is noticable immediately
<karolherbst>
sure this attack is possible and everything, but you won't get far