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