FSF recommendations for free OS distributions considering Secure Boot

https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/whitepaper-web

by ibotty • 14 years ago

136 89 14 years ago

CJefferson• 14 years ago

sigh

While the FSF seems happy with the root Fedora is taken, it is interesting that every suggestion they make will make user's life harder.

I realise that they want to make software more free, and that this is broadly all Microsoft's fault, but I'll be honest as the years go by, I just get... tired. I just want to be able to install Linux as easily as Windows, and have it just work. I don't want to have to install extra keys.

sp332• 14 years ago

Crypto multiplies, or even exponentiates, the effort you take to secure something vs. the effort an attacker makes to break it. But if you put 0 effort into logging in to your computer (no password, or the same simple password for every website, etc.) it will be broken easily, because 0 to the power of anything is still 0. If your computer has restricted boot, your only options are to make some effort at keeping your computer secure, or let someone else make the decision of what to run on your computer. If you're looking for convenience at the expense of security, you should push back against Secure Boot being enabled by default (which Win8 "certification" mandates).

ben0x539• 14 years ago

That's kinda backwards. It's not the FSF that is pushing Secure Boot to begin with, but it is the FSF that is pushing for everybody to be able to install their Linux as easily as Windows and not only Fedora or Ubuntu users.

krupan• 14 years ago

Please direct all your sighs of discontent at Microsoft, not the FSF.

rdl2• 14 years ago

I would prefer not to be "protected by a GPL licensed bootloader" from having a machine actually boot successfully under default conditions.

Pretty much ok with Fedora and Ubuntu making the best of a somewhat bad situation. I wish they'd just fix the standard to allow multiple signatures on code and extensions, though. With that, Secure Boot would be basically all positive.

icebraining• 14 years ago

I would prefer not to be "protected by a GPL licensed bootloader" from having a machine actually boot successfully under default conditions.

But Fedora's solution achieves both, so there's no need to leave GRUB2 for UEFI.

earl• 14 years ago

It's amazing. I read the first 3 paragraphs and the eff can't even acknowledge how much of a problem malware is for many computer users.

For the thousandth time: I know a computer user who almost had a $300k sum stolen because his laptop was owned. He has had to resort to having a second laptop used exclusively for accessing his business bank accounts in order to feel some security. He's not dumb: he makes more money than virtually anybody reading this and has an undergrad in math.

The computer security model for most users is incredibly broken. The alternate to secure boot is something like an ios app store for all apps. Users simply want to be able to run their computers without having to be constantly paranoid about spyware and malware. Microsoft is at least trying to do this, but the eff pretty much dismisses these very real concerns.

edit: for the record, I spelled fsf as eff before having my first cup of coffee.

cletus• 14 years ago

I've had similar thoughts. I can make a fairly strong case that the best platform for me to access sensitive information from is iOS (specifically my iPad). It's sandboxed and comparatively secure.

Using Windows these days just seems like asking for trouble on the spyware/malware front. Some of it is your machine getting owned, other times its just missing a checkbox on a program install that installs a browser bar that does God knows what.

My Macbook Air is pretty much my computer of choice these days (with very little third party software). Soon Apple will require sandboxing on the Mac App Store too. Linux of course also being a much better choice than Windows from a security point of view.

On the browser front I can't see myself using anything other than Chrome. Part of this is feature-related and the whole one process per tab thing but it's also the most security-conscious browser IMHO (disclaimer: I work for Google but not on Chrome).

gouranga4• 14 years ago

We've got 135 on site users, 25 mobile users and about 500 windows machines and VMs floating around.

We haven't had any machines "owned" at all...

Xuzz• 14 years ago

The FSF, not the EFF. The EFF is generally much more reasonable (moderate?) about things like this; the FSF is generally more in line with Stallman's views (radical or crazy, depending if you agree with him).

rbanffy8• 14 years ago

You know... They fight for the users. Exchanging long-term freedom for short-term security (or the illusion of security) is rarely a good idea.

viraptor2• 14 years ago

How much of that malware is actually working at the level that the bootloader is concerned with? And how many samples are just trivial keyloggers, screen grabbers, enablers for fishing attacks, etc. that don't even need anything more than user-level privileges? I'd happily run a system with no standard antivirus / malware protection / ... as long as it has a good separation of resources from kernel to user-space. I subscribe to ideas like http://qubes-os.org much more than trying to protect the bootloader. The typical user-space is exposed too much at the moment and the number of really sophisticated exploits isn't that big.

