| === absk007 is now known as Guest34745 | ||
| === absk007_ is now known as absk007 | ||
| unixist | I'm trying to add an additional x509 key to the system keyring, but in order to do so, the new key must be signed with the old key. How do I do this? You can read https://www.kernel.org/doc/Documentation/module-signing.txt and / for "keyctl padd" to see what I'm trying to do | 01:08 |
|---|---|---|
| unixist_ | I d/c'd. Did anybody answer my question about signing and inserting additional public keys into the kernel's system keyring | 03:11 |
| === unixist_ is now known as unixist | ||
| === gerald is now known as Guest62279 | ||
| free1 | hello #ubuntu-kernel | 03:42 |
| free1 | infinity: can you fire a sniper rifle? | 03:45 |
| smb | tseliot, So I filed bug 1431753 as a result of my tests with dkms (in case you have not seen, yet). Turns out the slightly over-eager dkms builds do help to let the nvidia driver get away with bad behaviour. | 09:34 |
| ubot5 | bug 1431753 in nvidia-graphics-drivers-340-updates (Ubuntu) "Nvidia binary driver FTBS due to DKMS layer violation" [High,Confirmed] https://launchpad.net/bugs/1431753 | 09:34 |
| tseliot | smb: I've just had a look at it. bbswitch-dkms is not part of the nvidia sources | 09:37 |
| smb | tseliot, Ah ok, minor lapse on my side. It is just always there when I have nvidia driver installed. | 09:39 |
| smb | Probably should have guessed since the version number differs | 09:39 |
| tseliot | smb: as for UVM, what you suggest might cause some trouble packaging-wise as UVM is only available on amd64 (no armhf or i386), at least in the 346 series | 09:39 |
| tseliot | yes, the nvidia packages recommend bbswitch for hybrid graphics | 09:40 |
| infinity | tseliot: Why would it only being available on amd64 matter? | 09:40 |
| infinity | tseliot: If you package nvidia as a single driver instead of two, the Makefile can surely be smart enough to DTRT for the kernel it's building for. | 09:41 |
| infinity | Single dkms package, that is. | 09:41 |
| tseliot | infinity: it would add even more complexity to the packages. I don't know if you remember what the packaging is like... ;) | 09:41 |
| smb | infinity, I think because you can not declare it only for one arch in the dkms.conf | 09:41 |
| infinity | tseliot: It would reduce complexity... | 09:41 |
| smb | Still one might just do a dummy thing | 09:41 |
| tseliot | I can definitely look into it but we can probably lower the bug priority | 09:42 |
| smb | tseliot, But touching other modules private parts as you do now is as bad :) | 09:42 |
| tseliot | smb: I'll get back to you on this. I really need to have a look at the code first though, as I really don't remember how it works | 09:44 |
| smb | tseliot, Ok, right now we are lucky to have working installs most of the time as the multiple dkms autoinstall runs get things done eventually (most of the time). You just can expect appart to go on bitching at you | 09:46 |
| smb | apport even | 09:46 |
| infinity | Hrm, all this needs is for DKMS to export $kernel_arch, and we're set. | 09:47 |
| tseliot | smb: ok, I definitely don't need apport to complain any more than it already does ;) | 09:47 |
| infinity | Since dkms.conf is a shell script. | 09:47 |
| infinity | And it might exist as $arch, despite the manpage not documenting it. | 09:49 |
| smb | infinity, What might not be there is something to tell it a module only will be there for $ARCH==x. Right now I think there is only an array of module name and some where to put those | 09:50 |
| infinity | So, it might be as simple as doing this: | 09:51 |
| infinity | if [ "$arch" = "x86_64" ] | 09:51 |
| infinity | BUILT_MODULE_NAME[1]= | 09:51 |
| infinity | DEST_MODULE_NAME[1]= | 09:51 |
| infinity | ... | 09:51 |
| infinity | fi | 09:51 |
| infinity | smb: Yeah, if $arch is there, the other bit is easy. | 09:51 |
| smb | infinity, Ah I see what you mean | 09:51 |
| infinity | You only add to the array if the arch matches, done. | 09:51 |
| tseliot | I can try that | 09:51 |
| infinity | Make that proper shell syntax (; then), etc. | 09:52 |
| infinity | Not sure if $arch is the right thing, mind you. This source is messy. :P | 09:53 |
| tseliot | maybe I won't even need that | 09:54 |
| tseliot | but yes, I can see what's wrong in the sources now | 09:54 |
| tseliot | I'm not sure I wrote that code though | 09:55 |
| tseliot | smb: that seems to be an upstream (i.e. NVIDIA) choice. I should probably talk to them before making any changes | 11:30 |
| smb | tseliot, hm ok. Likely behaves as bad for everyone but just we happen to trigger apport if dkms fails. :/ | 11:35 |
| tseliot | smb: right | 11:35 |
| infinity | tseliot: Upstreams aren't always right, and this is clearly wrong. | 11:38 |
| infinity | tseliot: If the dkms packaging comes from them, by all means, tell them they're wrong, but don't do something just because they say so either. | 11:38 |
| tseliot | infinity: I know. Since we use (more or less) the same packaging scripts, I think it makes sense for me to ask them first. I'm not asking permission. It's about collaboration. | 11:41 |
| rbasak | ppisati: we're looking for an equivalent of rdtsc on armhf for porting issues | 13:03 |
| rbasak | ppisati: found http://blog.regehr.org/archives/794, but that needs enablement of access to the CPU's cycle counter from kernel space | 13:03 |
| rbasak | ppisati: do you know why we don't do this by default anyway, given that INtel permits it? Is there any particular reason, or could we get upstream to enable this by default universally? | 13:03 |
| rbasak | jamespage, ogra_, smb: incidentally the cross-distro list might be a good place to ask, if nobody knows here. | 13:04 |
| ogra_ | yeah " | 13:04 |
| rbasak | Many ARM people there, and the patch would only be useful to ceph upstreams if all the distros do the same thing here. | 13:04 |
| rbasak | IIRC there's also a Launchpad project to track arm porting issues. | 13:05 |
| smb | Yeah, there might be a reason but I don't know ... | 13:07 |
| ppisati | rbasak: why don't you use the perf infrastructrue for that? | 13:23 |
| ppisati | rbasak: i mean | 13:23 |
| rbasak | ppisati: doesn't that involve a system call? | 13:24 |
| rbasak | In that case we could just use clock_gettime(2) | 13:24 |
| rbasak | jamespage did find http://neocontra.blogspot.co.uk/2013/05/user-mode-performance-counters-for.html which talks about how to use perf | 13:24 |
| rbasak | But if that was suitable the original code would be using that instead of rdtsc | 13:25 |
| rbasak | I presume the system call overhead is too high | 13:25 |
| ppisati | ah | 13:26 |
| ppisati | but did you read the comment about that piece of code? | 13:26 |
| ppisati | "Setting the V bit also allows userspace to access the System Validation Operations Register. Among other amusing effects this allows any userspace process to schedule a hard reset of the CPU in N cycles time." | 13:26 |
| rbasak | Oh | 13:26 |
| rbasak | So that'll be the reason then. | 13:26 |
| rbasak | Thanks! | 13:27 |
| rbasak | jamespage: ^^ so that'll be the reason it's not enabled by deafult then :) | 13:27 |
| ppisati | rbasak: dude, but i would be interested to hear some more comments on this | 13:27 |
| ppisati | rbasak: so, if you wanna send a msg to the cross distro ml or linux-arm, i'm all for it | 13:27 |
| ppisati | rbasak: i think anything an rdtsc that doesn't involve a syscall might be useful for many people | 13:28 |
| ppisati | just my 2 cents | 13:28 |
| rbasak | ppisati: yeah, but not at the cost of allowing userspaces process to hard reset | 13:28 |
| ppisati | rbasak: of course, but there might be another way | 13:28 |
| ppisati | rbasak: anyhow yes, that thing doesn't sound good :) | 13:29 |
| pkern | Hey. Would it be possible to push https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/1314653 for trusty as well, for compatibility with the utopic lts backport? Having the governor set to performance makes for a bad experience on laptops with the new kernel. | 14:27 |
| ubot5 | Ubuntu bug 1314653 in sysvinit (Ubuntu Trusty) "sysvinit: default cpufreq governor to powersave for intel-pstate driver" [High,Confirmed] | 14:27 |
| ogra_ | pkern, the governor is always forced to ondemand | 14:44 |
| smb | Problem seems to be that ondemand is not available with intel_pstate | 14:44 |
| ogra_ | unless pitti broke that with the switch to systemd (it is still a sysvinit job, not sure he ported that) | 14:44 |
| ogra_ | oh | 14:44 |
| smb | It does not sound unreasonable... not sure why we initially said no... | 14:45 |
| smb | I try to remember to ask Colin on Monday ... maybe he remembers | 14:46 |
| ogra_ | is that code even still used with systemd ? | 14:47 |
| smb | ogra_, it is in Trusty :) | 14:47 |
| ogra_ | ah | 14:48 |
| pkern | ondemand is gone with intel-pstate on trusty with the utopic kernel. | 14:49 |
| pkern | smb: Yeah, it was a bit sad not to see a rationale. | 14:49 |
| pkern | I guess because it wasn't urgent at the time with the trusty kernel, only with 3.16+ it's now relevant. | 14:49 |
| smb | pkern, Agreed. And since the additional powersave is lower prio in the case statement it should not harm the other cases | 14:50 |
| pkern | smb: ACK. | 14:51 |
| pkern | smb: That might sound weird, but mind to take the issue in the meantime or assign it? ;-) | 14:55 |
| smb | pkern, Totally weird. Why would I want to do that. :-P Yeah, done | 14:55 |
| pkern | smb: Thanks! | 15:02 |
| zequence | infinity: currently building | 15:17 |
| infinity | zequence: I saw, thanks. :) | 15:18 |
| free1 | Do you retain logs? | 15:28 |
| Pwnna | does anyone know how the configs from the mainline builds are generated? | 16:29 |
| apw | Pwnna, yes, i do | 16:33 |
| Pwnna | apw: we left off of the CONFIG_MEMCG discussion. i had to go sleep | 16:34 |
| Pwnna | specifically http://pastebin.ubuntu.com/10582239/ | 16:34 |
| unixist | I'm trying to add an additional x509 key to the system keyring, but in order to do so, the new key must be signed with the old key. How do I do this? You can read https://www.kernel.org/doc/Documentation/module-signing.txt and / for "keyctl padd" to see what I'm trying to do | 16:35 |
| mozmck | What is different between the vivid kernel and the trusty lts-backport-vivid kernel? | 16:35 |
| infinity | mozmck: Very little, except for the repository it's published in and the name of the metapackages. | 16:45 |
| infinity | unixist: You can't, not without rebuilding the kernel. The key we use to sign modules is generated and thrown away during the build. | 16:47 |
| apw | unixist, yep, waht infinity said, the key never persists, it is gone | 17:03 |
| mozmck | infinity: thanks. Now how do I find the closest release to 3.18.9 in the repository? I see commits like "Ubuntu-lts-3.18.0-14.15~14.04.1", but the makefile at that point says 3.19.x | 17:05 |
| infinity | mozmck: That's a question for apw, though it seems odd that a 3.18 tag would be 3.19 | 17:07 |
| free1 | mislabeled? | 17:08 |
| apw | mozmck, ok they moved the MEMCG things into a new section RESOURCE_COUNTERS which defaults off ... so we default it off | 17:10 |
| unixist | apw: hm? | 17:10 |
| apw | mozmck, and that makes the others go away | 17:10 |
| apw | the "things which are new" logic is very simplistic in the test build generator | 17:10 |
| free1 | apw: Who is "they" that moved the memcg? | 17:11 |
| apw | upstream | 17:11 |
| apw | they moved that option and a few others under a new menu option, and that new option defaults off | 17:11 |
| apw | and so they get lost | 17:11 |
| apw | because the config doesn't come with a schema migration plan, like it needs | 17:12 |
| free1 | apw: any identity for "upstream"? | 17:12 |
| infinity | free1: Not everything is a conspiracy theory. | 17:12 |
| infinity | Shockingly. | 17:12 |
| Pwnna | hm | 17:14 |
| infinity | unixist: Maybe you missed my response that apw was referring to... | 17:14 |
| infinity | unixist: You can't, not without rebuilding the kernel. The key we use to sign modules is generated and thrown away during the build. | 17:14 |
| apw | mozmck, in theory this list http://people.canonical.com/~kernel/info/kernel-version-map.html has the upstream to ubuntu mapping | 17:14 |
| apw | mozmck, and if i checkout that tag, i get:\VERSION = 3 | 17:15 |
| apw | PATCHLEVEL = 18 | 17:15 |
| apw | SUBLEVEL = 7 | 17:15 |
| apw | a 3.18.7 based kernel ? | 17:15 |
| tseliot | smb: I've just spoken with upstream, and I'm ready to make the required changes. Just FYI | 17:15 |
| free1 | infinity: Is it possible there is no crime involved? Then it is not a conspiracy. | 17:16 |
| unixist | infinity: My question happens to pertain to custom-built kernels. If the key were maintained, then how would sign and add subsequent keys? | 17:16 |
| apw | unixist, in the packaging we manually re-sign our own packages so you should be able to do the same if you keep the key | 17:17 |
| infinity | unixist: So, for custom-built kernels, you just want to use a real key for the master signing key, not a throwaway. And then use that to sign subsequent keys. | 17:18 |
| apw | i doubt we let you do that, but hey :) | 17:18 |
| unixist | infinity: apw: Gotcha. My question is how exactly to do that. I tried using something like: scripts/sign-file sha512 old.key old.x509 new.x509 | 17:18 |
| unixist | to no avail | 17:18 |
| mozmck | thanks for the info. I see that tag, but I was also seeing the other commits which I don't understand. Anyhow, I'll try the 3.18.7 tag. | 17:19 |
| infinity | apw: By "we", you mean the Ubuntu packaging? Almost certainly not. | 17:19 |
| apw | infinity, indeed that | 17:19 |
| infinity | Might be friendly to allow one to plug in path-to-key in debian/rules or some such. | 17:19 |
| infinity | And use it if it's set. | 17:19 |
| apw | mozmck, well to be honest you might as well just resign everything with your own key and not have a magrathea key at all | 17:19 |
| free1 | I only ask if there is an identity. | 17:20 |
| free1 | Why sign kernel "downstream" for identity or just for nothing? | 17:20 |
| apw | infinity, and yes we should | 17:20 |
| infinity | unixist: ^ :P | 17:20 |
| mozmck | apw: I think you are talking to unixist about that? | 17:20 |
| infinity | mozmck: He was. He's old, he forgets. | 17:20 |
| apw | i might be, i think i should just put both your names on everything and let you filter, cause i am not getting them right at all | 17:20 |
| mozmck | haha! me too and I'm not that old. tab completion messes me up sometimes. | 17:21 |
| apw | infinity, old enough to forget your birthday i am sure | 17:21 |
| free1 | Of course if there were only 1 committing the crime it is neither conspiracy. That is called meditation. | 17:21 |
| infinity | free1: Do you honestly believe any of this is a useful contribution to the conversations taking place? | 17:22 |
| unixist | apw: This is for key rotation. If the signing key is compromised, I'm screwed until I rebuild and deploy to the entire fleet. That takes lots of time | 17:22 |
| unixist | I read somewhere in the key retention service's documentation about revocation. I plan to read more about that since part of what I want to do is predicated on being able to revoke the initial signing key | 17:22 |
| free1 | Yes. Why do you want to identify anything? | 17:22 |
| infinity | unixist: So, the kernel always has at least one key baked in. That's the only way it can validate subsequent keys. | 17:23 |
| infinity | unixist: If you lose that one, you pretty much have to shut down the world and roll out new kernels. So, uhm, don't do that. | 17:23 |
| apw | infinity, it has one ca chain built in ... right, so it could have the master master key in it, and veryify the chains from there | 17:25 |
| apw | i think | 17:25 |
| infinity | Right. | 17:25 |
| apw | and use "this months" kernel siging key | 17:26 |
| apw | signed with that, or something | 17:26 |
| infinity | But that top master either needs to be ephemeral or super secret. | 17:26 |
| unixist | infinity: gah I see. the problem would then be a race to revoke-and-replace-original-key | 17:26 |
| apw | but ... given your h/w and your bootloader are about as secure as a wet paper bag, this is mostly moot | 17:26 |
| free1 | IBM was the first to sell identity systems to nazi germany. So the story goes. | 17:26 |
| free1 | Crackheads break into your house. | 17:26 |
| free1 | Identify them? | 17:26 |
| infinity | And if it's ephemeral, you could use it to sign a subsequent rotating module key at build time before you throw it away, and roll out revocations of THAT key. | 17:26 |
| apw | a master master key shouldn't exist in one part "ever" | 17:27 |
| free1 | Everywhere. | 17:27 |
| apw | so it cannot be stolen | 17:27 |
| free1 | No need to key anything. | 17:27 |
| free1 | Just look out the window. | 17:27 |
| free1 | Sodomites everywhere. | 17:27 |
| * unixist ignores free1 ;) | 17:27 | |
| * unixist ignore free1 | 17:27 | |
| infinity | apw: Sure a proper CA master in fragments that produces chained authorities that sign kernels works fine. But you still can't revoke the key embedded in the kernel without also disabling signed module loading. | 17:28 |
| apw | infinity, well you can't reall revoke it either because well it doesn't have any way to get the revokation into the kernek | 17:29 |
| unixist | infinity: you could insert-new-and-revoke-old in a single operation | 17:29 |
| apw | module signing is almost as badly designed as secure boot | 17:29 |
| infinity | unixist: Honestly, I'd just go lockdown in a suspected compromise situation. "echo 1 > /proc/sys/kernel/modules_disabled" and call it done. | 17:30 |
| infinity | apw: Exactly. | 17:30 |
| apw | infinity, and you should be there after boot on all your critical boxes, and living on the moon in a steel cage | 17:30 |
| infinity | apw: I *am* living on the moon in a steel cage, are you not? | 17:31 |
| apw | infinity, you arn't in my cage, i hope | 17:31 |
| * infinity elbows apw. | 17:31 | |
| apw | infinity, but if you are in that cage you forgot to disconnect those insecure network thingies | 17:31 |
| infinity | unixist: In theory, that would be lovely. In practice, I don't think that's possible. | 17:31 |
| unixist | infinity: bleh that's hawrd. rebooting all boxen after such a case is infeasible. Admittedly what I'm looking for is to walk the thin line between productivity and security. Therein lie the difficult and fun problems | 17:32 |
| infinity | unixist: And as long as the attackers can trigger a reboot, you've lost anyway, because baked in is baked in. Any modifications you do to the in-memory keyring at run time are, well, in memory. | 17:32 |
| unixist | infinity: true. I guess I'd have to treat reboot as a "reprovision" during lockdown | 17:33 |
| infinity | (And it's usually much easier to trigger a reboot than to gain enough privs to insert a module) | 17:33 |
| unixist | and that pre-supposes that I always know when I'm compromised | 17:33 |
| unixist | infinity: ya totally | 17:33 |
| infinity | I haven't really looked into what improvements have gone into signed modules since the Plumbers two years ago when we had a nice long BoF about how much it sucked, but it really feels like it was just implemented as a bullet point feature with not much attention to actual security. | 17:37 |
| infinity | Sadly. | 17:37 |
| infinity | But with good key management practices, you can make it still be useful. | 17:38 |
| infinity | The pain point is that your signing key can't be fragmented, because you need to sign all your kernels with it, so a bit of a catch-22 on the "good key management" front. | 17:38 |
| infinity | Erm, well, maybe not. I guess you could have a CA key fragmented, dump the public key in the keyring, sign an ephemeral key with that, and use it for all your module signing, and push revocations to live machines. But then you lose all your modules, even the ones you kinda like. | 17:40 |
| infinity | So, you'd need to build everything in that you actually need at runtime. | 17:40 |
| infinity | At which point, why are you allowing module loading at all? | 17:40 |
| unixist | infinity: lose all the modules? they'd just have to be re-signed, right? | 17:41 |
| unixist | I mean, not fun, but not lost | 17:42 |
| infinity | unixist: Sure, you'd have to re-sign them all and push the new ones along with your revocation. That's starting to look like almost as much work as just rebuilding a kernel and pushing it, though. | 17:42 |
| unixist | infinity: what I want to avoid is a reboot | 17:42 |
| unixist | infinity: that means cold rolling cache, minutes of downtime for each host, very slow across many hosts, etc. | 17:43 |
| infinity | unixist: Fair. I suspect you're optimising for a weird attack vector, though. But no criticism here for wanting to cover your bases. | 17:44 |
| infinity | unixist: So, yes, a "key of the month club", signed by your fragmented CA that you assemble only to sign those monthly keys would do the trick. | 17:45 |
| infinity | Modules get signed by key-of-the-month on the build machine, cert chain is put in the keyring, and you can revoke the subordinate key. | 17:45 |
| infinity | Assuming the kernel keyring actually supports revocation. :P | 17:46 |
| infinity | Which I'd like to think it should. | 17:46 |
| unixist | infinity: word | 17:46 |
| infinity | That said, if I can access your build machine to get your subordinate key, I can also poison your builds. | 17:47 |
| infinity | So you'd have to make sure you have backups and signed hashes and the like, or you're re-signing trojans and pushing them out. | 17:47 |
| unixist | There'd have to be something like signed version control and two-factor auth'd build kickoffs | 17:48 |
| unixist | sounds like amazing pain^H^H^Hlan | 17:49 |
| infinity | unixist: Yes. I've been considering a nice career in the field of NOTHING TO DO WITH COMPUTERS for a while now. | 17:50 |
| unixist | infinity: :) | 17:50 |
| mjg59 | infinity: Or just go with an HSM rather than fragmented keys | 18:39 |
| free1 | jsalisbury: when did you become op? | 19:46 |
| jsalisbury | free1, a few years ago | 19:47 |
| free1 | jsalisbury: and how do you identify freenode? | 19:49 |
| jsalisbury | free1, I'm not sure I understand the question | 19:50 |
| free1 | when is the last time a cop jumped in front of a bullet for you? | 19:51 |
| free1 | jsalisbury: do you just sign on and assume that it is the same freenode you signed on to the last session? | 19:52 |
| free1 | do the cops pro-kick you? | 19:53 |
| free1 | jsalisbury: answer the question | 19:59 |
| infinity | free1: None of those is on topic for #ubuntu-kernel. At all. | 20:00 |
| free1 | What about at one? | 20:02 |
| * hggdh waits for the hammer | 20:20 | |
| free11 | jsalisbury: still connected? | 21:11 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!