[12:36] <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.
[13:34] <cyphermox> rtg: thanks. have you taken a look at the test matrix?
[13:35] <rtg> cyphermox, have you told me where it is ? if so, I've forgotten
[13:36] <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:37] <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:38] <rtg> cyphermox, I actually used fwts-dkms, but bbswitch ought to produce the same result wrt secure boot
[13:39] <cyphermox> right, I only picked that one because I knew this one built
[14:06] <cyphermox> rtg: trusty lts-wily fails validation here -- everything looks as though SB is enabled; yet it loads the module
[14:07] <rtg> cyphermox, ok
[14:08] <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:09] <cyphermox> right, it should
[14:10] <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:11] <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:12] <rtg> cyphermox, yes, it should say that SB is disabled because MOKSBState is non-zero
[14:13] <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:14] <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:15] <rtg> huh
[14:15] <cyphermox> I think the variable would *not* be there at all if SB is enabled
[14:18] <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:30] <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:31] <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:32] <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:33] <cyphermox> I will be able to tell you later (currently on a trusty install)
[14:34] <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:41] <cyphermox> hrm, well lts-xenial on trusty is also letting things through
[14:47] <cyphermox> ok, looks like the lts-wily kernel is looking for the right variable
[14:52] <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:53] <rtg> still getting my trusty instance spooled up
[14:54] <cyphermox> right, that's just what I was saying
[14:54] <cyphermox> and anyway, the kernel seems to think SecureBoot is off
[14:55] <cyphermox> except od -t u1 -An /sys/firmware/efi/efivars/SecureBoot-* shows it's set to 1
[14:56] <cyphermox> going to try to reset everything in the BIOS to see
[15:07] <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:08] <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:09] <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:10] <cyphermox> very well
[15:10] <cyphermox> well, moving on to testing wily itself now, and I'll leave the debugging in your hands.
[15:11] <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:12] <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:13] <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
[16:09] <rtg> cyphermox, should I expect the MOK util enable/disable dialog when installing a DKMS package on Trusty ?
[16:19] <cyphermox> if you're using my PPA too, yes
[16:20] <rtg> cyphermox, oh, I'm not. that'll make a difference
[16:21] <cyphermox> yeah, and you should take care when you install as it will removed grub2-signed; and change the efi BootEntry
[16:22] <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:23] <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:24] <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:25] <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:26] <cyphermox> I'll fix that shortly
[16:28] <cyphermox> rtg: I don't know, did you reupload lts-utopic earlier?
[16:28] <rtg> whoops, forgot the efibootmgr command.
[16:29] <cyphermox> oh, I didn't test lts-utopic I think
[16:29] <rtg> cyphermox, trusty is the only kernel I've re-uploaded
[16:43] <cking> bjf, what's the story on the arm64 wily boot saga?
[16:44] <bjf> cking, checking
[16:58] <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.
[17:04] <rtg> cyphermox, still recovering from your grub package update. I think I'll not do that again.
[17:06] <cyphermox> you should be able to disable SB in BIOS to get booting
[17:36] <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?
[18:07] <rtg> cyphermox, I'll be testing lts-vivid here in a sec
[18:09] <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.
[19:09] <rtg> cyphermox, ok, I'm comfortable that all the LTS kernels work. 
[19:23] <cyphermox> rtg: ok; are things in the ppa?
[19:24] <rtg> cyphermox, yeah, the trusty kernel is still building, but I'm pretty sure it'll be OK
[19:25] <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:29] <cyphermox> well, they will only work if you just did some code change, it was very obviously broken
[19:38] <rtg> cyphermox, indeed. vivid seems to work just fine.
[19:39] <cyphermox> what do you mean by "vivid"?
[19:40] <rtg> cyphermox, 15.04 
[19:41] <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:42] <rtg> lts-wily works for me
[19:56] <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:57] <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:58] <rtg> cyphermox, that is pretty much waht I've been doing
[19:59] <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
[20:00] <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:01] <cyphermox> then let me finish this update and I'll check lts-wily again
[20:01] <rtg> cyphermox, I'm about EOD
[20:02] <cyphermox> please wait so you can know whether this is still exploding
[20:02] <cyphermox> 2 minutes.
[20:03] <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:09] <cyphermox> looks fine, so to you we're good to SRU this crap?
[20:10] <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:11] <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:12] <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:13] <rtg> cyphermox, yes, enforcement is disabled in lts-trusty (i.e., precise)
[20:13] <cyphermox> ok
[20:14] <cyphermox> well, sounds like we're good then, thanks!
[20:17] <rtg> cyphermox, yup, cheers.