You're saying "Microsoft is at least trying to do this" about a company that continues to hold up fixes to known exploits (maybe not publicly known, but it takes only a single person...) until a convenient patch day, but manages to push own idea of security which breaks other peoples' systems onto the whole industry (strangely those other systems are not affected to the same degree). That's what I would call a very real concern.

From my experience with the "typical user", migrating my gf's laptop from Windows to Ubuntu did more for security than any bootloader hardening could do. And it required no hardware update either...

anonymfus• 14 years ago

>And how many samples are just trivial keyloggers, screen grabbers, enablers for fishing attacks, etc. that don't even need anything more than user-level privileges?

They need more privileges for hiding itself from antivirus software, SmartScreen and MMSRT.

beagle34• 14 years ago

Unless you can produce credible statistics showing bootloader malware, I'm going to call "strawman".

Bootloader signing is going to do NOTHING against the current threat model, which is all in the much higher levels.

Yes, an ios-app-store for all apps model IS effective against the current threat model (but also harmful to the computing economy at large). Secure boot, at this point, does ESSENTIALLY NOTHING against any of the worms / trojans out there.

recoiledsnake10• 14 years ago

Here are some references about boot malware which UEFI secure boot can prevent.

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...

I recommend reading atleast the first link.

Here's one juicy bit:

TDL4 is the most recent high tech and widely spread member of the TDSS family rootkit, targeting x64 operating systems too such as Windows Vista and Windows 7. One of the most striking features of TDL4 is that it is able to load its kernel-mode driver on systems with an enforced kernel-mode code signing policy (64-bit versions of Microsoft Windows Vista and 7) and perform kernel-mode hooks with kernel-mode patch protection policy enabled.

When the driver is loaded into kernel-mode address space it overwrites the MBR (Master Boot Record) of the disk by sending SRB (SCSI Request Block) packets directly to the miniport device object, then it initializes its hidden file system. The bootkit’s modules are written into the hidden file system from the dropper.

The TDL4 bootkit controls two areas of the hard drive one is the MBR and other is the hidden file system created at the time of malware deployment. When any application reads the MBR, the bootkit changes data and returns the contents of the clean MBR i.e. prior to the infection, and also it takes care of Infected MBR by protecting it from overwriting.

The hidden file system with the malicious components also gets protected by the bootkit. So if any application is making an attempt to read sectors of the hard disk where the hidden file system is stored, It will return zeroed buffer instead of the original data.

The bootkit contains code that performs additional checks to prevent the malware from the cleanup. At every start of the system TDL4 bootkit driver gets loaded and initialized properly by performing tasks as follows: Reads the contents of the boot sector, compares it with the infected image stored in hidden file system, if it finds any difference between these two images it rewrites the infected image to the boot sector. Sets the DriverObject field of the miniport device object to point to the bootkit’s driver object and also hooks the DriverStartIo field of the miniport’s driver object. If kernel debugging is enabled then this TDL4 does not install any of it’s components.

TDL4 Rootkit hooks the ATAPI driver i.e. standard windows miniport drivers like atapi.sys. It keeps Device Object at lowest in the device stack, which makes a lot harder to dump TDL4 files.

All these striking features have made TDL4 most notorious Windows rootkit and it is also very important to mention that the key to its success is the boot sector infection.

Another bit:

The original MBR and driver component are stored in encrypted form using the same encryption. Driver component hooks ATAPI's DriverStartIo routine where it monitors for write operations. In case of write operation targeted at the MBR sector, it is changed to read operation. This way it is trying to bypass repair operation by Security Products.

keithpeter• 14 years ago

"I know a computer user who almost had a $300k sum stolen because his laptop was owned."

Was this unfortunate gentleman's laptop subject to unauthorised access by means of a compromised bootloader/bios? I have heard of very few exploits of that nature (but I'm not involved in supporting large numbers of machines).

cooldeal5• 14 years ago

The concern is not that bootloaders/bios is compromised. It is that once the PC is compromised, the malware can load from the bootloader before the OS or antivirus can even load, and then hide itself from them completely, thus making it effectively invisible.

Think of it like a VM loader, an OS running in a VM may not even be able to find out if it's running on Linux or Windows, but the host can transparently see everything going on in the guest OS.

einhverfr6• 14 years ago

