Comment # 66 on bug 1175626 from John Shaw

(In reply to Martin Wilck from comment #65)
> (In reply to John Shaw from comment #63)
> > All are empty. I shut my machine off every night and reboot in the morning
> > with SecureBoot disabled. Updates come through in that mode, so I wonder if
> > they don't try to setup the certificates/keys.
> 
> This is how it's designed, yes. If the nvidia driver is installed with SB
> disabled, it will not try to either generate or enroll any keys. You need to
> uninstall the drivers, enable SB, reboot, and install them again.

This makes sense, if MokManager worked for me;)


> 
> > Although I can sometimes boot
> > with SecureBoot (I tried again a couple of days ago), I cannot get the
> > nVidia driver to be enrolled.
> 
> That makes no sense to me. With SB, a driver can't be sometimes loadable and
> sometimes not. If the key hasn't been enrolled, it's not loadable, period.
> Unless you are booting a Leap 15.1 kernel, that is.

I mean that I was able to get to the MokManager screen with SB enabled, but
there was no "enroll key" line. I continued to boot, but the graphics driver
was not loaded. This is consistent with mokutil --list-new being empty (I
guess). Its very unclear (to me at least) why the kernel would have booted as
its been updated a number of times in the past few days. I would have thought
that would generate a new certificate. This happened only a couple of times out
of ~20 reboot attempts, and it generally it hangs on an blank screen.

This behavor also makes me wonder if the BIOS is just plain buggy.

> 
> >  This is not an option for me as I write
> > Cuda-based codes.
> > 
> > I count not care less about having SecureBoot (why would anyone?), but I
> > figured I would try to help debug this issue. The certificate file is
> > available for the nvidia driver, so I can be imported with mokutil again.
> 
> Hm. If the driver was installed without SB as you wrote above, it wouldn't
> generate a key. If there is still a key file around, it's likely from a
> previous installed version of the driver and won't work with the current
> drivers you have.

The current certificate is MOK-nvidia-gfxG05-450.66-default.der, which is the
same version as the driver. Presumably the actual keys would be different from
install to install, so this is left over from an attempt to update the driver
when SB was enabled. Deleting this key, and doing a full uninstall/reinstall of
the driver would generate a new self-consistent key. It would be good until the
next driver update (which seems to be coming though more often than usual these
days).

> 
> > This may force MOK to pause and let me enroll it. If there is nothing to
> > enroll, what is MOK Manager supposed to do on a boot? Is its supposed to: a)
> > do nothing and pass control to grub; b) flash MOC screen and move on; or c)
> > show MOC screen and wait a few seconds?
> 
> It's a). Otherwise we'd see the mok screen on every boot.

ok. 

> 
> (In reply to John Shaw from comment #64)
> > I imported the nVidia certificate for the latest driver, so it shows up in
> > with --list-new. This should force MOK manager to attempt to enroll it. If I
> > boot with SecureBoot enabled, it hangs BUT the first time I tried I had a
> > mostly black screen, with green "noise" along the top. This was the first
> > time I saw this phenomena, and it looks like the video driver (?) crashes
> > when trying to display the MOK screen. Repeating the boot resulted in a pure
> > black screen, so I guess the green noise is a random thing.
> 
> At the time MokManager is running, the EFI environment of your BIOS is
> responsible to display the screen. It could be that this fails. MokManager
> uses 
> EFI calls to switch the console to *from graphics to text mode*, actually;
> perhaps your EFI BIOS has an issue with text mode? It wouldn't be the first
> BIOS that fails at simple text mode. Whatever goes wrong here, I don't see
> how it could be related to the fact that you installed the Linux nvidia
> drivers and enrolled a certificate for them.

If its the underlying EFI BIOS that buggy, there is nothing to be done. I have
the latest BIOS for my MB, but it was issued about 2 years ago. Its unlikely
ASUS will issue any more updates for it, but I will keep watch for one. People
running Windows have to occasionally start in safe mode, or bring up the ntldr
boot menu for whatever reason. That would seem to be a screen in simple text
mode, and by this point many many people would have reported if it did not work
with this MB (ASUS z170A).

Is it possible that there is some simple bug in console.c that could account
for this? (eg, a timing issue?) Just a thought.



> 
> https://github.com/rhboot/shim/blob/master/lib/console.c
> https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf (�12)
> 
> If you have that black/green screen, you don't know what's going on of
> course. Normally Mokmanager would wait for a key press for some time, then
> continue normal boot without enrolling anything. But it deletes any certs in
> MokNew IIRC, even if they weren't enrolled, so it's normal behavior that at
> subsequent boots the MokManager screen wouldn't show up again.
>  
> > My machine has two nVidia cards in it. A GTX 950 drives two monitors, and a
> > Quadro GV100 is used for Cuda development. This is not "normal" for a home
> > computer (the GV100 costs ~$8.5k).
> 
> Both cards using the same driver?

yes, nVidia used to have separate drivers for consumer and pro products, but
now there is just a single unified driver. 450.66 is the current long-lived
stable one. Its officially supports both cards, so there is nothing funny here.

> 
> > This may be the difference causing the
> > problem, but I cannot imaging why, as the BIOS display clearly has no
> > problem with it and it has nothing to do with nVidia drivers. Maybe the way
> > MOK Manager writes or initializes the display has an issue if multiple
> > graphics cards are present. If this is the case, maybe this is not worth
> > pursuing at your end.
> 
> If it's no big hassle for you, you might try if the problem goes away if you
> remove or disable the GV100 card.

Let me think about it (ie, its a hassle;). I don't really believe this has
anything to do with anything, but I thought I would mention it. The theory
about a bug in the BIOS being able to switch to text only mode makes the most
sense to me. There seems to be no way to show a "simple" bios in text-only mode
anymore. In the past, I have been able to run memtest86, which looks like it to
has a text interface. I can try to boot that and make sure it still works.

> 
> > Anyway, if I then boot with SecureBoot disabled, MOK Manager comes up, but
> > it does not offer to enroll anything (ie, the nVidia certificate).
> 
> Probably the cert has been removed from MokNew by that time. (Does mokutil
> --list-new still show them?).
> 
> >  I can
> > continue, reset MOK, or import (?) keys or hashes for files. In either of
> > the last two cases, I cannot get to the certificate file (.der) for the
> > nVidia driver, but I can navigate the UEFI directory. I guess I could try to
> > import hashes for some of the \efi\opensuse\*.bin files.
> 
> You could try copying the nvidia .der files to some path below \EFI aka
> /boot/efi/EFI. (doesn't have to be \EFI\opensuse).
> 
> >  Presumably I need
> > at least shim.efi,   grubx64.efi, and MokManager.efi. Anything else? Clearly
> > none of this matters with SecureBoot disabled.
> 
> No certificates should be needed for any of these. shim is signed by
> Microsoft, and has built-in certificates for verifying the further steps in
> the openSUSE boot chain.

ok thanks.

Out of curiosity, why does MokManager come up if SB is disabled? Presumably
there is nothing meaningful for it to do. For users who disable SB, this is
just a confusing screen page. I would suggest that MokManager kick out
immediately and pass control to grub if it determines SB is is not in effect. I
can confirm the Linux believes SB is disabled when I disable it.