Hacker News new | comments | show | ask | jobs | submit login
Which Distros Work on New Windows 8 Machines (ostatic.com)
45 points by Garbage 1576 days ago | hide | past | web | 37 comments | favorite



Why not just link to Matthew's post?

http://mjg59.dreamwidth.org/20522.html


UEFI, at least as I understand things, was really about enterprise desktops, which are nice big chunks in terms of sales compared to individual consumers. The consumer facing change is a side effect.

From the perspective of the corporation buying big amounts of computers from an oem, your users are employees, and it makes sense that you don't want them screwing with secure boot. Individual Consumers still have options.

The ARM thing is, however, a bigger deal.


UEFI is not secure boot just like boot from USB is not BIOS.

Secure boot is great we just have to demand that we control the keys.


What? Booting from USB uses the BIOS.

The solution to UEFI is to refrain from using it. Just use a classic BIOS.

If some Linux distribution cannot boot via a legacy BIOS (how difficult is that, really? we've been doing it for over 30 years), then it's not an OS worth using.

Relative to everything else BIOS software has not changed much in 30 years (ask yourself why; it does not need to), and only a couple of companies have a monopoly on nearly all BIOS software.

A BIOS does not need features. It does not need a shell and applications. It just needs to initialise hardware and launch a bootloader, and to be able to do this from a variety of media. That is, relatively, a very simple task. You want it to work everytime, with no fiddling.

UEFI is not giving you anything that is worth the hassle it can cause and the complications it can add to simply booting a device. It is not giving you more freedom.

Whatever the reasoning behind UEFI (maybe there is no compelling reason; that wouldn't be a first), UEFI is a recipe for disaster. Because MS is headed downhill, they will get desperate and will try anything to retain market share; and they have a history of using complexity and obscurity as a way of disincentiving many users from using Windows alternatives (e.g. Gates used the original BIOS strategically this way in the 80's).

UEFI is certainly not the path to "hardware and software freedom". It will not make things easier for any user who wants to use different OS's on a variety of HW. But it may be abused by MS who has immense influence on hardware manufacturers.

Stick with the old BIOS. Keep it simple.


The BIOS is hardly simple. Apart from the fact that modern OSes need to re-implement half of what the bios was designed for just to get the full adress space, and jump through countless hoops during boot is secondary. There are still timeswhere I have to reboot to change some BIOS setting, which is unnesasarily inconvinient. Presumably, UEFI implentations will be tested and stable.

Also, even if your distribution supports BIOS, that does not mean your motherboard does.


I've been using Fedora since well before they dropped the "Core", but F18 might just be when I jump to Arch. The MSFT signed shim is just too repellent a concept to me; I will sooner use a distro that makes me mess with UEFI/BIOS options crap.


There are lots of valid reasons to dislike Fedora, but "working out of the box on new machines" seems like an unlikely one.


No, but to me "paying microsoft for mythical grandmother users" is reason enough for me.


A total of $100 was paid to Microsoft. I'm pretty sure that MSFT's not going to break out this massive new revenue stream in the end of year accounts


I am well aware. Actually, I thought it was only $90, not $100.

It is the principle of the matter. Paying that $90, when really there is little reason to on x86 (it would be more excusable on ARM), is the equivalent of saying "uncle".


Especially since all x86 machines with Secure Boot allow you to disable it. And to get a LiveCD or Install CD to boot you need to go via the BIOS/UEFI/other firmware anyway.


I once suggested transferring the keys to a neutral standard body in another thread on HN.


It would be nice to see hardware OEMs completely neutering this nonsense by installing default public keys of their own alongside the MSFT keys, then publicly release the private material so that anyone could sign images that would be trusted by default.

Who the hell even needs this "feature"? Are we really so afraid of an "evil maid" attack? People who legitimately need it are a minority (some larger corporations and... paranoid people?) and can remove/add their own keys.

I assume some part of their contract with MSFT would prevent them from doing this.


> Who the hell even needs this "feature"? Are we really so afraid of an "evil maid" attack? People who legitimately need it are a minority (some larger corporations and... paranoid people?) and can remove/add their own keys.

Calling people paranoid that want security feature X is not productive.

European governments are using Trojans to track pretty small crimes already, and some people regularly change planes in charming environments like China. What you say applies to almost every security measure.


Listen, I am into security. I've been using FDE for the better part of the past decade, use two-factor authentication along with a passphrase with ssh (and always tunnel my traffic on public wifi), encrypt all of my personal files before I back them up to S3/dropbox/whatever, and have lined my wallet with foil (after microwaving most of my cards). At one point I considered and partially followed through with epoxying the ram into one of my motherboards.

For some people, these may be sensible security measures. For most people, including myself, it's just plain old paranoia. So long as it is harmless, there is no problem with it.

Protecting the general public from a hypothetical evil maid that wants to swap out their kernel is not harmless if it means inconveniencing consumers^, and is frankly off the deep end. Some people need to worry about that, and the tools needed to protect themselves should be made available to them, but the general public really doesn't have to worry about it. Making people opt-out of it is nuts.

^ Yeah, it's not MSFT's consumers that are being inconvenienced, and I can't imagine OEMs are going to all of a sudden start caring about minority OS users out of nowhere after all of these years... Neither of those facts will make me refrain from futilely complaining on the internet.

(as a side note, I don't see how productivity is involved. What does "being productive" mean here?)


> (as a side note, I don't see how productivity is involved. What does "being productive" mean here?)

Umm - I guess "convincing" would have been the better word? :) If you blame people for demanding too much security, then it only makes Linux look bad and insecure in comparison to Windows, or at least that was my impression in this thread. I don't think that the threat is inherently less realistic than any of the other things we protect against - the problem is Microsoft's implementation of this particular security measure.


As Harry Dresden said: "... just because you're paranoid doesn't mean there isn't an invisible demon about to eat your face."


>Who the hell even needs this "feature"? Are we really so afraid of an "evil maid" attack? People who legitimately need it are a minority (some larger corporations and... paranoid people?) and can remove/add their own keys.

Correct me if I am wrong, but the evil maid attack needs a physically present malicious person. The vast majority of bootkits don't need this and can install undetectable malware across the internet.


That may be the case, but if malware is able to swap out your kernel on the filesystem with a malicious one at runtime, surely you are hosed anyway?

This seems to like either a protection against a hyper-paranoid threat, or a bandaid on a larger problem.

How many security incidents is secure boot actually projected to prevent?


A signed bootloader that loads a signed kernel(with things like signed filesystem drivers) which loads a signed antivirus executable will actually be able to detect bootkits.

A few references to widespread bootkits:

http://www.chmag.in/article/sep2011/rootkits-are-back-boot-i...

http://www.theregister.co.uk/2010/11/16/tdl_rootkit_does_64_...

http://www.computerworld.com/s/article/9217953/Rootkit_infec...


That's the "sufficiently smart compiler" argument ("If only the world was perfect, then the world would be perfect, and although there is no evidence the world can in fact be perfect, and there is mounting evidence that it isn't, I will assume it can and will be made perfect soon enough").

Except for the boot signature, all of these could have been successfully implemented in the past and prevented everything you reference -- how on earth would an internet virus update the kernel or boot unless the kernel let it? but that wasn't the case.

There is no reason that secure boot would help in this respect.


Is this antivirus presumably missing the malware that would install the bootkit before it could actually do so?

If it gets to the point that secure boot is what saved you, then there was already a series of fairly disturbing errors. Layered security is good, but if it is really needed in a common case to this extent... what the hell is going wrong?


Well the problem is that antiviruses only know about publicly identified viruses. Everytime a new virus or a variant is released, a good number of computers get infected before the virus is identified and fingerprinted. If you are met with a state sponsored virus/malware, good luck with an antivirus companies even acknowledging it.

The way I see it, secure boot is like SSL, it stands as the last resort before giving up complete control.


Why bother with default keys? Why not just ship with SecureBoot as an optional feature? If people want to really be secure they need to enroll their own key they trust.


That would be better, though shipping with default keys would be more of a "fuck you" to microsoft I think, which appeals to me.


I wonder who will take on the responsibility on educating people like my mom on who to trust and how to enroll public and private keys.

Or how about we have it secure by default and allow people who presumably know what they're doing to turn it off or enroll their own keys or ones they trust because of their heightened knowledge? Are there really a lot of people who are able to partition their hard disk but unable to turn secure boot off? How does that compare with the number of people running Windows and vulnerable to malware and bootkits?


>Or how about we have it secure by default

If the private key is public, it's not secure, there's barely a point, hence my question... That's why I find this all so amusing.


The problem is that no neutral standard body is willing to step up.


The latest Windows 8 Dell Inspirons let you turn off UEFI.


Of course they do. All x86 Windows 8 PCs are required by Microsoft to allow disabling Secure Boot.


I am still using my almost-4-years-old Asus laptop, so I don't know much about this secure boot thingy, but I thought they require vendor to allow consumers to turn the secure boot off?


Turning off secure boot is only required for x86 and the actual article (at mjg59.dreamwidth.org) says "in case you don't want to fiddle with firmware settings."

So for Arm you would still need a signed boot loader.


My relatively new machine boots both UEFI and Legacy. I have tried Ubuntu, Fedora, and Arch in UEFI only boot and they all work out-of-box in their own ways.


Currently running Ubuntu 12.10 on a brand new HP Envy 4 Ultrabook. Everything works just fine, but I had to use Boot Repair and turn off secure boot in the BIOS before Grub would show at boot.


There is a special Ubuntu ISO for secure boot that contains pre-installed Boot Repair but it didn't work for me. I just used regular ISO and it worked like charm.


same here. ordered two Lenovo laptops and they were both allowed to switch between legacy and UEFI.


Weirdly being filtered by the public wifi spot i was using.

(http://imgur.com/fPeXY)




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: