zlacker

>>Zuider+(OP)
Hmmm maybe i should keep windows offline for a few days…..

>>bratwu+B8
I always use opportunities like this to experiment with whatever workflow I have on Linux to see what state it's at. I just game on Windows and do work on Linux so for me the transition is always quite simple: just install what you want on Steam/lutris and compare performance.

Last time I was starting vanishing of Ethan Carter, but even though it was playable, the experience wasn't free of stutters, whereas windows ran flawlessly.

In any case, it is always nice to jump back and check out how far Linux has come.

>>gchamo+x9
A stolen code signing certificate affect Linux in the same capacity as Windows.

I'm of course ignoring the fact that a lot of Linux distros still do not have Secure Boot enabled by default, and therefore do not enforce any kernel driver signing policy.

>>Genbox+Td
Probably because those distros haven't developed a relationship with Microsoft. I'm reasonably certain that in order to distribute Linux on SB, you have to build the kernel as a Windows executable and get MS to sign it.

>>jart+Yp
Most manufactures decided to include Microsoft's signing key into firmware. That is not something Microsoft is in control of. Pre-loaded (factory) keys are much harder for Linux as it seems every distro wants their own signing key, and from an administration perspective, that is not easy to keep track of.

Everyone can load their own signing keys into firmware. However, if you want something that "just works", Microsoft signs a package called Shim[1] that can be loaded on most computers due to the pre-loaded keys.

A relationship with Microsoft is not needed in any way or form to have Secure Boot.

[1] https://launchpad.net/ubuntu/+source/shim

>>Genbox+jy
What's stopping the bad guys from using that shim to boot their own code? Is there a date when the shim expires and Microsoft has to renew it?

>>jart+H51
Well, it is a chain of trusted components that are responsible for loading the next component in the chain.

UEFI with Secure Boot enabled will only load the stage 1 bootloader if it is signed with the firmware trusted certificate. We don't know if this component is malicious, we just know it is signed by the certificate.

The stage 1 bootloader (shim) will then be responsible for loading the next component (stage 2 bootloader). It will only boot the component if it is signed with a trusted (chosen by the user/distro) certificate.

The bad guys can't insert themselves into this process, as they either have to be trusted by the UEFI firmware (protected by an owner password), signed by Microsoft (to replace the shim) or be signed by the distro's certificate.

As long as the chain is unbroken it is secure.