I am no fan of what Microsoft is doing here, but it is an emerging threat profile and consequently some sort of boot loader signing makes sense. The exact design of course should be such that it is possible for users to update keys, however, because otherwise, once a key is compromised the whole system falls apart.

batgaijin• 14 years ago

Until we have 'personality' virtualization for os's, so you can have subaccounts, the model is shitty. Also, programs and users should be treated the same.

einhverfr6• 14 years ago

Isn't that, more or less, what selinux lets you do?

mjg59• 14 years ago

Well maybe you should have read more of it? They explicitly acknowledge the benefits of secure boot - the concern they have is that it's possible for the current model to be used to prevent the owners of machines from being able to choose what their computer will run.

ajross• 14 years ago

This is the Free Software Foundation's position, not the Electronic Frontier Foundation's. Those are very different organizations. The fact that you confuse their acronyms (and also that you apparently stopped reading after three paragraphs) makes me worried that you are conflating their positions.

Also: how does secure boot prevent your laptop from being "owned?". It doesn't. I will bet a significant fraction of that $300k that the exploit used against your friend was not pre-OS malware.

ibotty• 14 years ago

a fraction as in 1, i'd say.

cooldeal5• 14 years ago

Not only that, but after calling secure boot basically useless for security, they turn around and want to secure their PCs against malware known as Windows using secure boot!

Flimm• 14 years ago

They didn't call it useless, they said it could be useful, if done correctly. From their point of view, if it were done correctly, the user ought to be able to block Windows. But since that will be difficult, it undermines the security advantages of Secure Boot. Their position is quite consistent.

giZm03• 14 years ago

>I know a computer user who almost had a $300k sum stolen because his laptop was owned. He has had to resort to having a second laptop used exclusively for accessing his business bank accounts in order to feel some security. He's not dumb: he makes more money than virtually anybody reading this and has an undergrad in math.

So what you saying is that just because you know some smart guy that owns a lot of money, UEFI is a good solution for fighting malware. I'm not so sure that UEFI is really gone help your friend to be more secure ... maby feel more secure though, which of course is a valid point but probably not because he will see thru it. Maby you friends laptop was due to a bootloader hack but there is easier ways to hack computer then that. I'm not saying that we shouldn't try to do anything about the risks but not this way, because this do only do it harder for everyone else.

stcredzero5• 14 years ago

> The computer security model for most users is incredibly broken.

Agreed.

> The alternate to secure boot is something like an ios app store for all apps.

That's not the only alternative, though. Having a way to simply notify users of a signing status change would be enough.

http://news.ycombinator.com/item?id=4190930

rbanffy8• 14 years ago

> It's amazing. I read the first 3 paragraphs and the eff can't even acknowledge how much of a problem malware is for many computer users.

Maybe because those who boot into environments endorsed by the FSF don't have a malware problem. I certainly don't.

That doesn't make me insensitive to other people's problems. But I have no sympathy for those who face such problems because they chose to.

I'll take it seriously when bootloader malware become the dominant model, because only difference is being harder to detect. Each and every malware I've seen is perfectly happy with user-level permissions and privilege escalation from within the OS and, once UEFI becomes the norm, I suspect signing keys will leak anyway.

wtallis• 14 years ago

"can't even acknowledge how much of a problem malware is for many computer users"

What text are you drawing that conclusion from? It strikes me that they deliberately pass up the opportunity to disparage the security explanation for secure boot: "This claim ignores the fact that we need protection from them." Not "This claim is total BS."

The FSF statement acknowledges the security concern and brings up a competing concern. They ask that computer makers balance the two competing needs, and state that the plans for implementing secure boot on x86 will satisfy both needs. That's definitely not the blindly one-sided position you seem to think it is.

tzs• 14 years ago

> Their stated concern is that someone might ship an Ubuntu Certified machine with Restricted Boot (where the user cannot disable it). In order to comply with GPLv3, Ubuntu thinks it would then have to divulge its private key so that users could sign and install modified software on the restricted system.

> This fear is unfounded and based on a misunderstanding of GPLv3. We have not been able to come up with any scenario where Ubuntu would be forced to divulge a private signing key because a third-party computer manufacturer or distributor shipped Ubuntu on a Restricted Boot machine.

That's because like pretty much everyone who is not the FSF, Ubuntu has not actually carefully read the part of GPLv3 that deals with software that requires signing in order to install. Almost everyone just seems to skim through that section, sees something about having to provide keys, and then moves on. They don't read the definitions that define the terminology used in that section, and so have no clue whatsoever about what they have just read means.

