@mjg59 Well most users don't have the luxury of open implementations. Running firmware code with kernel privs compromises their security.
@mjg59 @oshepherd Refraining from executing firmware blobs in ring 0 after boot should not require starting over from the beginning.
-
-
@RichFelker@oshepherd so you keep saying but it currently does so it is unhelpful with regard to the current situation -
@mjg59@oshepherd What breaks if you just rip out that code? -
@RichFelker@oshepherd Bootloader installation, boot order priority, boot source configuration, all configuration of shim's keystore -
@mjg59@oshepherd None of those are needed on an already-setup system. I've never had need for any of those. -
@RichFelker@oshepherd your needs are not everyone's needs. I've needed to do all of these post installation.
End of conversation
New conversation -
-
-
@RichFelker@mjg59 To what end? The firmware is always resident in SMM, so stuff in Ring 0 is the least of your worries... -
@oshepherd@mjg59 SMM is another bug to fix, yes, but the existence of bugs at one layer is no excuse for not fixing other layers. -
@RichFelker@mjg59 if you replace your firmware such that your SMM is trustable then your EFI runtime should be trusted also -
@oshepherd@mjg59 I was talking about desoldering/cutting the SMI pin. -
@oshepherd@mjg59 Alternatively some chipsets have a register to disable it which the kernel could use, if you trust it. -
@RichFelker@mjg59 there isn't an SMI pin, and firmware *correctly* blocks writes to that bit -
@oshepherd@mjg59 On early models (386-486 era?) there was a pin, and the disable register was available a few years back. -
@RichFelker@mjg59 since about Pentium it's been a bus cmessage. It has always been possible for SMM to disable the disable register - 2 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.