Why would you even have secure boot enabled on a Windows 7 system? Three of my machines have ASUS Motherboards and Secure boot is disabled and other OS is selected. Enough of this nonsense Microsoft fecking with Windows 7 user base.
A recent Windows 7 update partially bricks computers that have an Asus motherboard fitted, it emerged this week. Windows 7 machines that have installed Microsoft's KB3133977 update may trigger a "secure boot violation" during startup, preventing the PC from loading the operating system, Asus said. Though the KB3133977 patch …
"Why would you even have secure boot enabled on a Windows 7 system?"
It's supported by default on newer Asus motherboards but Windows 7 doesn't use it. The update makes the firmware think Secure Boot is supported by the operating system, but really the OS cannot/does not ultimately provide the signatures needed, so the boot fails.
I suspect - and we're waiting for more info from Microsoft - that the updated BitLocker drive encryption code that loads before the OS is run is cocking up the process: the firmware believes it's booting a Secure Boot OS but it's really not. Possibly.
I have an Asus P9X79 Pro motherboard, and I installed on it Windows 7 a couple of years ago with the default secure boot settings (enabled) and it worked fine until I installed the update. Then the message stating the secure boot checks failed appeared.
I sent The Register a mail about it days ago, before it became an update installed by default. There were already threads about it in Microsoft support forums, thereby Microsoft was well aware of it and I'm "very surprised" it decided to make it installed by default knowing it would have caused not a few PC not to boot. Unless it was exactly another way to nag user to install Windows 10.
Moreover, secure boot failure message are not really very informative and helpful.
BTW: the way you disable secure boot on Asus boards may depend on the model and UEFI interface.
Um, i think you'll find people have been posting without reading the article for years.
This is about a feature that asus put on old pcs. Is also about the grief ms get for trying to support relatively ancient systems (if you have an android handset you know how quickly a machine can become outdated). It's not about ms trying to stop you installing linux.
"This is about a feature that asus put on old pcs. Is also about the grief ms get for trying to support relatively ancient systems (if you have an android handset you know how quickly a machine can become outdated). It's not about ms trying to stop you installing linux."
Fair point, but they clearly didn't do adequate regression testing and the guys doing the work clearly didn't understand the full implications of what they were up to. I would have thought a multibillion dollar multinational that took an active part in developing SecureBoot would be capable of getting this right before release. It's not as if they're short of skilled devs & cash to pay them.
No, siree! An honest to God and trusted company like Microsoft would never dream of locking the PC hardware and prevent you from installing Linux. They are just trying to prevent you from installing anything but what they want you to have on their PC (I said their PC because with them controlling the boot process the computer is no longer yours).
Fixing the UEFI BIOS by disabling secure boot (setting it to "Other OS") worked, BUT:
That still left me with two notices that appeared at boot, both of which I had to click through. One said, <Asus Setup C:\Users\******\AppData\Local\Temp\211540Log.iniis lost> and the other was identical except that it referenced 211241Log.iniis lost>.
More Googling suggested entering Task Scheduler and deleting or disabling the i-21 entries. I did so and disabled them both; upon reboot both notices were gone and did not return. Whee! Note I went to Control Panel\Administrative Tools\Task Scheduler, not Task Manager.
"A recent Windows 7 update partially bricks computers that have an Asus motherboard fitted, it emerged this week."
Either it bricks them or it doesn't. Reading the article implies it does nothing of the sort. And it's not a Microsoft issue.
"Microsoft half-bricks Asus Windows 7 PCs with UEFI boot glitch "
So actually it's more like "Asus Windows 7 PCs fail to boot due to UEFI bios glitch" - but I guess that wouldn't get as many clicks?
The answer is simple - be like that California woman (see http://www.theregister.co.uk/2016/06/27/woman_microsoft_windows_10_upgrades/) and take them to the small claims tribunal where they are prohibited from sending along a lawyer (but make sure their representative has no legal training because you can be fairly sure that they will try that trick if they think they can get away with it).
You are then on equal footing with one of their sales droid and in front of an judge who only has to decide on whether the "patch" was fit for purpose
This post has been deleted by its author
You mean like clean installs of windows 7 that when you install updates, you end up with a borked windows update subsystem that takes major messing around with the get working again.
Seen this exact behaviour on about 20 rebuilds now. It happened around about the same time as windows 10 nagware propaganda started. It's as if they didn't want me trying to fix win7 windows update and install windows 10 instead.
I just got a brand new laptop and the manufacturers advised not to use Linux because the drivers might not be available - stuck the latest Xubuntu on it and everything works like a dream. There are a couple of proprietary drivers on offer but I haven't bothered to find out what they do to see if they're worth installing.
Only heard of one machine with a driver problem under linux lately and that was where the bios/uefi had a bug so a quick update and sorted.
"I just got a brand new laptop and the manufacturers advised not to use Linux because the drivers might not be availableI just got a brand new laptop and the manufacturers advised not to use Linux because the drivers might not be available"
That's just fscking laziness on the part of the manufacture. What would it cost them to do a test install of a few popular Linux distros and maybe a couple of xBSDs and then advertise that such and such an OS, version x.x was tested and worked ok with all the inbuilt hardware. They don't have to care about updates or new/old drivers. Just that it worked with a specific version. They already do that with Windows and to a far greater extent so they can have the special permission from MS to put a sticker on the case.
It may or may not generate lots of sales, but I bet it would at least generate enough to more than cover the day or two it would take to run some simple tests.
> There is always an alternative to Windows that is not Ubuntu.
What a dumb statement. There's always an alternative to something if you don't need it. Like starving to death is an alternative to eating. But it's not a *good* substitute.
Likewise, while there are other OSs besides Windows, there are a ton of valuable Windows applications that do not run on other OSs, and don't have compatible substitutes if even any substitutes Since people who are not hermits and use their computers for work often have to share documents with Windows users, an incompatible "alternative" won't suffice, either.
What would be nice is a genuine fully-compatible Windows substitute that could run all Windows applications, but Microsoft has gone to great lengths to make that virtually impossible. WINE is a cute toy but doesn't cut it in the real world of business computing.
What's all with the negativity !
Look you are complaining that's there is no alternative but you are not going to try any other OS ?
How do you think that MS became so popular, because people used it !
Now you want a completely compatible OS to windows that can run all your Windows software etc, then use Windows and be damned !
You state almost like its factual that there are a ton of Windows applications that do not run on other OS's, well in a Windows VM running under Linux I dispute what you say !
Also many businesses are capable of using the various Office software's that are available on Linux and there are several Libre Office, WPS Office and several others here's a link for a review on Office software on Linux but you have to remember that t was done in 2013 and Linux has come on leaps and bounds since then. http://www.techradar.com/news/software/applications/best-office-suites-for-linux-5-reviewed-and-rated-1146417/1
There is always an alternative to Windows that is not Ubuntu.
Agreed. How many times have I said it in the past...
Linux is NOT Ubuntu. Nor is it Mint, RedHat, SUSE, Debian, Arch, Gentoo, Puppy, Slackware or any other distro you care to mention. If anything, distro evangelists do more damage than good when it comes to situations like this.
This happened to me with a Z97-A mobo that had been happily working in UEFI mode with Windows 7 for a year. The answer given by Asus seems a bit extreme - to keep UEFI mode but disable secure boot, the Delete PK option deletes the Secure Boot keys - at least, I think that's what I did. The Asus menus didn't have a simple enable or disable secure boot option and it took a bit of digging in key management before I found an option that warned me secure boot would be disabled if I proceeded.
I don't remember ever setting up a secure boot option when I built the PC but as it's not supported in Windows 7 and it booted, I assumed all was ok!
I had the same on my home PC a few weeks back. Hours of hair pulling to figure out what was wrong. Fixed it, then last week two "home-brew" number crunching machines at work (bought in from specialist builders and that moved to our centre with a research group) went the same way. The BIOS screens were vastly different from mobo to mobo though, making it hard to find exactly where to make the tweak - on mine it was under advanced boot settings, on the other two it was under security on one and advanced settings - key management on the other . Anyway my reputation as a miracle worker upheld.
Same happened to a friends PC, however, the problem was blamed on a recently installed game, and hence hours of looking in all the wrong places.
A quick internet search brought up a youtube video that hadn't got a tenth the way through its explanation, before the secure boot light bulb turned on.
Never encountered it before, and yes my WIN 7 machine has it enabled too, but it is air-gapped from the net, and hasn't had any updates for years, hence it was a new one on me.
Pity he saw me cribbing from the net, otherwise my genius status, would have risen a few notches.
Still, as long as some friends continue to refuse to go down the Linux route, I can always count on getting free beer and snacks every other week, from despairing Microsofties.
If the mobo has Secure Boot enabled, that infers it'll boot in UEFI mode, which implies either an entry in the firmware's boot menu, or the boot device has a removable media (simple) boot path loader at /EFI/BOOT/BOOTx64.EFI in an EFI System Partition, and that the boot-loader has a signing certificate indicating it was signed by a key trusted by a Certificate Authority embedded in the firmware.
It sounds as if the Asus firmware is doing something that isn't in the UEFI specification - namely when Secure Boot is enabled it isn't actually enabled so much as *optional* - if the initial boot-loader stub it reads doesn't have a signing certificate attached the firmware will boot with Secure Boot disabled.
If the MS KB3133977 update contains a boot-loader that is signed that would trigger Secure-Boot mode, but when the next stage is loaded and is found not to be signed it throws the reported error.
If this is correct then the Asus firmware could very easily mislead a user into believing a Secure Boot happened with an OS that does support Secure Boot when it didn't - any malware or physical intervention could replace the initial EFI stub with an unsigned version and the system would boot without a warning.
I hope this hypothesis is proved wrong else that's a big security FAIL on Asus' part.
If you're interested in the attack vectors I recommend reading this Intel & Phoenix "UEFI Secure Boot in Modern Computer Security Solutions" paper  and footnote 1 on page 7 and its reference 21 link to the Blackhat USA 2013 paper "A Tale of One Software Bypass of Windows 8 Secure Boot" .
If your hypothesis is right* then someone at a vulture desk will owe MS an apology for the title of this article. It would in that case be Asus causes some of its motherboards to crash** after faulty UEFI implementation.
* I have nothing to add on that point.
** Brick is the wrong verb here.
Windows 7 works fine with UEFI - so long Secure Boot is turned off. It also refuses to boot the installer if SB is turned on. Saying that, 8.1 and 10 work fine with SB off. My box dual boots Mint 17.3 and Win10 Education (it was free via Dreamspark). Both of which play nice with Secure Boot. However there are two reasons I don't use it - I can't be bothered derping about to get rEFInd signed so Secure Boot doesn't throw a wobbly, and it doesn't like my Radeon 6850 X2, even with the GOP ROM flashed onto it.
How many users know how to get the BIOS/UEFI at start up? This type of screw up makes one trust Slurp even less. I have seen something similar with a dual boot laptop (W8.1/Linux Mint) after a Winbloat update reset the UEFI settings which disabled the dual boot. Easy to fix if one knows how but not something I expect must users to have a clue about. Nor should they need to have a clue in their defence.
Secure Boot is INTENDED as an enforced [Trust Chain]? between UEFI bring-to-life routines completion and Modern Windows own Boot.
Anything else [Even Win7 at some cases], could become liability.
By the way, Linux is effectively a missing member of UEFI. And that is inadmissible.
Agreed, "Secure" was a politically correct way to say "even more lock-in to M$".
But I discovered, having recently bought an Asus mobo that they did a fine job. On top of being able to switch to good old "Legacy mode" (aka BIOS) and disabling "Secure" boot, apparently you can also import your own set of keys (didn't try, but it looks like you can).
That was what EFF (or the likes) asked to make "Secure" boot acceptable, and not locked-in. Because that fact that Canonical or Redhat have to ask for a signing key to M$ in order for they OSes to boot is really bad; If you are able to change the keys, you can even compile your own flavour of Linux/FreeBSD, optimised to your hardware, and self-sign it with your own keys.
If it really works as it looks like, then Asus did a fine work!
Wouldn't it be nice if Microsoft would just stop messing with people? Breaking their stuff, forcing their updates, taking away features they already paid for?
But they won't. People tolerate this behaviour. Consumers and businesses are so committed to Windows they will never leave. So Microsoft can do anything they want. And they do.
It's the way it's always been.
I don't think it's commitment so much as mass resignation/ignorance/indifference... for the individual consumer certainly... and I'm quite certain M$ understands this perfectly. M$ knows its OEM lock-in operation is the lifeblood of its racket.... and would sooner strangle the last gasps of life from the PC industry than loosen that grip.
Alright, I give up. Where'd you get that icon?
If you look at the source it's a Reg icon, but not one that us plebs can see when using the "select an icon" interface. If you were keen enough you could try copying the HTML into a post and see if it works, but my guess is that it won't for you and I. Worth noting that the AC also has an icon, again something blocked for the masses.
Could it be the Reg staff, using comments to say things or use language they can't in the article....
there are people who still believe Secure boot is about security, they are either in denial or plain dumb.
Secure boot is about controlling your PC. With it Microsoft can prove to content and software vendors that your PC can be trusted (by them of course) and that their DRM can not be subverted.
will be for MS to send out an update that borks ALL systems from booting that don't (or can't) have secure boot enabled.
Then all those free upgrades will suddenly turn into paid ones as the PC makers see a sudden rise in demand.
Well, I would not put it past MS for at least considering this as a way to turn the W10 revenue stream from a trickle to a veritable torrent.
Because computers didn't work properly with BIOS.
Computers did, of course, work properly with BIOS.
Well, if they didn't (and most didn't, at least some of the time) it usually wasn't the BIOS's fault.
UEFI is veritably the road to hell -- paved with good intentions. The good intentions are many: It's supposed to support booting from hard disks that are larger than a BIOS can handle. It's supposed to provide a mechanism whereby a an x86 PC can boot straight into protected mode, so the chip makers can finally stop supporting legacy real mode operations in their precious silicon. It's supposed to enable expansion cards to be made with on-board firmware that can work in a PCI/PCIe slot of any computer regardless of the type of CPU fitted (Intel wanted this so that cards designed for x86 could be used in Itanic^WItanium systems). It's supposed to provide an OS-agnostic pre-boot environment from which system administration functions can be run. It's supposed to provide a level of security that will ensure that a system will only boot from a properly signed and authorised image.
The big problem is that it was designed by a committee, a committee of interested parties who each wanted to bring their own pet feature to the standard, and who apparently didn't pay too much attention to what else was getting in through the door; a committee that didn't have the budget, the trust, or the authority to take actual responsibility for the monster they created.
Have you seen the size of the UEFI spec? Have you ever tried to read it? It's a fine example of a document that was put together by people who knew what they were trying to say, but didn't think to say it in a way that would be accessible by anyone else. To say that it was impenetrable would be kind. It's hardly surprising that it's taken several generations of supposedly UEFI-compliant motherboards and their firmware to get to anything that works somewhat consistently between different boards and vendors. The standard is far too ambitious, encompasses far too much, and explains far too little. Someone should have taken it in hand and whittled it down to usable size.
Secure Boot is actually a very good idea -- it's in the users' interest to be able to have some confidence that the OS on a PC hasn't been suborned by malware. The problem with it is that the UEFI Forum didn't -- wasn't in a position to -- create a master set of vendor-neutral keys and set up a service whereby OS providers could get their OS images signed. The meant that Microsoft, as the biggest commercial provider of OS images, set up the signing infrastructure themselves, and own the main OS verification keys that board manufacturers supply preinstalled on their boards. This means that the boards that are sold accept only Microsoft-signed OS images, at least out of the box, and in order to install another image it is necessary either to get Microsoft to sign that image with their keys (which some Linux distros have done) or to add a new set of keys to the board (which not all boards allow).
For most users, the main advantage of UEFI is that it supports GUID partitioning, and so enables disks larger than 2TiB to be visible at boot time. Even that's becoming less important than it once was, as many PCs are now fitted with a small (certainly less than 2TiB, at today's prices) SSD and larger spinning rust for storage, but the spinning rust doesn't have to be visible at boot time, so a traditional real-mode BIOS booting a GUID-capable OS will work just fine.
When SSDs drop in price by another order of magnitude it may again be important to be able to boot from GUID disks, but by then I hope UEFI will have died the death it so richly deserves and been replaced by Coreboot or Open Firmware or something else that does the jobs that actually matter without the bloat of UEFI.
"Secure Boot is actually a very good idea -- it's in the users' interest to be able to have some confidence that the OS on a PC hasn't been suborned by malware."
The thing is it is overkill, a read-only SD card slot that is only used to load the boostrap would achieve the same thing. When people want to change the bootstrap - (eg: add SecureBoot) they could swap out the SD cards - or with ILO type setups the ILO gear could manage the read-only bootstrap image. It's really not hard - and it doesn't force you into accepting a long chain of trust either. :(
While I agree that on paper UEFI is useful to prevent tampering with the BIOS or OS, if a lousy update or a virus (which is what this is supposed to prevent), can so easily render the machine unbootable, isn't that somewhat worse than a machine you can at least boot?
I realize in the case of ransomware, that the answer is emphatically "No."
UEFI/GPT partitions are already a pain to work with compared to MBR. We were forced to change part of our imaging process to deal with UEFI, and it's been a pain in the butt all the way. (Oh, and there's a rather nice bug in MS's "DISM" tool that makes it idiotically use what appears to be PE's ramdrive for the cache when capturing an image if you don't specify a scratch directory)
We all need to be protected, but with increasing complexity comes more and more woes of a single misstep bricking equipment. Soon will come a day where you'll have to authenticate to your toaster before you can insert bread, I expect.
Soon will come a day where you'll have to authenticate to your toaster before you can insert bread, I expect.
Yes, and that toaster will have DRM to ensure you only insert bread from approved bakers, to ensure your dough goes into their back pockets and not anyone else's.
Putting aside the whole Windows 10 upgrade thing.
Windows had, for a long time, a reputation for having more holes than a sponge.
So the industry decides to come up with something to make it more difficult for an operating environment to be modified without the user's knowledge.
Appears that's wrong too.
So, what exactly is a company expected to do?
What, precisely, do you pretend SecureBoot™ does to make MS™ Windows™ itself less insecure?
Hint: Nothing. That's not its purpose and it's simply impossible for it to do any such thing.
SecureBoot™ secures "your" computer against you. On behalf of the Microsoft Corporation Inc. / RIAA / MPAA. That is ALL.
You can do plenty of damage to a computer and its users without modifying its operating system.
SecureBoot will do nothing to protect against that.
A good example is ransomware, which can run as the local user without administrative privileges, do its nasty work, drop its files then leave. The only way it would be detected, would be by its activity, and this has to be compared with what is "normal" for that computer to be executing.
Not an easy task.
SecureBoot however, is built upon UEFI, which is estimated to have more code than the Linux kernel. If you think that code is going to be bug (exploit) free, then you are living in a dream land.
"...is built upon UEFI, which is estimated to have more code than the Linux kernel. If you think that code is going to be bug (exploit) free, then you are living in a dream land."
F_(k, [idem], [idem]...
Seriously thinking of collecting all remaining, working BIOS motherboards could get a grip on.
BAH ! Secureboot.. Another unneeded MS creation. Seemingly created to attempt to keep people from running OS's other than winblows. Kept folks from running Linux for a short time until MS was forced to cough up the keys.. This is not a glitch. It's a feature now being utilize in an attempt to "encourage" users to migrate to windows 10.
Microsoft... The McDonalds of the computer industry. Trying to cover so many niches they've forgotten how to make the one thing that made them popular.
Actually, some form of secure boot is also used by Apple devices, consoles, and so on. It's all up to ensure the whole stack is trusted. Of course it can also be used to deny installing other OSes, if those controlling the keys don't "trust" them. But whenever you can boot untrusted code you have a big issue lurking around.
First it was the windows 7 telemetry updates that you could hide, but would re-appear. Then the nag ware for windows 10. Then the ultra slow updates making a new windows 7 installation a day long process. Now this. Anyone would think ms didn't want you to stay on windows 7.
Well I didn't stay on windows 7, I got Linux mint. I only use windows 10 on one machine, and its crap in comparison.
Yep, there's a laptop at work that I managed to get Windows 7 installed onto, but now will have the arduous process of getting up to date.
I got as far as getting our standard operating environment going on it Friday evening, and left it at that. I'll be tackling it tomorrow morning when I get in. Hopefully it'll be ready by the time its user arrives at work.
Since forever (well, actually, since 52k dial-up) I've saved Windows updates to disc. To update more than one machine; or to do a clean install, which pre-XP I did a lot. So, I have all the updates - less the telemetry, GWX etc - for W7 x64. However, where you used to be able to chain about 99% of them in a batch and come back an hour later and a clean install was ~99% updated, that doesn't work any more.
There came a time when it was quicker to update via WU than with a batch, so I stopped updating offline, so I don't know at what point it stopped being effective. When updating a clean W7 install via WU turned to molasses, I went back to doing it offline. Only you get about half a dozen updates into the batch and it slows to WU clean install speed. Whether the batch will ever complete, I don't know, for most of the time what you have to do is reboot; most of the time on returning to the desktop the batch will continue - for about another half-dozen patches, then go glacial again. Or if you run each patch manually, clicking 'close' rather than 'reboot', after about half a dozen, you'll get 'searching for installed updates' running indefinitely. Again, rebooting will often get past this and that patch will run sometime before the heat death of the Universe. But I for one am not going to run a hundred-odd patches manually, or by batch requiring multiple restarts and me having to sit in front of the computer for a couple of hours watching and waiting for the cues. It takes so long that more-often-than-not WU will finally present the list well before manually updating is even half done.
It has been said WU is so slow on W7 these days because of the 'checking for installed updates' process. It certainly seems a contender! This doesn't happen on Windows 8.1; on 8.1 updating is like it used to be on 7.
It seems a no-brainer that Microsoft don't fix it, because it reduces the appeal of Windows 7; rather than that they sabotaged it's update process. But that would be so vindictive of them that you couldn't rule out it's being a deliberately-introduced 'bug'. Ethically there is little difference between the two behaviours.
There was a bug in NT4.0 whereby you couldn't chain patches and guarantee newer libraries - for example - would not be overwritten by older ones. They fixed that. Now, in Windows 7, chaining updates is broken more than it was nearly 20 years ago - and they don't give a stuff. But then, updates are no longer for our benefit.
This was all about killing alternate OSes.
Not Linux, thats not a serious M$ competitor, by installed user base. XP, Vista and were the targets, and with win10 certified motherboards you can't boot them. M$ win!
They really didn't have to stuff win10 down our throats as they are now, I guess they've become impatient.
Coreboot was looking so good, then this came along :-(
Not an asus issue, but I dual boot my Dell XPS13 with Win 7 and Win 10 for various reasons. I reformatted the drive to get rid of all the 'secure' boot stuff. It all works, but Microsoft or Intel are certainly still up to sillies because when I choose Win 7, the machine loses the sound drivers on the Win 10 installation and I have to reinstall them each time...
Biting the hand that feeds IT © 1998–2021