Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror

Comment: Re:Poor Mattthew Garrett (Score 5, Informative) 88 88

I stopped working on Ubuntu because decisions were increasingly being made internally rather than anywhere that volunteer contributors could influence them. The "Click here to instantly break your mouse" thing was just the final straw. There's a component to the story that involves beer and a hilarious reply vs. reply all error on an iPhone, but I don't remember it being about anyone siding with Scott - there's a picture somewhere of me deactivating my Ubuntu membership a few minutes after sending https://lists.ubuntu.com/archives/ubuntu-devel/2008-February/025141.html , which hardly gave them time to.

Comment: Re:Not even a brick, not a story (Score 5, Informative) 215 215

Removing the CMOS battery didn't recover this system, which is pretty much what I'd expect - UEFI variables are typically stored in the same hardware as the firmware itself, and unplugging batteries doesn't kill your firmware.

The system doesn't fail to boot. The system doesn't even complete its power-on self checks. The screen is never turned on. It never responds to keyboard input. It's bricked. This machine's not coming back to life without an SPI programmer.

Comment: Re:Conceptually.. (Score 5, Insightful) 196 196

The kernel can execute ring 0 instructions. Your initrd can't. The difference is that you could construct an appropriately modified hibernation image that booted an arbitrary kernel - or even an entirely separate OS. In that scenario, your kernel is effectively a new bootloader, except unlike the signed bootloaders it'll happily boot an entirely unsigned OS. That's unlikely to end well.

But, conceptually, you're right. Secure Boot doesn't magically make a system secure, but it *is* a vital part of system security - if you can't trust your kernel, any other security you attempt to build is pretty much pointless.

Comment: Re:What problem does it solve? (Score 1) 210 210

You don't need an exploit or a kernel patch. You just need to replace the firmware's function pointer to GetVariable(), which is a thing you can do because you're running untrusted code in the firmware context. The OS has no way of knowing that you're doing that.

Comment: Re:What problem does it solve? (Score 1) 210 210

Please describe how Windows can accurately determine whether it was booted in Secure Boot mode or not. For an encore, describe how Trusted Computing can limit the code you can boot. As far as I know, single machine local attestation is an unsolved problem.

Always look over your shoulder because everyone is watching and plotting against you.

Working...