01:02chillfan: Is the nouveau driver potentially vulnerable to this https://nvidia.custhelp.com/app/answers/detail/a_id/4738?
01:06karolherbst: we don't support those counters I think
01:08chillfan: Ah, so if you don't have a similar thing.. then no side channel issue I guess
01:09karolherbst: well, that is a pretty minor issue overall though
01:10karolherbst: it's something you could exploit if you want to attack a specific person, but you can't really use it for maleware
01:19chillfan: So I guess this is a hardware issue, and nvidias blurb there is just software mitigation
01:24chillfan: Ah thanks. Just making sure, we have hw vulns regularly now month and vendors are very slow to do anything.
01:25karolherbst: it won't stop
01:28chillfan: I'm not a hardware hacker but I think you're right based just on the trend that hw researchers are now looking very hard at chips
01:29gnarface: a decade late, but better late than never i guess
01:29chillfan: But I'm happy they do, and find the issues.. even if a fix is slow
01:29gnarface: i predicted spectre/meltdown the very same day Intel dropped their press release about the speculative execution feature.
01:30gnarface: if i can see that coming, then people in charge of making this hardware are doing it on purpose
01:30chillfan: How do you mean by predicted?
01:30joepublic: 'pre' = before 'dict' = say
01:31chillfan: I mean, were the trouble signs or you've just always suspected things with these chips?
01:31joepublic: therefore "say beforehand"
01:31gnarface: chillfan: i mean i read the press release and it sounded completely insecure even from the marketing blurb description.
01:31gnarface: chillfan: then i announced my fears to everyone i knew that would listen
01:32gnarface: i furthermore advised nobody buy ANY those chips for anything directly attached to the internet
01:33gnarface: and i followed through on that, for my own part (nobody i told about it even took me serious enough to remember my warning years later when it came true, but i'm used to that - it fits a larger pattern of events throughout my life)
01:33chillfan: It's odd but when the TLS 1.3 draft was being finalized.. I looked at this 0RTT thing and thought "this sounds very unsafe".. now it seems a few people are warning against it as a way of tracking users. If a crypto dummy like myself can figure that.. so I think I see how you mean
01:34gnarface: i think you do see how i mean
01:35gnarface: something similar happened around that big SSL vulnerability (heartbleed?)
01:35gnarface: at the time i was being tasked at work to backport it to a debian squeeze system
01:35gnarface: i did some benchmarks and was told to report
01:35gnarface: i reported "this is so much faster i can't imagine it's secure"
01:35gnarface: "i advise we do not roll this update out"
01:35gnarface: they didn't listen
01:35gnarface: but they were out of business before hearbleed even hit the market so it didn't matter
01:36gnarface: but once again, my vindication went unnoticed into the nether
01:36chillfan: hah, yeah sometimes the trends tell you when to be spooked I suppose. I got away from Windows permanently just as Code Red took over 1/3 of all computers :)
01:37chillfan: Not that it made a difference, I was reformatting every day at that point
01:37chillfan: One less headache though
01:40chillfan: My current instincts based on hw vulns.. run from x86 as fast as I can. Also to not use proprietary bios at all, even if I downgrade.
01:41chillfan: I suppose that's well justified with a vuln per month though
01:52chillfan: I suspect something will happen anyway, more than just some paper and a delayed patch
01:54karolherbst: chillfan: other archs aren't better
01:54karolherbst: it just needs somebody to look hard enough
01:56gnarface: i, too, wonder if there's too much trust being placed in the "ARM Trusted Firmware"
01:57gnarface: so far i'm hopeful though that at least stuff not made by broadcom is secure (the stuff made by broadcom definitely isn't)
01:57imirkin: chillfan: if you're earnestly concerned about security, i wouldn't necessarily recommend leaving nouveau loaded
01:58imirkin: at the very least, it's _really_ easy to DoS
01:58chillfan: Well another arch or a librebooted machine to replace the one I have. Yeah, maybe someone just needs to dig more for ARM. I would tend to think it's a "safer" bet because it's simpler though
01:58chillfan: which it might not be at all
01:58karolherbst: simplier doens't mean more secure
01:58karolherbst: the contrary is the case most of the time
01:59karolherbst: writing code in a secure way makes the code more complicated
01:59karolherbst: especially if you mitigate timing attacks
01:59karolherbst: because 1. you need to build a path table 2. you have to write code in a way that each path is always taken 3. you have to select the correct result from the correct path
01:59karolherbst: no way this is gonna be less complicated than the insecure code
02:00chillfan: Well, I would probably just do Power9 Talos II.. but it's very expensive for entire rebuild (required due to form factor for me)
02:01karolherbst: and nobody looked in how secure it is
02:01karolherbst: you can be sure about the security about a system if it was out for 20 years without anybody finding a bug
02:01karolherbst: then you can be fairly sure it's not the most insecure system out there
02:02karolherbst: wouldn't be surprised if th talos II is even less secure than x86
02:02karolherbst: at that point, nobody knows
02:02karolherbst: we don't even know how other CPUs compare to intel/AMDs
02:02karolherbst: we simply know that intel CPUs have major design issues
02:02chillfan: I can't know either way, so I would go with what "seems" right to me, at least not to stay with known very bad chip like I have now
02:02karolherbst: and AMDs less for the same features
02:03gnarface: powerpc advocates had long told me that the chips were more inherently secure than Intel's equivalent offerings. i'm lead to believe this is a huge justification behind the choice for the Talos II
02:03karolherbst: gnarface: he is lying
02:03karolherbst: how to figure out somebody lies about securite: he says what is more secure
02:03karolherbst: that's a statement you simply can't make
02:03gnarface: karolherbst: the person who told me that was definitely blowing smoke out his ass but my point is just that it may be a common opinion
02:04karolherbst: point is, nobody knows
02:04chillfan: imirkin: I'll keep that in mind
02:04joepublic: talos power9, 4 threads per core. do they leak to each other? Dunno
02:04karolherbst: any kind of comparison about the security between two systems is most of the time pure bs
02:05gnarface: another part of the justification for the talosII i thought was that they were building something only through vendors willing to cough up the firmware code3
02:05chillfan: idk.. they have blobless spectre v2 fix I think
02:05chillfan: well since they are blobless
02:05chillfan: in that space anyway
02:05karolherbst: well, now researchers are looking into cross thread/core vulns
02:06karolherbst: and speculative execution
02:06karolherbst: we had some cache vulns in the past
02:06chillfan: yeah, it seems like the fix is don't run SMT/HT
02:06karolherbst: you can do that within the same application
02:06karolherbst: not always
02:07chillfan: unless.. you apply kernel fix that hoses performance
02:07karolherbst: like for web browser you wouldn't
02:07karolherbst: or virtual machines
02:07joepublic: KVM on my workstation yells at me if I spin up a VM with hyperthreading turned on
02:07karolherbst: but for games?
02:07karolherbst: who cares
02:07karolherbst: joepublic: what we want is a way to tell the scheduler when a process takes up two threads and when only one
02:07karolherbst: but... well
02:07karolherbst: that's work
02:08joepublic: and, as you mentioned, adds a little complexity
02:08karolherbst: and might even cost perf in the end
02:08joepublic: but if leak-patching compound makes my boat a little heavier, I will still apply it so I don't sink.
02:09karolherbst: well, we still have a quite bad sec vuln in the graphics space anyway
02:09karolherbst: graphics driver don't clean used memory
02:09chillfan: Yeah, I will patch what I can because I'd rather lose a little performance that I don't need than perform better and be unsafe
02:09karolherbst: and the next application can just read it out
02:10karolherbst: doesn't apply to GPUs using system RAM though
02:10karolherbst: if you look hard enough, you'll find some vulns everywehere
02:10chillfan: just regular kernel vuln?
02:10karolherbst: well yeah
02:10chillfan: ah ok, so just wait for the fix :p
02:11karolherbst: the issue is known for years
02:11karolherbst: maybe 10?
02:11karolherbst: vendors won't fix it, because it costs too much perf
02:11karolherbst: and because nobody cares, nothing happens
02:12karolherbst: there is some SDL sample code where you can literally dump the memory and even recognize textures
02:12karolherbst: or even frames
02:12karolherbst: somebody showed it could be used to dump browser tabs
02:12karolherbst: there are some random corruption in the date
02:12karolherbst: but I am sure you could make text readable
02:12karolherbst: anyway, it's super hard to actually exploit that
02:13karolherbst: what do you do with all the image data?
02:13karolherbst: do you want to upload gigs of image data?
02:13karolherbst: or run some KI on the infected system to scan whatever is in there
02:13karolherbst: just in the off chance you find important stuff?
02:13karolherbst: how do you detect credentials that way
02:13chillfan: so a slight good news on that then
02:14karolherbst: doesn't help you if you are a high profile target
02:14karolherbst: and the attacker doesn't care about the costs
02:15karolherbst: chillfan: but now you start to mix vulns
02:15karolherbst: and use that perf counter one to detect some interesting stuff the user is doing
02:15karolherbst: and only upload data from a few seconds
02:22chillfan: Well, everything can break somehow.. maybe if something happened with memory safe languages, but I dunno.. I'm not a hacker
02:26chillfan: "break less" probably heh
02:37chillfan: ok ttg, later :)
05:11pmoreau: karolherbst: Got everything cloned thanks to the conference WiFi; I was downloading at ~10KiB/s at the hotel, so I’m not sure it would have finished before I went home.
05:11pmoreau: Compilation is under way.
12:48karolherbst: nice, my mt fixes even work under webengine :)
12:51karolherbst: imirkin: so uhm... we might want to take about my mt fix approach a bit more. It seems to fix the issues and I don't see anything wrong with the seperate timeline thing. The patches fix all of the crashes and I wasn't able to trigger any of those mt crashes since.
14:18imirkin: karolherbst: sure it works. lots of things work. uninstall nouveau also works. we've avoided having this type of suboptimal solution up until now, and i see no pressing reason to start.
14:19karolherbst: and why do you think it is suboptimal?
14:23imirkin: because it uses multiple clients
14:24karolherbst: and why is that bad?
14:24imirkin: it's the same conversation over and over and over and over and over again
14:29karolherbst: afaik you didn't explain why you think using multiple clients is bad or maybe I simply missed that, but couldn't find anything in my local logs. What I can deduce is that you might think that a client has its own vm, but I don't know if that's even true
14:35imirkin: so ... one of the reasons that people use multiple contexts
14:35imirkin: is to that in context 1 they draw; draw; draw
14:35imirkin: (and therefore thread 1)
14:36imirkin: and in thread 2, they upload; upload; upload
14:36imirkin: (and thus context 2)
14:36imirkin: that way, the uploads don't block the cpu of the drawing thread
14:36imirkin: which is nice.
14:37imirkin: however, that means that the uploads will go through client 2
14:37imirkin: and draws will go through client 1
14:37imirkin: that means a full hw context for ... basically no reason
14:37karolherbst: but they work on the same channel
14:39imirkin: you're not creating separate channels?
14:39imirkin: then i've managed to confuse myself with terminology
14:39imirkin: remind me what a channel is, and what a client is?
14:40imirkin: a channel is an hw context, right?
14:40imirkin: and a client is a vm?
14:40imirkin: i gtg, but post a link to your patches anyways
14:40imirkin: i might have time to look tonight
14:41karolherbst: channel == hw context, client is just some userspace wrapper around the kernel API afaik.
14:41imirkin: ok, well i don't give a shit how many userspace wrappers we use -- could be 100
14:41imirkin: i just want to only have 1 hw context per screen
14:41karolherbst: yeah, that's what I have
14:41imirkin: ok awesome
14:41imirkin: then post the patches
14:41imirkin: send a link
14:41imirkin: it'll be easier anyways
14:42imirkin: see ya
14:42HdkR: Another usage of multiple contexts is drawing in one and presenting in another
14:42HdkR: VR makes heavy use of that from what I hear
14:44karolherbst: HdkR: ;) right, but that's not the point here
14:44karolherbst: we don't want to bother with context switches
14:49HdkR: It's one of the best use cases I've seen for multiple contexts, though using a second context for uploads seems like a really good one
21:07karolherbst: HdkR: do you have some list of applications using multiple contexts?
21:08HdkR: karolherbst: Sadly I don't have a list
21:08HdkR: I only know a handful and only 1 runs on !Android :P
21:08karolherbst: HdkR: I mean, I am sure that you personally don't have a list, but I was wondering if you would be able to organize something like that? shouldn't contain any secrets ;)
21:08HdkR: Which is Dolphin
21:08karolherbst: yeah, sure, dolphin
21:09karolherbst: I also know of chromium/qtwebengine and warsow
21:09karolherbst: and of course any video player using vdpau and opengl
21:09HdkR: I might be able to? I've never looked :P
21:09karolherbst: I just posted my patches and would like nvc0 users to test them a bit
21:10karolherbst: HdkR: would be cool. I would avoid going the official channels here as this will just take months or nothing happens at all
21:10karolherbst: even simple gl samples would be fine
21:11karolherbst: I tried asking in #dri-devel a few times, but nothing really came up there
21:11HdkR: I'll ping around to see if I can find any
21:11karolherbst: awesome, thanks!
21:11HdkR: I'm trying to get Yuzu to use multiple contexts as well but they keep saying they don't know how
21:12karolherbst: only for shader compilation or even more stuff? :p
21:20HdkR: more stuff
21:20HdkR: Considering the architecture of the Switch, it is easy to see games doing GPU things from multiple threads
21:26karolherbst: how is yuzu doing anyway? already hitting ugly to solve issues?
21:28HdkR: There was some discussion about how to solve wave shuffling on !Nvidia architectures when there aren't any guarantees that they warp will directly match screen space coordinates
21:28HdkR: match across the architectures I mean
21:29HdkR: There is at least one game that is using them and the game black screens on their current no-op implementation
21:30karolherbst: I see
21:31HdkR: I'm assuming the game is using them to upscale in some weird bandwidth preserving way
21:31HdkR: It's quirky, I like it
21:32karolherbst: HdkR: all those "this should be next gen"-games will be super tricky to emulate
21:55karolherbst: allthough, none of those will be on the switch sadly :/ the tegra just hasn't that much power I figure
22:03HdkR: Doom 2016 is on it and... wolfenstein 2?
22:04HdkR: The people attempting to push "next-gen" games to it would still be optimized as much as physically possible and wreck havok :P
22:05HdkR: Which apparently that Wolfenstein game just got an update on PC to take advantage of Turing's VRS feature
22:06karolherbst: but I mean, wolfenstein 2 doesn't look as nice on the switch, right?
22:06HdkR: Yea, they cut back on a ton of features
22:08loonycyborg: lol doom and wolfenstein are two original fps games to spawn the entire genre
22:08karolherbst: I heard that RDR2 on the PS4 looks like a PS5 game ;)
22:09loonycyborg: you mentioning those distant sequels made it look like entire fps genre is in midlife crisis :P
22:09HdkR: I've not seen a PS5 game so I can't confirm truth there
22:09karolherbst: you know what I mean
22:09loonycyborg: or maybe jumping the shark
22:09karolherbst: sometimes game engines are just crap and waste tons of resources
22:09karolherbst: and sometimes dev care
22:10HdkR: Game studios are getting really really good at PBR and baking tons of state :D
22:13karolherbst: well, whatever works ;)
22:15HdkR: Should I shill ray tracing as a "it just works" solution? :P
22:15HdkR: I think that was a quote from somewhere about it
22:31karolherbst: it's just super slow :p
22:33HdkR: Or the stack is too green. Did you see the benchmarks today showing dumb amount of performance improvements with an updated client and driver? :P
22:34HdkR: https://www.guru3d.com/news-story/december-4-battlefield-v-raytracing-dxr-performance-patch-released-(benchmarks).html Dumb amount of performance change
22:39HdkR: Of course doesn't really matter. Nouveau needs to get even basic hardware support going first...