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