[00:08] <sbeattie> bryceh, cnd, and mlankhorst: I published bryceh's revert of the 10.2 and 10.3 through precise-security
[00:10] <bryceh> thanks sbeattie 
[00:14] <bryceh> sbeattie, hmm I just got a reject message back on 10.6
[00:20] <bryceh> sbeattie, guessing it's because it went through -security so the -proposed one can be canceled?
[01:56] <RAOF> mlankhorst: Hey, how much do you know about drm authentication stuff?
[01:57] <mlankhorst> not much, X server handles most of it, why?
[02:12] <mlankhorst> oh right it probably screws up on prime
[02:13] <mlankhorst> for some reason it only works there if i set /dev/dri/* to 666 even if im a member of video
[02:20] <RAOF> mlankhorst: More I mean “what stops me from flinking random numbers until I hit upon the framebuffer/other juicy buffers and then screen cap everyone else's session from my user's logged in session?”
[02:23] <mlankhorst> erm a handle to a bo is mapped per file
[02:26] <RAOF> But you can retrieve that bo from the global name, right?
[02:29] <RAOF> Via such magic as nouveau_bo_wrap and such.
[02:29] <mlankhorst> in prime?
[02:29] <RAOF> In general.
[02:30] <mlankhorst> doubt it, anyhow I think X is partly responsible for security as well
[02:30] <RAOF> From talking with airlied it's tied up with drm master, but I can't see how that's actually implemented in drivers/gpu/drm/*
[02:32] <mlankhorst> drm_gem probably
[02:32] <RAOF> Yeah; it's all protected with DRM_AUTH.
[02:33] <RAOF> But *everything's* got DRM_AUTH.
[02:33] <RAOF> Hm. Unless dropping master revokes that auth; but then I don't think the X server or clients reauth on VT switch in, so I don't think that's it.
[02:39] <mlankhorst> I'm not sure it would matter, if you get the fd you probably already have enough privilege 
[02:39] <RAOF> But you can pass across fds.
[02:40] <RAOF> mesa & X have different drm fds but share buffers.
[02:48] <mlankhorst> not sure
[02:48] <RAOF> Ok. At least that makes two of us :)
[02:50] <mlankhorst> prime is simply fd passing though
[02:51] <RAOF> My concern is with the system-compositor; it breaks some assumptions that may have been there providing security (the currently logged-in user is drm master, when you switch user they drop master, only the currently logged in user is in the active vt, etc)
[02:52] <mlankhorst> so try to write an exploit to steal someone else's bo :-)
[02:54] <RAOF> Ah. The experimentalist approach!
[02:55] <RAOF> I prefer to start with the “ask someone who knows what the hell is going on” approach; it makes everything easier ☺
[02:56] <mlankhorst> oh with nouveau it's usually easier to start with RE'ing
[02:57] <RAOF> Well I feel that the nouveau code could do with a clean up if the easiest way to understand it is to reverse-engineer the open source driver :)
[02:57] <RAOF> And this (should be?) is in the common drm infrastructure, anyway.
[02:58] <mlankhorst> RAOF: I don't mean RE'ing nouveau
[02:58] <mlankhorst> the other implementation
[02:59] <mlankhorst> you're the kind of person that sees 2 and 2 and thinks 2 right?
[02:59] <RAOF> Right.
[03:02] <mlankhorst> although sometimes RE'ing is hard, I tried to RE aaronp but he didn't manage to get me the answer whether nvidia supports y swizzling or not :(
[03:02] <RAOF> Heh.
[03:40] <RAOF> Ah. So, it seems the answer to “how does drm auth prevent inactive users from snooping on the active user's buffers” is “it doesn't”. Hurrah!
[06:20] <sbeattie> bryceh: yeah, correct, I had them dump the one in the unaccepted proposed queue, since I'd already pushed it through -security (and by extension, -updates)
[08:33] <mlankhorst> morning
[08:34] <mlankhorst> RAOF: figures, I guess having access to the nodes means you can probably look at the screen too :-)
[08:35] <RAOF> mlankhorst: You shouldn't, though.
[08:35] <RAOF> *Particularly* when you're not actually active.
[08:35] <mlankhorst> still beats nvidia in security, though
[08:36] <RAOF> Well, yes. You get to screen-scrape other users, rather than escalate-to-root :)
[08:43] <mlankhorst> upgrading everything to xorg 1.13 has proven to be a royal pain..
[08:48] <mlankhorst> I guess with all the major ones done I should focus on bumping all input drivers first
[08:59] <mlankhorst> RAOF: did we upload new libdrm yet?
[09:02] <seb128> mlankhorst, hey, do you feel better today?
[09:03] <mlankhorst> slightly :)
[09:03] <mlankhorst> milk + honey helps a lot
[09:04] <seb128> hehe
[09:04] <seb128> mlankhorst, not sure if you saw by bryce did an upload reverting the previous SRUs fixes to workaround the segfault
[09:04] <mlankhorst> not against the sickness but I can at least talk some again
[09:04] <mlankhorst> yeah I saw
[09:04] <mlankhorst> I'll put it on the blueprint to fix
[09:04] <seb128> mlankhorst, it would still be good to debug the real issue and add those backs with the segfault fix, but it's less of an hurry with the revert in
[09:05] <seb128> mlankhorst, thanks
[09:07] <mlankhorst> wow ppa buildqueue is empty? Time to saturate it
[09:11] <mlankhorst>  >:D
[09:13] <mlankhorst> RAOF: tiem for.. https://launchpad.net/~mlankhorst/+archive/x-1.13
[09:14] <mlankhorst> time*
[09:15] <mlankhorst> how do I get arm enabled in my ppa though?
[09:21] <mlankhorst> https://launchpad.net/ubuntu/quantal/+source/x11proto-randr/1.4.0+git20101207.0d32bb07-0ubuntu2 argh........ why call it 1.4.0 when it isn't O_O
[09:37] <mlankhorst> RAOF: what should we do about binary driver breakage with x1.13?
[10:26] <tjaalton> scr
[10:26] <tjaalton> oops
[11:07] <mlankhorst> yikes, seems my testing machine is dying
[11:10] <mlankhorst> sata errors and mounting r/o is probably not good..
[13:18] <ogra_> heh, xinerama is funny ... if i move glxgears around on a three hearded two cards multi screen xinerama setup, i get 
[13:18] <ogra_> 8146 frames in 5.0 seconds = 1629.200 FPS
[13:19] <ogra_> 579 frames in 5.0 seconds = 115.800 FPS
[13:19] <ogra_> the latter is the low power card indeed ... 
[13:20] <ogra_> if i play a game that actually spreads fullscreen across both cards/all monitors ... does xorg take an average value between the two cards or would i be capped to the lowest framerate ?
[13:24] <mlankhorst> I didn't know xinerama did acceleration
[13:24] <mlankhorst> capped to lowest most likely
[13:25] <ogra_> well, i can play Xonotic with ~70fps at 5760x1080 ... 
[13:25] <ogra_> (just tried)
[13:26] <ogra_> (with effects set to ultra)
[13:27] <ogra_> that somewhat looks like it uses an average or so 
[13:32] <mlankhorst> nvidia drivers?
[13:37] <ogra_> fglrx
[13:38] <ogra_> sadly they drop randr and composite as soon as you switch on xinerama ... 
[13:40] <mlankhorst> I didn't know it even supported xinerama, most of the time it will cause loss of all acceleration
[13:43] <ogra_> well, given that radeon doesnt work at all in this config, i'm happy to at least have the fglrx stuff
[14:52] <mlankhorst> ok input rebuilds, looks like 37 video drivers will need a version bump..
[14:57] <mlankhorst> RAOF/bryceh: I doubt this can be automated, so could one of you maybe do it? I prepared nouveau, ati and cirrus in debian-experimental, so would just be a simple merge for those..
[14:58] <mlankhorst> modesetting lacks any acceleration so it will work, I'll try uploading the rest to my ppa to see which works and which doesn't
[14:59] <mlankhorst> oh right intel too
[15:15] <mlankhorst> https://launchpad.net/~mlankhorst/+archive/x-1.13/+packages all those xserver-xorg-video-* need an update..
[18:47] <Sarvatt> RAOF: here's the latest version of your out of tree stuff (with src/mesa/Makefile.am fixes added to fix i386 builds..) if it helps any http://bazaar.launchpad.net/~xorg-edgers/xorg-server/xorg-pkg-tools/view/head:/hooks/mesa-out-of-tree.patch
[18:48] <Sarvatt> darn thing needs refreshing every day :)
[18:50] <Sarvatt> saw you mention rebasing the patches the other day
[19:00] <ricotz> Sarvatt, hey, you are still having fun with mesa :\
[19:01] <Sarvatt> ricotz: yeah up to 6 commits that needed backporting to fix the build from this mornings checkout
[19:01] <Sarvatt> hopefully this one works :)
[19:01] <ricotz> hmm, aics it doesnt :\
[19:02] <ricotz> 8.1~git20120717.f42e601c-0ubuntu0sarvatt5 
[19:02] <Sarvatt> 6 is already uploaded
[19:02] <ricotz> ok ;)
[19:02] <Sarvatt> with http://cgit.freedesktop.org/mesa/mesa/commit/?id=bf484024b944a452e9022a1098313663e0028b29
[19:03] <ricotz> you can upload a clean tarball too, just rename the version and tar.gz according to 8.1~git20120717.rX.f42e601c
[19:04] <ricotz> i meant 8.1~git20120717.rX.xxxxxxxx
[19:04] <Sarvatt> if this doesn't build either i will
[19:06] <ricotz> i hope it works
[19:12] <Sarvatt> ricotz: doesn't look promising http://tinderbox.x.org/builds/2012-07-17-0023/logs/libGL/#build
[19:13] <Sarvatt> ..and it failed in gbm
[19:16] <ricotz> Sarvatt, this looks fixes in master
[19:16] <ricotz> http://cgit.freedesktop.org/mesa/mesa/commit/?id=2023bf996ed5c3797233b8d70670c28e15bdff75
[19:16] <Sarvatt> yeah i'm doing a new tarball now
[19:33] <Sarvatt> sucks the dev release gets +50 build score :)
[19:35] <ricotz> quantal rules :P
[19:38] <ricotz> \o/
[19:38] <ricotz> Sarvatt, damn symbols, but is looks good
[19:39] <Sarvatt> ricotz: ARGH :)
[19:39] <ricotz> looks like an abi break
[19:41] <mlankhorst> Sarvatt: if you had upload rights you could fixup the entire x1.13 stuff :-)
[19:42] <Sarvatt> its not like we can upload it until the nvidia blob works :P
[19:42] <Sarvatt> got a month or more
[19:43] <mlankhorst> Sarvatt: true but have to update every single package that depends on video abi since rebuild won' t work with this big abi breakage
[19:44] <mlankhorst> I will probably just upload the major ones to my repo for now
[19:44] <mlankhorst> eg cirrus, vmware, ati, nouveau, modesetting, intel
[19:45] <ricotz> mlankhorst, there are still some patch-rewrites needed too
[19:46] <mlankhorst> ricotz: I uploaded xorg-server just fine though?
[19:46] <ricotz> mlankhorst, i meant of the video drivers ;)
[19:47] <ricotz> like for xserver-xorg-video-tdfx
[19:47] <mlankhorst> oh sure
[19:47] <ricotz> and most of them are broken due the xaa removal
[19:48] <jcristau> are there still any users for the tdfx driver?
[19:48] <ricotz> no idea
[19:49] <Sarvatt> looks like its just tdfx broken against xserver 1.12 today, was a bunch more broken yesterday before the releases
[19:50] <Sarvatt> ricotz: it probably builds fine against 1.13?
[19:50] <ricotz> Sarvatt, upstream is fine, but the debian patches break it
[19:50] <ricotz> https://launchpadlibrarian.net/110246017/buildlog_ubuntu-quantal-amd64.xserver-xorg-video-tdfx_1%3A1.4.4%2Bgit20120716.42706433-0ubuntu0ricotz_FAILEDTOBUILD.txt.gz
[19:51] <ricotz> i might confused this with another package
[19:52] <mlankhorst> Sarvatt: airlied updated all xorg driver upstreams and in most cases released a new version so it builds
[21:58] <mlankhorst> bryceh/raof?
[22:02] <bryceh> mlankhorst, what's up?
[22:03] <bryceh> ah new drivers, yes may be worth resyncing
[22:04] <mlankhorst> yeah the thing is with debian freeze it's hard to upload there first
[22:04] <mlankhorst> so that means literally uploading every driver to ubuntu directly..
[22:05] <bryceh> will debian be pulling them in at some point within the next month?
[22:06] <mlankhorst> doubtful
[22:06] <bryceh> I think, unless something's broken, there is not a rush to get them in; we'll need to poke all the drivers anyway if/when we pull in the newer xserver.
[22:16] <bryceh> mlankhorst, maybe debian would be willing to pull the newer versions into experimental, and then we could sync from there?
[22:17] <mlankhorst> bryceh: maybe, anyone here has the capability to upload to experimental?
[22:17] <bryceh> mlankhorst, tjaalton might.
[22:41] <mlankhorst> ok I' ll try him :)
[22:41] <mlankhorst> don't know if he's back from vacation yet though
[23:07] <RAOF> mlankhorst: The way we deal with binary driver breakage in 1.13 is an email to various lists saying “we're about to break the binary drivers until we get a new set of blobs”