I can kind of excuse it when it is just random end users or individual software developers who don't understand the license they are using...but one of the leading Linux companies!?

Another place you see this problem is in discussion of the incompatibility between Apple's App Store and GPLv3. There are people who still think the signing requirements have something to do with it. They do not. The problem is Apple's terms and conditions, which Apple requires end users to agree to before being allowed to use the store, count as additional terms under GPL (both v2 and v3) that are incompatible with GPL. The GPLv3 restrictions on distributing signed code without the signing keys would only apply to GPLv3 code that Apple ships bundled with iOS devices.

rlpb• 14 years ago

> That's because like pretty much everyone who is not the FSF, Ubuntu has not actually carefully read the part of GPLv3 that deals with software that requires signing in order to install [...] I can kind of excuse it when it is just random end users or individual software developers who don't understand the license they are using...but one of the leading Linux companies!?

Please give them more credit. Apparently, they have even discussed it with the FSF. From https://lists.ubuntu.com/archives/ubuntu-devel/2012-June/035...:

Edit: failing to quote this sensibly.

In response to: "Have you talked to the FSF about their position on this? They're the sole copyright holder of grub 2, so any position they'd publicly take would be pretty relevant in terms of potential legal action."

The reply: "I haven't been privy to all the mails on this, but in the ones I saw, the responses were distinctly equivocal at best. They certainly didn't say that we were safe, rather the reverse."

einhverfr6• 14 years ago

I think the problem is it doesn't matter how carefully you read the GPL v3, you still can't understand it. The license is complex and inconsistent in important ways and applied mechanically and literally leads to bizarre conclusions (such as that it is incompatible with the BSD-style licenses but not the MIT license).

I have discussed this matter both with folks like Richard Fontana (involved in SFLC, general counsel for Red Hat, and one of the drafters of the GPL v3) and Eben Moglen (SFLC, FSF, and one of the drafters of the GPL v3) and their understandings of key provisions was not only different but incompatibly so.

Here's the problem: the SFLC's official view, which is also the view of many developers who use the BSD-license, is that the BSD license does not allow a license change on the original code, but only allows restrictions to be placed on new code. Therefore if you write a program and release it under the BSD license, I can change the license to the GPL (any version) when, and only when, I actually make copyright-worthy changes to the code. Anything short of that and I am impermissively sublicensing your code, as prohibited in US copyright law. Now, slowly read the GPL v3, section 7, on additional terms.

Section 7 outlines a few areas where additional restrictions are permitted, and also addresses additional permissions. Since the work as a whole must be licensed according to the GPL v3, this would apply to any modules the work is dependent on, by the terms and definitions of the GPL v3, and additional permissions must be removable without changing the code. Earlier drafts allowed these permissions to be removed only when changing code but this was removed in a later draft. The BSD license does not allow this, and therefore it is incompatible. OTOH, the MIT license does allow it and so is compatible. Oops.

Except that everyone agrees the licenses are compatible. Moglen says that basically you can claim anything you want but nobody can sue you for it (sorry, I am not betting my house on that). Fontana says that the license was intended to be compatible and therefore must be read to be compatible, that one cannot safely convert BSD files to the GPL without modifying them, and that the GPL v3 should be read to accommodate this restriction. What a mess that opens up. Now we have to read the GPL as explicitly authorizing things it says it does not authorize.

So given my time trying to figure the GPL v3 out (and I have slowly read it more than a few times) I will give Ubuntu the benefit of the doubt here. The GPL v2 has problems too, but I would pick the problems of a license which is, perhaps, too simple over one which is undeniably too complex.

Now, my reading of the GPL v3 here is that Ubuntu would only possibly be off the hook but every distributor of Ubuntu-certified computers would have to release their keys. Moreover I am not convinced entirely that if a distributor failed to that Ubuntu could not be held accountable. If it's copyright infringement, Ubuntu is a vicarious infringer unless they did everything reasonably within their power to stop it. They have the power to require the vendor to distribute the keys, and they have a financial incentive. That makes them responsible. Worse if they told any distributor "you don't have to distribute your keys" that might make them guilty of Grokster-style contributory infringement.

I am not convinced Ubuntu would be safe at all. More likely depending on what was in the agreements, they might be held accountable along with the distributor.

AmazingBytecode• 14 years ago

Wait, users can install new keys on their machines? What's the issue then?

gpvos• 14 years ago

Please read more thoroughly.

