04:52 imirkin: skeggsb: did you end up trying higher res on the quadro 600?
05:01 skeggsb: imirkin: no, but i'll have it plugged in again later today
05:19 imirkin: tagr: random guess for the 406040 issue - https://hastebin.com/uhuwojebat.swift
05:20 imirkin: [probably has to be restricted on nv50+]
13:59 karolherbst: imirkin: can we somehow make the buffer locations non deterministic?
14:00 RSpliet: karolherbst: without knowledge of the matter, virtual or physical addresses?
14:01 karolherbst: so that if I run two applications, that the second one doesn't get the same data when reading out the buffer
14:01 karolherbst: well
14:01 karolherbst: the data from the first application that is
14:03 RSpliet: karolherbst: if I understand correctly, per-"hw context" page tables should let you avoid just this. The physical memory of app 1 should not be mapped in the virtual address range of app 2, hence it can't access that data
14:03 karolherbst: it isn't about running applications at the same time
14:03 karolherbst: but after each other
14:04 karolherbst: thing is, I get the same virtual address each run, and apperantly even the same physical one
14:04 RSpliet: yeah, you're interested in higher randomisation of physical memory allocation from the sound of it. I think mupuf talked about this years ago
14:05 karolherbst: well, it seems like we have no randomisation at all
14:06 RSpliet: Well... nothing deliberate at least. "Chaos theory" applies to allocations too though, if other apps jump in the middle and start chipping off small sections of that frame buffer, then obviously app 2 will not get the whole buffer. There's insufficient chaos to hide this though :-D
14:07 RSpliet: I suspect this would require changes to the kernel allocator, which is a fairly simple allocator iirc. Nothing impossible. Randomisation could lead to fragmentation though, esp. if we need to worry about contiguous allocation (which sometimes we do... like for big pages etc.)
14:09 karolherbst: RSpliet: randomisation doesn't really lead to higher fragmentation when done correctly
14:10 karolherbst: well
14:10 karolherbst: you have to keep alignment in mind anyway
14:10 karolherbst: and sure, the real problem is, that usually for graphics we never clean the VRAM anyway
14:10 karolherbst: so randomisation would be just a dirty hack to not deal with the perf penalty
14:11 karolherbst: we have to clear the VRAM anyway
14:11 karolherbst: we are just good in ignoring this issue
14:11 karolherbst: or at least we should clear out CL buffers
14:11 RSpliet: fragmentation is a concern that should be addressed in your proposal for higher randomisation ;-). I always keep repeating to my students "just that you know there are solutions doesn't mean it's not a problem!", so sorry if I sound a bit teacher-preacher :-P
14:14 RSpliet: You could perhaps short-cut it a little bit and omit clearing buffers free'd and re-allocated by the same context. Perhaps some user-space buffer caching kind of thing like I think glibc's malloc does to mitigate overhead of frequent free's and mallocs().... but we may or may not be walking into GEM territory now (I don't know the hierarchy well enough)
14:14 karolherbst: mhh
14:14 karolherbst: we have to clear at free time
14:14 karolherbst: we can't omit any free
14:15 karolherbst: it works well as long as you expect an application to exit in a sane way
14:15 karolherbst: but thing about hard resets and vram not being cleared
14:15 karolherbst: when do you clear the VRAM?
14:16 RSpliet: We can debate about that (I recall a perf impact of like 10% if buffers are cleared on free), but a free in a user application does not necessarily have to lead to a free in the kernel. You could keep some of it it lingering around in a pool of re-allocatable memory until the kernel signals VRAM shortage.
14:18 karolherbst: RSpliet: well we can free it asnyc
14:18 karolherbst: *async
14:18 karolherbst: we just make the memory unavailable until it was cleared
14:18 karolherbst: and we have a kworker doing that for uns
14:18 karolherbst: or something
14:19 RSpliet: It still eats away from DRAM bandwidth as DRAM channels have a serialising effect.
14:19 karolherbst: no idea if we have nice GPU commands to do big clears in one command/step or something
14:20 RSpliet: There's a flag used for fast-clears. Think that's only useful to defer, not to do it ahead of time. as soon as the buffer is written you'll end up emitting those clears to DRAM anyway.
14:49 Masterboy: imirkin: i tested all the clips on http://www.h264info.com/clips.html with no problem - the simpsons trailer was fine only the 2k video was lagging because it is 2k. nv84 nouveau+hw decode + mpv from mpv ppa working fine.
14:50 imirkin_: if the 720p one worked fine, you must not be using hw decode via vdpau.
14:50 Masterboy: imirkin_: the problem you had got from the clips was solved somewhere it seems.
14:51 Masterboy: imirkin_: did you try loading the video with mpv? with mpv it was fine.
14:51 Masterboy: nv84 decoded it fine o ubuntu 16.04 lts
14:52 Masterboy: mhm mhm... i don't think mpv has a fallback mechanism...
14:53 Masterboy: to software decode
14:54 imirkin_: so it's not the whoel clip that's messed up
14:54 imirkin_: but just parts of it
14:54 Masterboy: oh, i see, i just saw that it loads and plays, i did not watch it all...
14:54 imirkin_: like when the dog sleigh is jumping over the gorge
14:55 imirkin_: and some other panning scenes
14:55 Masterboy: shoot, ok, i have to test again...
18:33 mupuf: karolherbst: you mean sanitizing the VRAM pages
18:34 karolherbst: mupuf: so that they contain random data after free, yes
18:34 karolherbst: or 0 or whatever
18:34 mupuf: 0, yes
18:34 mupuf: https://lwn.net/Articles/517624/
18:34 karolherbst: mupuf: is there some GPU command we could use for that?
18:34 mupuf: pcopy?
18:36 karolherbst: yeah, but I meant more like a fill command or something
18:36 karolherbst: it isn't really a copy of data
18:36 karolherbst: but I guess pcopy may be able to overwrite a chunk of memory with the same value?
18:37 karolherbst: mupuf: "On the other hand, if we want all buffers to be wiped at allocation time," no, we don't want that :p
18:37 mupuf: karolherbst: I was thinking of keeping a zeroed-out memory page
18:37 mupuf: and repeat that
18:37 karolherbst: mhh
18:37 karolherbst: I kind of wish there is a simplier thing
18:38 mupuf: you wish there would be a memset command
18:38 mupuf: maybe pcopy has one
18:38 karolherbst: how is that done on normal x86 memory for example?
18:38 mupuf: copy-on write
18:38 karolherbst: I meant on boot time or whatever
18:38 mupuf: the memory is not reset, AFAIR
18:38 karolherbst: mhhhh
18:39 karolherbst: but I guess the hw kind of protects against access?
18:39 mupuf: no
18:39 karolherbst: uhh
18:39 karolherbst: so it is all inside the kernel
18:39 karolherbst: I mean, I always have that most insane attack in mind: force reboot into customly crafted kernel
18:40 karolherbst: and you kind of want to be protected against even that scenario
18:40 mupuf: malloc does not zero out the allocated memory, only calloc does. However, not sure what happens when a page is migrated from one process to another
18:40 karolherbst: mhhh
18:40 mupuf: kernels can do whatever they want
18:40 karolherbst: right
18:40 mupuf: but userspace, that's what you want to protect
18:41 karolherbst: well, you still have that scenario of booting into a different OS with a different kernel
18:41 karolherbst: I just don't know how important it is to be protected against that as well
18:41 opal: well you "want to protect" the kernel too but in a different fashion
18:42 mupuf: karolherbst: honeslty, the only issue I see is the attack I mentioned in the presentation
18:42 mupuf: allocating a lot of memory, then reading it
18:42 opal: secure boot + efi stub + full-disk encryption is probably the best current way to protect a system from head to toe, software wise
18:42 mupuf: there was "an attack" published for that
18:42 karolherbst: I mean, what happens if for example boot linux, do all my important stuff there, email encryption stuff, whatever, then boot into a different OS, because I am smart not to trust that one with my important data, and it may be just possible to extract stuff from there due to kernel bugs inside windows or whatever
18:43 karolherbst: mupuf: yeah
18:43 mupuf: opal: it does not prevent this. Only encrypting memory could
18:43 opal: i've looked into encrypting memory lol, would be interesting but unfeasible
18:43 karolherbst: opal: secure boot only protects against unauthoritative kernels
18:43 mupuf: karolherbst: yes, see my answer to opal
18:43 karolherbst: opal: not against kernel modifications
18:44 karolherbst: if you are authorized to create a kernel passing secure boot, you can just do that for other machines as well, because they usually share the same public key ;)
18:44 mupuf: just make sure each kernel has the encryption key in its binary
18:44 karolherbst: you just drastically limit the group of people able to modify your kernel
18:44 opal: i wasnt keeping up honestly, was this the original question: 13:59.36 < karolherbst:#nouveau> imirkin: can we somehow make the buffer locations non deterministic?
18:45 opal: also yes that's true
18:45 mupuf: opal: that part is odd. Non-deterministic is not what karolherbst wants. He wants to sanitize memory pages before handing them out to applications
18:46 opal: gotcha
18:46 mupuf: so as no confidential information could leak from one process to another
18:46 karolherbst: yeah
18:46 opal: i believe grsecurity has offered this?
18:46 karolherbst: not leaking information is my main concern overall
18:46 mupuf: then he started musing about kernels, but this is impossible to fix without HW encryption
18:46 opal: shame grsecurity is unavailable to the public now
18:46 karolherbst: but... my main issue was, that when fixing up data, tests start to pass allthough they didn't before :p
18:46 mupuf: (of the memory)
18:47 karolherbst: opal: or not... depends on how you look at it
18:47 mupuf: karolherbst: hmm, fixing data?
18:47 karolherbst: mupuf: well, run some other test to verify something and you accidentally put the value into memory the test expects
18:47 karolherbst: and suddenly it passes ;)
18:47 mupuf: oh, of course!
18:47 mupuf: yeah, it is always a risk
18:47 opal: karolherbst: or not what? not a shame? ...that's only if you get into politics
18:47 opal: politics shouldnt be a factor in security and sadly it has been made a factor
18:47 mupuf: well, you can do something about this already in mesa
18:48 karolherbst: mupuf: yeah, hence why getting random buffer addresses
18:48 karolherbst: or something
18:48 mupuf: karolherbst: that only limits the risk
18:48 karolherbst: good enough
18:48 mupuf: so you think :D
18:48 karolherbst: :D
18:49 karolherbst: opal: well, it is questionable if grsecurity is effective. I don't think there were trustworthy studies for that
18:49 mupuf: and what you propose is basically to only reuse a memory page when no zeroed-out ones are available
18:49 mupuf: you'll run out of them before piglit is done executing :p
18:49 karolherbst: opal: and maybe you just feel safer using grsecurity because it has security in its name or something and care less about other issues...
18:49 karolherbst: the entire security business sounds like a lot of placebo and snake oil to me in general
18:50 karolherbst: spending more on marketing than on developing software and so on...
18:50 opal: well a primary aim for grsec was preventative security, stopping bugs borne from code before they had a chance to cause issues
18:50 karolherbst: right, but does it work?
18:50 karolherbst: does it lead to systems running more secure or less?
18:51 karolherbst: maybe you fix bugs later, because gsecurity protects you?
18:51 opal: you tell me, does ASLR work? do stack canaries work? does zeroing memory work?
18:51 karolherbst: or don't detect bugs at all?
18:51 opal: when a bug is encountered the system will most likely crash rather than be exploited
18:51 opal: grsec's useful if you value security over uptime
18:51 karolherbst: yeah, which is good
18:51 karolherbst: well
18:51 karolherbst: it isn't like that linux has nothing and gsecurity has everything
18:51 RSpliet: funny enough, I wouldn't be surprised if ASLR reveals bugs rather than prevents due to more random behaviour :-D
18:51 opal: if you value protecting assets over serving users
18:52 opal: linux has some stuff
18:52 opal: but linus himself has admitted that security is not a primary focus for linux
18:52 karolherbst: opal: who is saying that gsecurityies things on top of linux are really helping?
18:52 opal: security bugs are just like any other bug
18:52 karolherbst: opal: that's a bit short sighted, his point was a different one
18:52 karolherbst: opal: and they are
18:53 karolherbst: for many reasons
18:53 karolherbst: you just don't know if you can exploit a bug security wise or not
18:53 opal: no i know his point, it was that security "experts" hunt bugs down and make huge publicity deals out of them
18:53 karolherbst: you can't say for any random bug to 100% confidence: nope, not relevant to security
18:53 opal: yes
18:53 karolherbst: so you should get all bug fixes, not just "security" ones
18:54 karolherbst: opal: ohh yeah, that as well...
18:54 karolherbst: I mean, sure some bugs are super big and lead to a lot of security issues, and thats good to inform people
18:54 opal: yeah linus hates the security bloggers lol
18:54 opal: yeah
18:54 karolherbst: well
18:55 karolherbst: well...
18:55 opal: yeah security isn't black and white, i'm sure of that
18:55 opal: you have to address your personal risk model
18:55 opal: while grsec may not be useful to you personally, some find value from preemptive protection, and yes, others probably see "security" in the name lol
18:56 karolherbst: opal: well, that's not what I mean
18:56 karolherbst: I am just questioning if gsecuritys additional things really help
18:56 karolherbst: maybe they do, maybe they don't
18:56 karolherbst: linux also has quite a lot of features to find bugs faster and so on
18:58 opal: well i alluded to this earlier: this isn't directly related to grsec but to code in general, would you compile a critical program with PIC, ASLR, SECCOMP/pledge(), and whatever else is available if given the opportunity?
18:58 opal: some programmers decide to take this route
18:58 opal: tor comes to mind, it's known for high focus on privacy and security
18:58 opal: web browsers too
18:59 opal: web browsers are untrusted code sandboxes at this poihnt
18:59 RSpliet: karolherbst: IMHO, the higher level point is that grsec doesn't quite play the open source game neatly. That's part of their business model. But I would simply claim that the lack of independent scrutineering on grsec patches make their code a higher risk rather than lower.
18:59 karolherbst: but we do with any random linux distribution already so far
18:59 karolherbst: RSpliet: right
18:59 karolherbst: exactly one of the bigger issues with grsec
18:59 opal: personally i'd dig a microkernel model but none of the microkernels in development are getting too far
19:00 opal: RSpliet: that could definitely be true, and now we don't know for current patches since the code is paywalled
19:00 opal: which is a shitty decision but oh well
19:00 karolherbst: well, one can buy it and share it...
19:00 RSpliet: opal: just microkernel, or capability-based kernel?
19:00 opal: yeah and lose the licence lol
19:00 opal: and then it would be paywalled again
19:00 karolherbst: opal: well
19:01 opal: RSpliet: give me a second; i never really made a distinction
19:01 karolherbst: opal: you don't have to do it personally
19:01 RSpliet: opal: sounds like a violation of the GPL license of the Linux kernel...
19:01 karolherbst: RSpliet: it isn't
19:01 opal: RSpliet: yeah it isnt lol the gpl allows it
19:01 karolherbst: because you can still share what you got
19:01 karolherbst: you just don't get updates or newer versions
19:01 opal: grsecurity says you can share the code, but you just wont get updates if you do
19:01 opal: yep
19:01 karolherbst: I am sure they can just stop doing business with you
19:01 karolherbst: _but_
19:01 karolherbst: you could also just post it via tor or something
19:02 karolherbst: pastebin it
19:02 opal: but you havent considered that spender could simply run his patchset through a script to search-and-replace variables or function names
19:02 karolherbst: yeah
19:02 opal: which is entirely possible now since we don't know what's being done with the code
19:02 RSpliet: watermarking you mean? yep...
19:02 karolherbst: mhh
19:03 RSpliet: Yet another reason why I personally wouldn't want to trade with the grsec guys ;-)
19:03 karolherbst: opal: get access twice
19:03 opal: to counter that you could just run the patch through a "beautifier" and try reversing any fingerprinting techniques
19:03 karolherbst: opal: compare
19:03 opal: yeah that would be a good metric if it didn't cost so much lol
19:04 karolherbst: mhh
19:04 karolherbst: opal: did you click the Papers link on theyr website?
19:04 karolherbst: :D
19:04 karolherbst: *their
19:04 RSpliet: Anyway, not interested. I bet a lot of the grsec patches are practical implementations of academic ideas. Much more productive to try and properly upstream these ideas the Linux way rather than trying to upstream the grsec-shoehorned-it-compiles-ship-it patches...
19:04 opal: i think i read through a couple, cant remember
19:05 karolherbst: opal: well, ;)
19:05 karolherbst: those aren't papers
19:05 opal: lol
19:05 karolherbst: just some slides to some presentations
19:05 RSpliet: I'm exaggerating obviously, but people attempting to port grsec patches upstream naively always run into a wall of gatekeepers who raise serious issues with the quality of the code
19:06 opal: main complaint seems to be that the patch isnt segmented into smaller patches. i'm sure they have other nitpicks
19:06 karolherbst: RSpliet: I am not surprised
19:06 karolherbst: opal: well coorperate software development usually is shit
19:07 karolherbst: I mean the process
19:07 opal: yes
19:07 RSpliet: opal: valid complaint, because it prevents stage two of code review (more in-depth ;-))
19:07 opal: i believe spender's counterreasoning was "the grsec features are designed to work together"
19:07 opal: so he was just stubborn on that front
19:08 karolherbst: well, that's part of the spending more money on marketing than development thing I talked about, no?
19:08 opal: so looking at capability-based kernels it seems like this isn't exclusive from microkernels; you can have both
19:08 karolherbst: rather writing bs PR answers than thinking about how to do it correctly
19:09 opal: i'm interested in microkernels for, yes, it does have the opportunity to provide security by sandboxing, but it also gives way to more modular, interchangable code and possibly better standardised API/IPC
19:10 karolherbst: opal: well, practically at some point you always run into perf issues usually
19:10 karolherbst: that's one of the main reasons why even with modern micro kernels, you usually fall back to a hybrid form and still have some drivers in kernel sapce
19:10 karolherbst: *space
19:10 karolherbst: usually graphics
19:11 opal: context switching is indeed an issue even with monokernels
19:11 karolherbst: or networking
19:11 karolherbst: opal: well, it is more than that
19:11 karolherbst: if you do IPC, you get a round trip through the kernel
19:11 opal: im sure but it's one issue
19:11 karolherbst: and then your driver process gets tons of new syscalls
19:12 karolherbst: I mean, the issue isn't context switching really, it's just that you need to do quite a lot more
19:12 opal: yeah
19:12 opal: https://www.kernel.org/doc/ols/2007/ols2007v1-pages-251-262.pdf found this
19:14 opal: oh related question to nouveau: has support improved a lot since 4.9.7x? i'm using 4.14.8 now
19:14 imirkin_: depends on your hw
19:14 opal: had vsync issues before and im not noticing them now but maybe it's because i haven't done anything too intensive since then
19:14 opal: card im using isNVIDIA GeForce GT 730
19:15 imirkin_: you should now be able to reclock reliably
19:15 imirkin_: iirc it was still a bit flaky in 4.9
19:15 opal: bought this desktop before knowing anything about linux gpu support lol
19:15 imirkin_: yeah, just use the onboard gpu if possible
19:16 opal: isn't possible for me since i do use linux for some gaming, mainly under emulator
19:16 imirkin_: on a gt 730?
19:16 opal: works well enough for me
19:16 imirkin_: gt730 should be about as powerful as a skylake gpu...
19:16 imirkin_: maybe a tad more
19:17 imirkin_: i guess depends on if you have ddr3 or gddr5 vram
19:17 opal: i just know i used onboard on my laptop for pcsx2 and performance suffered from graphics. might be a different story with my desktop cpu but i havent bothered to try
19:17 opal: i already set this up and got it working so i dont really want to break it lol
19:19 imirkin_: using blob?
19:19 opal: just nouveau, no nvidia blob
19:20 opal: i might give onboard a try if i experience vsync issues again
19:21 opal: then i can use the card with qemu + passthrough if i need to
19:21 opal: i'll see how it goes
19:23 imirkin_: you might also give reclocking a try if you want maor fps
19:23 opal: alright i'll look into that if i need to, thanks
19:24 imirkin_: should probably be about 2x fps on your board? dunno
21:14 imirkin_: pendingchaos: brian landed the conservative rast series :)
21:14 HdkR: \o/
21:14 pendingchaos: yup
21:16 pendingchaos: you might want to update the card on the trello, now that the GM20x-GP10x extensions are implemented
21:16 imirkin_: can i just add you to the trello board?
21:16 imirkin_: do you have a trello username?
21:17 pendingchaos: I'm creating an account now
21:18 imirkin_: i've sent you an invite to the board.
21:18 pendingchaos: trello allows you to invite people before they've created an account?
21:18 imirkin_: ya
21:18 imirkin_: (i've also archived that card)