=== tai271828_ is now known as tai271828 === pkern_ is now known as pkern === JanC is now known as Guest23785 === JanC_ is now known as JanC [13:00] tseliot, have you built nVidia against a 4.6 kernel yet ? we've got one for you in the yakkety pocket of https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/ppa [13:38] rtg: I have built 361 with a patch for 4.6, and I'll use that kernel for testing now, thanks [13:38] tseliot, great! [14:15] rtg: ok, the patch seems to need more work. I'll let you know when it's ready [14:23] tseliot, ack [20:39] anyone know of a guide that'll tell me how to make dkms sign modules it builds? [20:42] Laney, sign them with what [20:42] this key that I made [20:42] and then added to the mok thingy [20:42] Laney, i know of no existing mecahnaism for that [20:42] wl.ko is now signed so I'm at least online :) [20:43] but the next kernel will I guess not have that [20:43] no indeed, but having the signing key on the machine seems like a lawed security position [20:44] it's at least root only [20:44] I haven't thought about this *that* much [20:44] Laney, https://docs.google.com/document/d/1Z1_jR3MmxuvqolQH4PORkJCgENkb2Tlw4FVA-sHqdMw [20:45] rtg, i think he has done the equivalent of that [20:45] yeah [20:45] I think cyphermox is working on the user space components for DKMS signing [20:46] okay, so not there yet [20:46] is there any sane configuration where you have the signing key on disk? if you do you might as well just turn secure boot of at MOK ? [20:46] I should read aout the arguments around this signing stuff [20:54] I suppose it's something like - [20:54] The key database is 'secure' even in the face of the system being rooted [20:55] and so an attacker that has root wouldn't be able to make the kernel load things if they don't have the signing key [20:55] in theory, the practice is much less clear [20:56] then you have to never let the private key touch the machine [20:57] right and that part is what makes the dkms side difficult [20:58] quite an interesting problem [20:58] would be keen to see the spec cyphermox is working to if there is one [20:58] also I managed to get upgraded to a kernel which refused to load wl.ko [20:58] i am unclear of the bigger picture inthe plan [20:59] without knowing that it was going to happen in advance, so I rebooted and had no network [20:59] that was a bit sad [20:59] yes, out of tree drivers are not first class citizens in a lot of ways,secure boot is one of them [20:59] thoughyou should have been told to turn off secure boot because dkms was installed [21:00] but perhaps that is only done as we transition from no dkms -> dkms installed [21:00] hmmm [21:00] perhaps update-manger or the release upgrader would have done that [21:01] the dkms asking you to disable secureboot via mok happens as part of dkms installing even at the command line [21:01] but perhaps not on upgrades or something [21:02] I can't rule out that I missed or ignored it either [21:02] * Laney checks dkms [21:02] Laney, I've gotten a couple of reports of basically the same thing happening [21:08] rtg: Hmm [21:08] It's confusing now because cyphermox moved to a new script in yakkety [21:08] and I didn't have a new enough shim-signed to have the "update-secureboot-policy" thing installed [21:08] so I wouldn't have been prompted to disable it [21:09] *however* I should have seen the old debconf questions [21:09] Laney, I think upgrading Wily to Xenial definitely has issues [21:09] which have now been unregistered by the new dkms [21:09] so probably out of luck to find out what happened to me [21:09] Laney, man its a minefiled [21:09] warrants some testing for sure [21:09] get that davmor2 on it [21:10] apw: Be glad you're not on the front line of this one :) [21:13] Laney: what's the issue? [21:14] * cyphermox reads backlog [21:14] hey cyphermox [21:14] I may not have been asked to disable SB but can't prove it any more [21:15] and also was wondering if there's a story about signing for dkms [21:16] Laney: you're not the first to mention it; I remember Steve pinged me a few weeks ago about not being prompted on upgrade, but being prompted afterwards when it probably should not, but that was also unreproducible [21:17] Laney: tbh I don't know how to sign the modules, do we have a userland too to do that? [21:17] There's some script shipped by the kernel [21:17] well, I suppose we do, the question is more, do we ship it and is it usable by the common mortal [21:17] right [21:17] sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 ./MOK.priv ./MOK.der /lib/modules/4.4.0-23-generic/updates/dkms/wl.ko [21:17] apw has update sbsign to include the module signing tool [21:18] sbsigntool includes kmodsign in the versions in -proposed [21:18] I haven't really looked into that yet -- the story to start with was to either have free things and all signed with our kernel package, or have third-party drivers and disable shim validation [21:18] ah, great [21:19] Laney: the SB disabling should only prompt if it can see that you're booting with secure boot enabled and that it's not already disabled [21:19] yeah I am in that situation [21:20] right chaps [21:20] thanks for educating me a bit while I was cooking me dinner [21:20] it is now ready - ttyl :) [21:20] Laney: ping me later and we can chat more about it [21:20] sure [21:20] see you!