痞酷網_PIGOO

 找回密碼
 立即註冊
!!! [系統偵測到廣告阻擋軟體] !!!

如果您覺得痞酷網對您有些許幫助,或者您認同痞酷網的理想,

那麼希望您將痞酷網設定為白名單.

並請在上論壇的時候,動動您的手指,用行動支持我們.

謝謝!
查看: 4408|回復: 1

[轉貼]万恶的UEFI Secure Boot

[複製鏈接]
發表於 2013-4-8 21:02:38 | 顯示全部樓層 |閱讀模式
首先先強調一下,大家都有使用心目中理想的作業系統,因此,不管你是使用 MAC、MS、FreeBSD、GNU/Linux 我想這都是個人的喜好。

也因此,相互的尊重別人使用的作業系統是必然的,我絕對沒對使用 MS 系統的人不尊重!只是對 MS 的一些小手段很給它不是普通的那個....

相信現在的電腦都使用 UFEI 來取代傳統的 BIOS 了,這對除了 Windows 外的作業系統來說,真的是很給它不是普通的 “X"。

尤其是對 GNU/Linux 來說,在這類主機板上安裝雖然有變通的方式,但總是有種想法,MS “XXX” 如何有這種決定性的權力。如何有權力決定大家要使用何種作業系統 XD

以下文章轉貼自 LinuxToy,讓大家了解一下背後的真象,讓我想到一些名嘴的名言:“惡魔都藏在細節處”:

MS 的這招很惡質,若是想要裝 WIN 8,,那麼請使用 UEFI 吧,開個玩笑,幸好 WIN 8 反應不如預期 >_<

-- 轉貼內容 --

Matthew Garrett 在博客上阐述了最近关于 Fedora 18 在 UEFI 支持方面的一些动向,表示 Fedora 有可能会采取支付 $99 的方式获得 M$ 签名的第一阶段引导器,从而允许最终用户在不关闭 Secure Boot 的情况下引导。

今年下半年发布的 Win8 将要求 UEFI 中启用 Secure Boot 模式,届时所有带有的 Win8 认证徽标的硬件也将包含一组 M$ 公钥,不局限于 OEM。这将给包括 Fedora 在内的所有 Linux 发行版的安装带来不小的麻烦。怎么办呢?

一个直接的解决方法是和厂商合作在硬件中添加特定 Linux 发行版的公钥。这对于有 Red Hat 支持的 Fedora 来说并不是件难事,但是这样子做的话对其他没有长期硬件合作关系的发行版诸如 Arch、Gentoo、Mint 等是不公平的。同时由于难以让所有的硬件厂商都包含该公钥,又会无形的增加消费者选购 Linux 兼容硬件产品时的麻烦。

另一个方法是创建一个通用的 Linux 公钥。这意味着需要有一个可靠的组织掌管所有的 Linux 发行版密钥石,并且对签名请求进行必要的审核工作。这花费巨大,在短期内也是不现实的。

第三个方案,尽管不理想,但在目前看来是可行的。M$ 将在它的 Sysdev Portal 上提供付费的签名服务。在支付给 Verisign $99 并审核通过之后,将使用 M$ 的密钥进行签名,不限次数,使得其可以在具备 M$ 公钥的设备上运行。Fedora 打算将利用此对一个特制的初始阶段引导器进行签名,从而使得最终用户无需进入 UEFI 做任何更改即可顺利引导并安装 Fedora 18。

这种便利,除了那 $99 以外,还有其他代价的。

会被用来签名的初始阶段引导器将设计的十分简单,仅仅用来链式引导真正的 GRBU2 引导器,从而避免每次引导器升级的都要找 M$ 机器签名的麻烦。不过由于 UEFI Secure Boot 的要求,GRUB2 的动态加载和部分内核参数编辑功能将被禁用。

同样是由于 UEFI Secure Boot 的要求,所有可能会用到内核模块也需要签名。对于 Fedora 分发的内核树中模块自然是没有问题的,但是对于像 AMD 和 NVIDIA 之类安装时动态编译内核模块的闭源显卡驱动来说则极为麻烦。

需要自己编译内核的用户,则不得不使用 Fedora 提供的工具和文档,生成自己的公钥并将其添加到 UEFI 固件中,然后对编译的内核和引导器重新签名。若希望他人也能使用自定义的内核,则不得不像 Fedora 一样花费 $99 使用 M$ 的签名服务。

