=== cpaelzer is now known as cpaelzer_lunch === cpaelzer_lunch is now known as cpaelzer === inaddy is now known as tinoco === ara is now known as Guest21851 [12:36] cyphermox, there is a full suite of signed module enforcement kernels at ppa:canonical-kernel-team/unstable. Lemme know if there are any gaps. [13:34] rtg: thanks. have you taken a look at the test matrix? [13:35] cyphermox, have you told me where it is ? if so, I've forgotten [13:36] rtg: I sent it by email, but here it is: https://docs.google.com/spreadsheets/d/1GbyQDb4-sRv7OlIpbISiwVJ2ARHP3AkG2HbPTRk7p-E/edit#gid=0 [13:36] first page is the matrix; second page is kernel test cases, last page (still needs to be fleshed out) is the userland-side tests [13:36] I set up scripts to make it easy to spin up VMs with the right keys and Secure Boot enabled [13:37] rtg: I'd still like to know if the test cases I wrote up there match up with however you were testing things on your side so far [13:37] cyphermox, k, lemme look through them [13:38] cyphermox, I actually used fwts-dkms, but bbswitch ought to produce the same result wrt secure boot [13:39] right, I only picked that one because I knew this one built [14:06] rtg: trusty lts-wily fails validation here -- everything looks as though SB is enabled; yet it loads the module [14:07] cyphermox, ok [14:08] is there anything I can check? [14:08] /proc/sys/kernel/secure_boot is 0, and so is moksbstate_disabled [14:08] cyphermox, it should be working. I'll check in a bit [14:08] could it be that the build I got is one that doesn't enforce? [14:08] cyphermox, oh, secure_boot shuold be 1 [14:09] right, it should [14:10] but the firmware does show SecureBoot-(UUID) is 6 0 0 0 1 [14:10] ie. Secure Boot is enabled. [14:10] cyphermox, anything in dmesg ? [14:10] what should I look for? [14:10] dmesg|grep Secure [14:11] nope [14:11] hmm. ok, gimme a bit to check it out [14:11] I suppose it may be that MokSBState is still set wrong, but the kernel should have noticed and logged something [14:12] cyphermox, yes, it should say that SB is disabled because MOKSBState is non-zero [14:13] well, I don't know whether MokSBState is zero or not [14:13] Are you checking the variable as MOKSBState or MokSBState? in case it's case-sensitive [14:14] MOKSBState [14:14] should be "MokSBState" [14:14] but I'm not sure if that's suppose to be case-sensitive. [14:15] huh [14:15] I think the variable would *not* be there at all if SB is enabled === tyhicks` is now known as tyhicks [14:18] if I'm to follow efivarfs code, looks like it might be case-sensitive, maybe that's the issue [14:18] certainly couldn't hurt [14:30] rtg: you're looking into whether this might be the issue? [14:30] cyphermox, soon [14:30] trying to wrap up a rebase [14:31] what worries me is that it looked like xenial did things correctly, but lts-xenial clearly doesn't [14:31] ie. on xenial if sb is enabled, modules are not loaded [14:31] you said wily I thought [14:32] oh, right [14:32] but it's irrelevant, they should be using pretty much the same code for the SB magic. [14:32] cyphermox, is there a difference in behavior between wily and lts-wily ? [14:33] I will be able to tell you later (currently on a trusty install) [14:34] I'm writing a xenial image to USB now, and upgrading the trusty machine to lts-xenial [14:34] err, I mean writing wily to usb [14:34] too many releases [14:41] hrm, well lts-xenial on trusty is also letting things through [14:47] ok, looks like the lts-wily kernel is looking for the right variable [14:52] cyphermox, case likely isn't the culprit (unless this is wrong): [14:52] arch/x86/boot/compressed/eboot.c: L"MokSBState", &var_guid, &attr, &datasize, [14:53] still getting my trusty instance spooled up [14:54] right, that's just what I was saying [14:54] and anyway, the kernel seems to think SecureBoot is off [14:55] except od -t u1 -An /sys/firmware/efi/efivars/SecureBoot-* shows it's set to 1 [14:56] going to try to reset everything in the BIOS to see [15:07] rtg: I don't know what to make of this, it looks at though none of the code is working -- the writing of the files in /proc should happen correctly regardless of whether enforcing is done or not, and if enforcing is enabled, we should see something other than a sdhci message in dmesg | grep Secure [15:07] ie. looks like the enforcing isn't being enabled either. [15:07] source for lts-wily has [15:08] arch/x86/kernel/setup.c:#ifdef CONFIG_EFI_SECURE_BOOT_SIG_ENFORCE [15:08] debian/changelog: * [Config] CONFIG_EFI_SECURE_BOOT_SIG_ENFORCE=y [15:08] debian.master/config/config.common.ubuntu:CONFIG_EFI_SECURE_BOOT_SIG_ENFORCE=y [15:08] debian.master/changelog: * [Config] CONFIG_EFI_SECURE_BOOT_SIG_ENFORCE=y [15:08] debian.wily/config/config.common.ubuntu:CONFIG_EFI_SECURE_BOOT_SIG_ENFORCE=y [15:08] debian.wily/changelog: * [Config] CONFIG_EFI_SECURE_BOOT_SIG_ENFORCE=y [15:08] not sure whether that's all it should have or if there should be a debian.trusty directory [15:08] cyphermox, looks like enforcement is enabled to me [15:08] except that still won't fix the writing files to /proc part. [15:08] right [15:09] debian.wily/config/config.common.ubuntu:CONFIG_EFI_SECURE_BOOT_SIG_ENFORCE=y [15:09] I don't know, but something is clearly broken [15:09] that's for trusty's lts-wily though, is it correct for it to be set in a debian.wily directory? [15:09] I'm grasping at straws, I have no idea how your build process works. [15:09] cyphermox, yes, that looks correct. [15:10] very well [15:10] well, moving on to testing wily itself now, and I'll leave the debugging in your hands. [15:11] cyphermox, looks like trusty isn't right either. [15:11] rtg@ubuntu:~$ dmesg|grep Secure [15:11] [ 0.000000] Secure boot enabled [15:11] rtg@ubuntu:~$ cat /proc/sys/kernel/secure_boot [15:11] 0 [15:11] rtg@ubuntu:~$ cat /proc/sys/kernel/moksbstate_disabled [15:11] 0 [15:12] that's what I was just saying [15:12] except I don't even get the Secure boot enabled message [15:12] Secure Boot is most definitely enabled on my test machine [15:13] cyphermox, in my case it means the user keys are enrolled correctly, but the secure boot state isn't getting save [15:13] saved* [15:13] ok, gimme a bit and I'll find it === ara is now known as Guest30555 [16:09] cyphermox, should I expect the MOK util enable/disable dialog when installing a DKMS package on Trusty ? [16:19] if you're using my PPA too, yes [16:20] cyphermox, oh, I'm not. that'll make a difference [16:21] yeah, and you should take care when you install as it will removed grub2-signed; and change the efi BootEntry [16:22] cyphermox, what is your PPA ? [16:22] I don't think the userland should make much of a difference for testing the kernel bits though [16:22] ppa:cyphermox/efi [16:22] I might as well test against it [16:23] cyphermox, I re-uploaded trusty. lts-utopic looks like it is working OK [16:23] ok, so to work around the fact that things are signed by my PPA key rather than the Canonical key, you'll want to go download http://archive.ubuntu.com/ubuntu/dists/trusty-updates/main/uefi/grub2-amd64/current/grubx64.efi.signed [16:23] you need to replace /boot/efi/EFI/ubuntu/grubx64.efi with that file. [16:23] (so grub is correctly signed) [16:24] cyphermox, can't I just re-sign using my local keys ? [16:24] and also run: sudo efibootmgr -b *whatever ubuntu is at, 0018 for instance, depends what efibootmgr -v says*; sudo efibootmgr -c -L ubuntu -l \\EFI\\ubuntu\\shimx64.efi [16:24] rtg: well, sure, you can resign with your keys if you want [16:25] cyphermox, that is a lot easier in my setup [16:25] the efibootmgr commands still probably will need to be done though [16:26] I'll fix that shortly [16:28] rtg: I don't know, did you reupload lts-utopic earlier? [16:28] whoops, forgot the efibootmgr command. [16:29] oh, I didn't test lts-utopic I think [16:29] cyphermox, trusty is the only kernel I've re-uploaded [16:43] bjf, what's the story on the arm64 wily boot saga? [16:44] cking, checking [16:58] rtg: have you looked at lts-wily though? doesn't look to me like the issue is the same at all [16:58] ie. there is that setbit call there. [17:04] cyphermox, still recovering from your grub package update. I think I'll not do that again. [17:06] you should be able to disable SB in BIOS to get booting [17:36] rtg: can you ping me as soon as you have things working correctly for secure_boot and moksbstate_disabled; so I know where we're at? [18:07] cyphermox, I'll be testing lts-vivid here in a sec [18:09] rtg: could we focus first and foremost on having trusty, lts-wily, lts-xenial, and xenial working correctly? [18:09] working on it [18:09] since lts-wily is what's installed by default if you install from 14.04.4. [19:09] cyphermox, ok, I'm comfortable that all the LTS kernels work. [19:23] rtg: ok; are things in the ppa? [19:24] cyphermox, yeah, the trusty kernel is still building, but I'm pretty sure it'll be OK [19:25] I'm gonna work on vivid/wily just be be sure those kernels work as well, but they should since the LTS kernels are built from identical sources [19:29] well, they will only work if you just did some code change, it was very obviously broken [19:38] cyphermox, indeed. vivid seems to work just fine. [19:39] what do you mean by "vivid"? [19:40] cyphermox, 15.04 [19:41] 15.04 is EOL, we don't care about it. [19:41] cyphermox, lts-vivid is still built from the vivid kernel [19:41] I'd really just like to see either trusty's linux-image-generic or linux-image-lts-wily-generic working so that I can feel like we did some kind of progress today [19:42] lts-wily works for me [19:56] can you build all the kernels and signed kernels in the PPA so we can do one last pass tomorrow and be good to do the SRUs ? [19:57] cyphermox, they are already built. [19:57] I'm not sure what you mean [19:57] what I mean is that to do proper testing, you should be able to add the PPA; then upgrade, and things would just work. [19:58] cyphermox, that is pretty much waht I've been doing [19:59] and re-signing stuff? or doing some other steps? [19:59] cyphermox, oh, I've had to re-sign but I think that is acceptable [19:59] I can't build an archive signed kernel in a PPA anyways [20:00] I do to, since you're building in a PPA; but any other steps would show that the process is broken [20:00] signing the kernel after update is the only "extra" step [20:00] fair enough [20:01] then let me finish this update and I'll check lts-wily again [20:01] cyphermox, I'm about EOD [20:02] please wait so you can know whether this is still exploding [20:02] 2 minutes. [20:03] I'm still getting secure_boot == 0 on lts-wily. [20:03] oh, wait [20:03] that's without re-signing, hold on [20:03] cyphermox, is it signed ? [20:03] never mind [20:09] looks fine, so to you we're good to SRU this crap? [20:10] cyphermox, all of the kernel patches have been accepted and applied. they'll appear in the next SRU cycle. [20:10] and the corrolary to this is "can we upload it all to -proposed queues tomorrow rather than friday?" [20:11] cyphermox, for that you will have to coordinate with bjf or kamal [20:11] well, if it's automated stuff that will just land if the patches are accepted and whatnot and merged in the right places, then that's fine [20:11] cyphermox, I dare not get in the middle of the stable team process :) [20:12] it doesn't have to be tomorrow; I'm just curious because friday is a national holiday for me. [20:12] yes, they are all on the master-next branch [20:12] very well [20:12] for all the relevant releases? [20:12] cyphermox, I think kamal packages everything beginning on Monday [20:12] does that include precise too? [20:12] ok [20:12] yup [20:12] rtg, cyphermox: yes, we'll start a new cycle (for all of them) on Monday [20:12] precise is with enforcing disabled iirc? [20:13] cyphermox, yes, enforcement is disabled in lts-trusty (i.e., precise) [20:13] ok [20:14] well, sounds like we're good then, thanks! [20:17] cyphermox, yup, cheers. === danjared_ is now known as danjared === JanC_ is now known as JanC