1) If the user can, but is scared away by a disingenuous message saying "Do you want to make your computer less secure by installing a non-Microsoft key (y/n)?", that would still be bad.

2) They can't on ARM-based machines that have a Windows certification.

recoiledsnake10• 14 years ago

>They can't on ARM-based machines that have a Windows certification.

You cannot install an alternative OS on an iPad either which comes with a locked bootloader. Why is this such a big deal on Windows RT tablets only?

cs7022• 14 years ago

One possible solution to this problem is for the FSF itself -- or perhaps another non-profit organization with similar goals but a more flexible stance -- to get in the business of issuing Secure-Boot keys, backed by a public written policy of non-discriminatory key issuance. Such an organization could work with non-mainstream operating systems to get hardware vendors to adopt its keys. For example, Ubuntu and Red Hat could use keys issued by it.

All non-mainstream operating system projects would be able to request keys from this organization and boot without having to resort to tinkering in UEFI hardware from multiple vendors.

One can dream.

sounds• 14 years ago

Just assuming that the current UEFI working group agreed to this, the first problem arises when one of the key holders is compromised.

As a possible scenario: what if the Windows 8 private signing key leaked because it was used in Terminal Server somehow - do you want the FSF revoking the Microsoft signing key, thus invalidating UEFI signed drivers (necessary for boot) from hundreds of OEM's?

We can shortcut all this by supporting www.coreboot.org

cs7022• 14 years ago

sounds: coreboot.org is a worthwhile cause but unfortunately, for better or worse, whether we like it or not, most hardware vendors have decided to adopt UEFI.

tapoxi• 14 years ago

I have a CR-48 and it already solves this problem. Joe User get a secure, verified boot path by default. If you want to bypass this and use your another operating system, load your own keys, or generally prove that you know what you're doing, you:

1. Flip the machine over. 2. Remove battery. 3. Flip the "developer's mode" switch.

cooldeal5• 14 years ago

How is that much different from flipping this switch in the bios settings?

http://www.windowsfordevices.com/images/stories/samsung_secu...

Also, anyone having physical access to your Chromebook can flip that switch and compromise your machine. While you can set a bios setup password to guard against someone flipping the secure boot switch.

stcredzero5• 14 years ago

> Also, anyone having physical access to your Chromebook can flip that switch and compromise your machine.

Gain physical access to Any machine, and all security bets are off.

> While you can set a bios setup password to guard against someone flipping the secure boot switch.

Actually, that's a good point. But what if the attackers has physical access and simply reflashes the BIOS?

jtsagata3• 14 years ago

Do we really need UEFI? I believe that there is simpler ways to achieve this. For example:

a. User turn ON a switch to enter "OS Install mode"

b. User install the OS of his choice. During installation the installer read a motherboard specific key from the BIOS and sign his bootloader/kernel/drivers using that key.

c. User turn OFF the "OS installation switch". System is save (at least as long as the OS in choice is not a Redmnond one)

Is there any fundamental problems with this approach?

wtracy• 14 years ago

It seems that UEFI is supposed to protect against malicious actors who have physical access to your machine.

Of course, you're also assuming that securing the end-user is the actual goal of UEFI. ;-) I can see legitimate situations where a corporation would want to ensure that their employees aren't tampering with their hardware.

Of course, I think it's fairly obvious by now that one of the main reasons that MS is pushing UEFI at this point is to prevent Android from being installed on "Windows" hardware.

jtsagata3• 14 years ago

If someone have physical access to my machine he/she can install keys if the BIOS supports that anyway. And even if it doesn't i have many more things to worry anyway. UEFI don't protect me from stealing the machine or the HD data or installing mallicius software.

Of course, i totally agree with you on that the reall reasons is for MS and hardware manufactures is trying to control MY hardware.

sseveran• 14 years ago

If this is such a huge deal and users don't like it then there should be a market for machines that are not Windows Logo certified and run Linux. Given that there does not seem to be such a large market maybe those people that want to install linux on their desktop would be willing to pay more for the opportunity to do so.

Sandboxing has become increasingly popular and Microsoft is really the last one to the party. Most users (myself included) are happy with sandboxing. Apple has implemented this with great effect across its ecosystem.

All the actors are private organizations. No one is forcing anyone to buy a computer that enforces any of these restrictions. The FSF should try to understand why if this is such an important issue there does not seem to be a large market for Linux desktops. If there is a private actor can step in and provide the machines. If not, then you can always build your own.

