11–20 of 80 posts
It costs $99 to sign the software. I'm sure most of the distros can afford that (unless they take a die-hard stand, in which case, just don't buy a Windows pre-loaded PC from the OEM that disables the option to run Linux with).
Some of us are not okay with one company charging a gatekeeper fee for access to hardware we already bought from a different company.
I think we should give credit where it is due, MS is really trying to work with OSS community.
Also, a lot of enterprise customer would want always on secure boot, and it is up to OEM to decide whatever they want. How is this MS's fault?
I don't really understand the concern here. Microsoft is simply saying it's optional for its hardware partners to display the option to toggle it. I could see plenty of enterprise systems wanting to not allow users to change this setting. Microsoft isn't trying to block anything here. If you want to use linux simply vote with your dollar and go to the vendors that will let you install it (I imagine most will). That o…
The problem was IIRC that you need something signed with MS key to be able to boot whatever. If you are able to set your own keys - then there is almost no problem (still usb flashes and so on will be harder to boot)
Earlier quoted context omitted.
The problem was IIRC that you need something signed with MS key to be able to boot whatever. If you are able to set your own keys - then there is almost no problem (still usb flashes and so on will be harder to boot)
> If you are able to set your own keys - then there is almost no problem Doesn't this make the feature useless from a security standpoint? If you're able to create your own keys then malware could create its own keys. Maybe if manufacturers could do it that would be handy.
Ubuntu, Redhat, and other distros are compatible with secure boot. I understand the concern, but the flip side is that if secure boot makes my future Ubuntu laptops more secure that could be a good thing. Linux is here to stay. Relax.
How many times has a virus latched onto your computer by executing before your system booted up? I've never heard of this happening to anyone I've ever known.
The only scenario I can imagine is having a PC set to auto-boot from peripherals, and a USB key having something bad execute before invoking your hard disk's boot loader. And that is obviously possible, but terrifying more complex to pull off. But that seems a lot more like a local, physical attack that's much less useful and more targeted than your ordinary viruses that install after executing inside your OS, where viruses seem to have no problems pulling off privilege escalation exploits to gain kernel access then. Plus you can easily block this and then lock down your BIOS already.
It really seems like Secure Boot is solving a problem almost no one ever had. I may well be misunderstanding the point, so please elaborate on how this is useful and absolutely prevents a class of attack that could not be done otherwise.
One possible direction the industry could go in (suggested by Win 8) is that the "laptop" as we know it could be replaced by tablets, and potentially these could be very low cost devices.
The fly in that ointment is that vendors are not that excited about selling inexpensive machines. For instance, going with the "only a USB 3.1 port" approach would make a lot of sense for a cheap tablet but Apple did it first on a premium laptop because the PC industry had a "who moved my cheese" freakout over Win8 and at the moment the industry has abandoned the race to the bottom.
These super-cheap devices will have very different economics (they'll get a free or cheap Windows license) so a major change in the contract between manufacturers and users is possible.
The negative impact is not on the average Linux user who just runs a distro, but it will be bad for anyone who wants to compile and run their own kernels.
It costs $99 to sign the software. I'm sure most of the distros can afford that (unless they take a die-hard stand, in which case, just don't buy a Windows pre-loaded PC from the OEM that disables the option to run Linux with).
And who gets that $99? Microsoft. Some of us are not okay with one company charging a gatekeeper fee for access to hardware we already bought from a different company.
Ubuntu, Redhat, and other distros are compatible with secure boot. I understand the concern, but the flip side is that if secure boot makes my future Ubuntu laptops more secure that could be a good thing. Linux is here to stay. Relax.
Serious question: how does Secure Boot make you more secure? How many times has a virus latched onto your computer by executing before your system booted up? I've never heard of this happening to anyone I've ever known. The only scenario I can imagine is having a PC set to auto-boot from peripherals, and a USB key having something bad execute before invoking your hard disk's boot loader. And that is obviously possibl…
http://www.theregister.co.uk/2010/11/16/tdl_rootkit_does_64_...
http://www.computerworld.com/s/article/9217953/Rootkit_infec...
A snippet:
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