On Sun, 2019-03-31 at 15:42 +0200, Giovanni Mascellani wrote: > Hi, > > Il 31/03/19 08:18, Steve McIntyre ha scritto: > > I've extended and updated Lucas' initial SB page: > > > > > > https://wiki.debian.org/SecureBoot > > > > > > to cover a lot more user-facing stuff. Please review... > > Thanks for the writing. It is very nice and helpful to read. As a > rather > noob user of UEFI things, here are my thoughts after reading, in the > hope they can be useful to make it even better. > > * The trust chain is rather clear to me, and it's nice in that it > tries > to move from Microsft to Debian as soon as possible and to the user > itself as soon as possible. > > * I managed to enable Secure Boot on my laptop (Dell Precision 5530) > wihtout problems following instructions in the Testing page. > Everything > works, with the small exception that when I run "mokutil --import" > the > following is written to the output: > > Failed to write MokAuth > Failed to unset MokNew > > Sill, after a reboot shim will pickup the key and apparently install > correctly if I give it the password (the key will appear in "mokutil > --list-enrolled"). Similar writing appear when removing the key from > MOK, but again the key apparently correctly disappears and is not > listed > any more by "--list-enrolled". Yes, those false negative log messages seem to be a common issue with mok. > * I understand what the main shim and the MokManager are for, but > what > is FallBack for? https://github.com/rhboot/shim/blob/master/README.fallback > * I would like to be able to compile and load my own Linux modules, > both because I want to use NVIDIA drivers and because I need to > recompile a mainline module to workaround a problem with the Dell > firmware on my laptop. It would be nice, as Debian, to offer a smooth > workflow for doing this. Is something available already? If I follow > the > instructions in [1], linked by the Wiki page, it asks me to execute > "update-secureboot-policy --new-key", which launches a dialog > interface > that just asks me whether I want to keep Secure Boot enable or not. > It > doesn't actually take into account the option "--new-key". Is this > due > to the fact that Debian doesn't have yet a signed version of shim 15? > > [1] > https://wiki.ubuntu.com/UEFI/SecureBoot/DKMS Can't work with the Debian kernel at the moment, see my other reply to this thread. > * Apparently I can change the root Secure Boot keys in my firmware > configuration. I do not know much of how Secure Boot key management > works, but I can modify four things called "db", "dbx", "kek" and > "pk", > which is probably what I need to fully decide what can be booted on > my > machine and what not, without depending from Microsoft policies. Is > it > supported to verify shim at boot time with either Debian or my own > key, > removing entirely the dependency on Microsoft? If it is possible, it > would be nice to document this on the Wiki. shim is only signed with the MSFT CA right now, so you need to have the MSFT CA cert in db. If you are really worried about having non-debian certs in db, you can simply enroll the hash of shim into db. That way it can be verified without the CA. You'll have to update it everytime the package is updated of course, but hopefully that doesn't happen too often in stable. Also PE supports multiple signatures, so I guess we could consider signing it also with the Debian CA... but I don't think other vendors do this, and it would require a number of changes to the processes and packaging of shim, so IMHO even if we want to it's too late for buster. Also I don't know how well it's supported to have a list of signatures by the various tooling, so again IMHO too dangerous to consider for buster. -- Kind regards, Luca Boccassi
Attachment:
signature.asc
Description: This is a digitally signed message part