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