另一方面,M$ 对于在 ARM 平台上 UEFI Secure Boot 策略没有改变,意味着预装 Win8 ARM 的设备将不能关闭 Secure Boot 模式,也不能自己添加公钥。虽然理论上 Fedora 也可以像 X86 一样付费获得 ARM 版本的 M$ 签名认证,但是这样一个丝毫不允许内核级别自定义的 Fedora ARM 意义甚微,故放弃。

受不了这些限制和麻烦?

没问题,只要关闭 UEFI 的 Secure Boot 模式一切就和当下一样了,但这将意味着无法启动 Win8 系统,包括已经安装的,双启动成为过去时。

无论有没有世界末日,M$ 都会在 2012 年底逼迫最终用户在 Win8 和全功能的 Linux 系统之间“做一个艰难的决定”。

值得注意的是,Fedora 的这项方案目前处于讨论阶段,尚不清楚 M$ 方面对此会有什么样的反应。

名为安全,实为垄断

UEFI Secure Boot 带来这么多麻烦,那么它到底能起到什么作用呢?

它无法让您正在运行的系统更健壮,也无法抵御病毒对引导器的修改。它唯一能做的就是当机器的引导器已经被病毒修改之后,给出提醒并拒绝启动,避免可能带来的进一步损失。

没错,只有这些。没有办法恢复原先的引导器,没有办法动态加载任何杀毒或者数据挽救模块。或许届时您可以选择拨打 M$ 或厂商的客服获得解决方案,或者也可以选择购买必然会出现的某些经过 M$ 认证的特制修复引导盘。介于 $99 的存在,这些恐怕都不会是免费的。

难道这是 M$ 想要的效果?

场景:当 UEFI 提示引导器被修改,拒绝引导系统时,机器停滞在错误屏幕上,面对一切尝试修复的举动毫无反应……
用户:“我都不知道该用什么表情来面对了……”
M$:“微笑就可以了。”

文明用语!!!!

或许,是时候考虑加入 Free Software 基金会发起的反对 Secure Boot 的签名活动了。

补充说明

根据 M$ 的规定,Win8 仅能在 UEFI Secure Boot 开启时引导。已经安装好的 Win8 系统在关闭 UEFI Secure Boot 之后也不能引导。

Secure Boot 要求所有需要访问 PCI 地址的行为都要经过签名,而它的格式限制了一个程序或设备仅能被具有单一签名。这对于硬件厂商意味着什么?

若是板卡和驱动所用签名并未包含在主板的 UEFI Secure Boot 公钥库中,用户将无法使用该板卡。
唯一能保证板卡和驱动被广泛使用的方法就是像 Fedora 一样使用 M$ 的付费签名服务,因为预期只有 M$ 的公钥会被包含在绝大多数主板中。

从目前公布的内容来看,并不清楚 UEFI 中的 SB 是否是一个可以任意开关的选项:

It shall be possible for a physically present user to use the Custom Mode firmware setup option to modify the contents of the Secure Boot signature databases and the PK. If the user ends up deleting the PK then, upon exiting the Custom Mode firmware setup, the system will be operating in Setup Mode with Secure Boot turned off. The firmware setup shall indicate if Secure Boot is turned on, and if it is operated in Standard or Custom Mode. The firmware setup must provide an option to return from Custom to Standard Mode which restores the factory defaults.

“仅能通过删除 PK 的方式关闭 Secure Boot”,“仅能通过恢复出厂设置的方式开启 Secure Boot”,这种操作也是符合 M$ 规范的。过往的经验表明厂商倾向于给固件中最精简的功能,这很可能是他们会选择的方式。

破解 ROM ”拯救世界?醒醒吧,亲……

是 M$ 限制了 Win8 不可以在 Secure Boot 关闭情况下启动,不是主板厂商。
主板固件的开发难度可不一般,从 OpenBIOS 的缓慢发展可见一斑。

小贴士:尽管常常混用,实际上固件和 ROM 可是两个完全不同的东西哦~固件负责的是最底层的硬件沟通,常见的 Android 自定义 ROM 中也仅仅是重用了从厂商官方 ROM 提取的固件而已。
 樓主| 發表於 2013-4-8 21:07:30 | 顯示全部樓層
看看如何在 UBUNU 下的一些 UFEI 設定方式:
https://help.ubuntu.com/communit ... the_HDD_in_EFI_mode
您需要登錄後才可以回帖 登錄 | 立即註冊

本版積分規則

關閉

站長小叮嚀上一條 /1 下一條

禁閉室|手機版|連繫我們|痞酷網電子技術論壇

GMT+8, 2024-4-18 06:59 PM , Processed in 0.078989 second(s), 20 queries , Gzip On.

Powered by Discuz! X3.4 Licensed

© 2001-2023 Discuz! Team.