One thing that will be interesting to see is if GPLv3 software slowly withers given that many embedded device makers will be unable to use it. I guess another cause may be Apple's continued rise as a platform of choice for both tablets and desktops/laptops.

wmf2• 14 years ago

maybe those people that want to install linux on their desktop would be willing to pay more for the opportunity to do so.

But they're not. Desktop Linux can't win in the market, so they're trying to change the rules by whining.

recoiledsnake10• 14 years ago

>We will fight Microsoft's attempt at enforcing Restricted Boot on ARM devices like smartphones and tablets. Like any other computer, users must be able to install free software operating systems on these devices.

Again, a multi-thousand word essay on the topic of secure boot and lambasting Microsoft about the locked bootloader in the ARM tablets(which many of the same people think are going to crash and burn anyway).

Meanwhile, like in the RedHat and Mozilla blog posts about secure boot, not a peep about Apple or the iPad's locked bootloader which runs about 80% of ARM tablets.

Is this because Apple makes their own hardware so the FSF does not care? Or is it just their PR strategy that attacking MS is preferable due to media and people's favorable perception of Apple?

giZm03• 14 years ago

It is Microsoft that is pushing this.

recoiledsnake10• 14 years ago

I am referring to the criticism about ARM devices that Windows RT runs on, not about the x86 version.

tmzt• 14 years ago

I see your point, the simple fact is dual-booting Linux-based operating systems on hardware intended for use with Microsoft Windows is the norm, and without this source of computer systems a free license is nearly a moot point.

If ARM becomes dominant the idea that Microsoft can simply restrict access because that's how it was done in the past (even citing Apple as an example) simply means they can restrict a majority of all hardware sold from running a different system, extending their monopoly control through partnership agreements to a new generation of hardware.

Generally, PC compatibles boot an OS from a sector on the hard drive and provide a standard interface to the bootloader to hardware (BIOS, PCI enumeration, and now UEFI). While ARM is now beginning to adopt a similar boot system (in UEFI on RT devices) it's not carrying with it the openness we once enjoyed with PCs. This is the problem.

recoiledsnake10• 14 years ago

>If ARM becomes dominant the idea that Microsoft can simply restrict access because that's how it was done in the past (even citing Apple as an example) simply means they can restrict a majority of all hardware sold from running a different system, extending their monopoly control through partnership agreements to a new generation of hardware.

If iPads take over computing and desktops(along with Microsoft) die, won't the same scenario play out? Also, if ARM becomes dominant, won't a secton of the ARM devices be iPads and Android tablets? Why do you think Windows RT tablets will be the majority?

>While ARM is now beginning to adopt a similar boot system (in UEFI on RT devices) it's not carrying with it the openness we once enjoyed with PCs. This is the problem.

As an aside, ARM is different in the sense that each ARM SoC needs special drivers and coding.

streptomycin• 14 years ago

You write as if the FSF never criticizes Apple. To the contrary, they criticize them all the time: https://www.google.com/search?q=fsf+apple

Would you be satisfied only if every article complaining about the actions of one company also listed every single other company that has done something similar? That would be tedious, as the FSF has criticized lots of companies for crap like this.

giZm03• 14 years ago

Is secure boot really gone stop any malware? It will surly make it harder for anyone else to use a different OS. I mean malware is really a huge problem but isn't the majority of it, not related to bootloader.

cooldeal5• 14 years ago

>It will surly make it harder for anyone else to use a different OS.

Is it really that hard to go into the bios settings to change a setting? Already most people who want to boot a different OS have to do that to change the boot order to boot from DVD first.

http://www.windowsfordevices.com/images/stories/samsung_secu...

lunarscape• 14 years ago

Except MS specified that's not allowed on certified ARM devices.

stcredzero5• 14 years ago

For security purposes, wouldn't it be enough for the mechanism to simply display a change in the signing status, and not restrict boot? This would allow for the detection of malware without restricting how people use their hardware.

Displaying or dismissing such a notification needs to be built into the hardware in such a way that the OS wouldn't be able to interfere. There should also be a read-only channel for applications running on the OS to access the signing status to enable security programs.

MichaelGG• 14 years ago

It's pretty well agreed that notifying the user and allowing them to dismiss the notification is a useless security model.

stcredzero5• 14 years ago

Which is why you also have the ability for security programs to access the same information.

FSF recommendations for free OS distributions considering Secure Boot

Related Stories