Samsung Laptop Bug Is Not Linux Specific

First time accepted submitter YurB writes "Matthew Garrett, a Linux kernel developer who was investigating the recent Linux-on-Samsung-in-UEFI-mode problem, has bricked a Samsung laptop using a test userspace program in Windows. The most fascinating part of the story is on what is actually causing the firmware boot failure: 'Unfortunately, it turns out that some Samsung laptops will fail to boot if too much of the [UEFI] variable storage space is used. We don't know what "too much" is yet, but writing a bunch of variables from Windows is enough to trigger it. I put some sample code here — it writes out 36 variables each containing a kilobyte of random data. I ran this as an administrator under Windows and then rebooted the system. It never came back.'"

Comments

memo to hardware producers

[RichMan]

Embrace Linux as an additional test suite for your hardware.

Re:memo to hardware producers

[Anonymous Coward]

Add that script to the payload malware usually carries, and spread it around, a few thousands bricks later, the negative publicity is sure to kill this whole UEFI thing, or at least force the hardware makers to include linux in their testing.

Re:memo to hardware producers

[CheshireDragon]

I believe you misread the article. Taking Linux out of the equation still caused the problem.
I think the reason why it was most commonly found in Linux is that you can have several different variables to boot the system. Especially if you are one of those super custom freaks. :P
It needs to rewrite as: "Embrace a full test of the UEFI" or "Check storage limits on the UEFI"

Why they wouldn't put more storage on the UEFI, as cheap as it is, boggles my mind.

Re:memo to hardware producers

[PolygamousRanchKid]

How about a warning sticker?

"Warning: UEFI Inside!"

Re:memo to hardware producers

[neonsignal]

The reason it was noticed on Linux is because a portion of this UEFI space is being used to keep a non-volatile copy of the most recent kernel log messages (so that on a crash event, it is easier to find out what happened).

Re:memo to hardware producers

[CheshireDragon]

Ah OK, thanks for clearing my eyeballs on that one. :) Went back, re-read and understand it more now.
I've never really understood the purpose of the UEFI though. I thought it was a dumb idea a while back when I first heard about it. I guess it is time I go freshen up my computer skills a bit. I been out of the game for over a decade. :/

Re:memo to hardware producers

[Anonymous Coward]

Add that script to the payload malware usually carries, and spread it around, a few thousands bricks later, the negative publicity is sure to kill this whole UEFI thing, or at least force the hardware makers to include linux in their testing.

Yes, absolutely. Because people owning these devices would love nothing more than sacrificing them and their time and data to this cause.

Re:memo to hardware producers

[msauve]

"a portion of this UEFI space is being used to keep a non-volatile copy"

The UEFI doesn't require the use of battery backed RAM ("the implementation of variable storage is not defined in this specification, variables must be persistent in most cases."), so such use can be expected end up making all the EEPROM based ones fail at some point. Doing frequent updates to EEPROMs isn't a good idea.

Re:memo to hardware producers

[Anonymous Coward]

Well, yeah, that's why you have to force them. They're not going to brick their hardware voluntarily, are they?

Re:memo to hardware producers

[iced_773]

Except these days malware is used more for profit (e.g. botnet construction) than random mayhem, and to do that you need to keep the host you just pwned alive.

Re:memo to hardware producers

[marcello_dl]

"Embrace linux" requires not much of an effort. That's why PC that were made before linux got popular happily run it.
"Don't throttle linux" fits more the situation, IMHO.

Re:memo to hardware producers

[Anonymous Coward]

You probably didn't get the parent comment. If someone can brick a laptop using a simple hack within Windows, then Samsung (at least) better prepare their stock because it's gonna be an RMA nightmare very soon. And that's probably good for the anti-UEFI side

Re:memo to hardware producers

[DarwinSurvivor]

UEFI is much more than secure-boot. There are a lot of "hacks" required right now to make BIOS work properly for modern scenerios. the 4 partition limit is a good example, we have to use "logical" partitions within a bigger physical partition to get around this bullshit at the moment, UEFI fixes that. It also adds a LOT of other functionality such as much more powerful configuration interfaces that can supply graphics (temperature meters, etc), handle mouse input and drive system speakers directly.

Re:memo to hardware producers

[xaxa]

Except these days malware is used more for profit (e.g. botnet construction) than random mayhem, and to do that you need to keep the host you just pwned alive.

Perhaps put it in as a failure mode if the bot can't contact its server. That might dissuade the police from disabling the command server.

Re:memo to hardware producers

[gmuslera]

Considering all the times that malware was included in drivers disks, could be interesting that the ones for Samsung laptops have included a hardware killer trojan. Or, more up to date, that trojan appears masked as an update on Samsung site or Microsoft marketplace.

That would be preferable than to have a random trojan or exploit that runs at whatever time and put in doubt that it could be manufacturer or owners fault. If someone have to pay the full cost of this is the manufacturer, not the consumer, and the sooner is realized the implications and taken measures against, the better.

Re:memo to hardware producers

[RichMan]

> The title of the article is "Samsung Laptop Bug Is Not Linux Specific" for fuck's sake. Learn to read.

Sorry, but you need to learn to think.....

Sure the bug is not Linux specific. But Linux was the first to expose it. If they had tested on Linux they would have known it was broken and could have fixed it before releasing the hardware.
That is my point. Linux gives more hardware coverage and can expose bugs that might not be found otherwise. Linux provides a pretty much free test load for the hardware.

Any test house should be very very happy to have a pretty much free (only cost is small time to setup boot) second test suite for the hardware.

Re:memo to hardware producers

[Kaldaien]

Yeah, not to mention the latency involved in writing to EEPROM. You would pretty much have to do it asynchronously to keep it from becoming a bottleneck, which then invalidates the usefulness -- since there is no guarantee that the last log message(s) completely written to UEFI was the last message generated. I implemented something similar in a custom VxWare boot loader, which wrote boot status to on-board flash memory, but it did so synchronously at a limited number of application-defined checkpoints.

I do not like the idea of EEPROM being constantly written whenever the kernel spits out a message. You are spot on, this will inevitably wear the memory out :-\

Re:memo to hardware producers

[LordLimecat]

Luckily, the whole "cause havok for the heck of it" virus craze kind of died out years ago.

If theres no money to be had, theres no real threat except from people you know "pranking" you.

Re:memo to hardware producers

[LordLimecat]

Linux runs happily on all sorts of crappy hardware because somewhere, at some point, a linux dev did a lot of heavy lifting to make that happen, not because linux magically works with all hardware.

Re:memo to hardware producers

[Anonymous Coward]

Apple should include it in the next version of iTunes.

Re: memo to hardware producers

[Anonymous Coward]

Riiiiiight. Like there's nothing to be gained by an over zealous anti-UEFI coder writing a virus to accomplish what all the sound logic presented can not: making UEFI cost prohibitive due to RMA's and ad press.

Re:memo to hardware producers

[Kaldaien]

Modern EEPROM can be written to on the order of up to 1 million times before failing. However, at the same time, modern defective kernel modules can spam kernel messages fast enough to make me weary of simply streaming the kernel log straight to EEPROM :)

Re:memo to hardware producers

[jedidiah]

The 4 partition limit? Really? That's like something that only 1% of the 1% care about. All of your other examples are similarly completely unexciting.

BIOS may be ancient and ugly and still require you to [gasp] still use a keyboard but they don't seem to be bricking machines.

Re:memo to hardware producers

[John Hasler]

What does UEFI do that coreboot doesn't other than Secure Boot?

Re:memo to hardware producers

[Anonymous Coward]

Works on more hardware?

Re:memo to hardware producers

[Anonymous Coward]

As a matter of fact, many BIOS writers are quite proficient assembly gurus.

Re:memo to hardware producers

[wvmarle]

If only you had read the headline of the summary you would've known that it is not related to Linux as such.

Linux is just doing something to the UEFI (writing data to the UEFI memory) that is fully within the specs and which UEFI explicitly has been designed for to support. It is just that Windows normally doesn't use this feature. Yet bricking using Windows is just as easy or even easier than bricking using Linux.

Re:memo to hardware producers

[wvmarle]

And maybe, just maybe, people would start to wake up again to the real threats of malware, and would demand higher levels of security. Not likely, but you never know.

Re:memo to hardware producers

[wvmarle]

Isn't UEFI just a BIOS v2? It has the same basic purpose (bootstrap the system, so it can start loading the OS from an external memory). That's BIOS plus added functionality, including a thorough break from all legacy restrictions. And of course a new name to not leave a bad taste.

Re:memo to hardware producers

[rahvin112]

BIOS is incapable of handling boot storage larger than 3TB. Given the persistent increase in storage overtime and that Laptops right now are coming with 1TB, it's just a matter of a few years before BIOS can no longer be used without limiting storage to 3TB.

Re:memo to hardware producers

[jamesh]

Add that script to the payload malware usually carries, and spread it around, a few thousands bricks later, the negative publicity is sure to kill this whole UEFI thing, or at least force the hardware makers to include linux in their testing.

I don't understand. How is my botnet supposed to make me money if all the machines don't boot?

Re:memo to hardware producers

[Anonymous Coward]

Yes and no. I mean, yeah, it's a replacement for BIOS, but it's really not a version 2 in that it's a new design, as opposed to a rewrite of the old BIOS design. The 1981 IBM PC BIOS literally was the hardware driver layer for MS-DOS. That's all gone now, as is any use of the now-quaint CPU modes required by the DOS environment. The only way to get any of it back is by using a BIOS "compatibility module", an optional wedge of EFI application code that emulates classic BIOS interfaces.

EFI is designed to support some rather sophisticated application software running in the EFI environment using EFI as its only "OS". For example, Apple's recent Macs have a feature called "Internet Restore", which lets you install OS X over the Internet without physical media or even a restore partition. It's implemented entirely in their EFI firmware.

Re:memo to hardware producers

[Culture20]

Samsung has competitors and maybe a few fired programmers with grudges.

Re:memo to hardware producers

[tlhIngan]

I've never really understood the purpose of the UEFI though.

Think of it this way - the PC boots the same way today as it did 30 years ago. The BIOS reads the first sector ot the first hard drive at a specific location in low memory and jumps there. Now, in most cases, that is a standard MBR loader - it reads the partition table (also embedded in the first sector - great design, eh?), the calculates where the next sector (the first sector of the partition) should be ont he disk. It calls the BIOS to load that into another location in RAM, then jumps into it. That one hopefully loads more of itself so it can then load the OS. All this happens in 16 bit real mode.

EFI boot allows the loader to reside in a special EFI storage partition, where it can find the OS loader, and then the OS loader can directly, instead of chain loading various sectors all over the place (and often having to have a bootstrap loader be the one to fit in 512 bytes, that loads the main part of the boot loader - think the nasty hack that is grub's stage 1/2/2.5/etc loader and think how much nicer it would be if the BIOS would just read it off the disk)

In fact, practically all PCs sold have an EFI/UEFI bootloader by default - Intel has been shipping them for many years now (prior to 2006 - when Apple introduced the Intel Macs, even - probably the first experience most people have with EFI). What's been happening is that the EFI loader has been calling into the BIOS emulation layer to perform the BIOS legacy boot.

Basically, its a more advanced bootloader because really, initializing hardware is getting more complex. Think stuff like USB for example - it requires a lot of high level integration in order to work, and stuff like EFI can make it much easier to do so because it's like a mini OS. Plus getting rid of the 512 byte loader limitation.

Finally, (U)EFI is a joint collaboration between Microsoft and Intel - Intel created several technologies, including the GPT (which is required if you want a >3TB drive to be useful and not truncated to 3TB - MBR is useless at this point - and important if you're running huge RAID arrays)., while using others from Microsoft (the on-disk EFI partition is... FAT32, and the binaries it loads are PE COFF exe's).

Re:memo to hardware producers

[PPH]

Because no one on teh Internets ever does something for the lulz. And just to make a political/economic point by trashing something or raising a bit of hell.

Re: memo to hardware producers

[MaskedSlacker]

Right, instead of fucking up Windows (which they could have already done) they fuck up your firmware, and you honestly think end users would even know the damned difference. Pass the pipe please.

Maybe you should stop smoking that, it's damaging your critical thinking skills.

The users are not the one receiving a message in this scenario. The manufacturer is the one receiving the message. It works like this:

1) Unethical hacker writes virus to brick Samsung laptops.
2) Thousands of Samsung laptops get sent in under warranty for repair because they inexplicably (from the users' perspective) stopped booting.
3) Samsung bean counters notice that UEFI models have an unacceptably high rate of failure under warranty.
4) Samsung bean counters decide to kill UEFI models.

Re:memo to hardware producers

[sdsucks]

I believe you misread the article. Taking Linux out of the equation still caused the problem.

Uh, testing under this distro and version of linux WOULD have caught the bug, right? It's not unexpectable that a samsung laptop would have ubuntu installed.

Just because the bug was reproduced under Windows doesn't mean it would have ever occurred accidentally there. I'm guessing you have never been involved in any kind of testing - software or otherwise.

Re:memo to hardware producers

[X0563511]

Breaking Windows is different than breaking the hardware. I'm sure this will not end well.

All it takes is one asshole with an axe to grind. They can include it in their botnet package, so if the victim isn't vulnerable to this, they just get added to the attack network.

Re:memo to hardware producers

[pjt33]

My understanding of Matthew Garrett's blog post is that it only writes to UEFI variable storage on a kernel crash, which (hopefully!) isn't a frequent occurrence.

Re:memo to hardware producers

[VinylPusher]

That argument stands up rather well. ... until you factor eMachines laptops into the equation. Lowest of low quality components. You still can buy EEPROMs that are designed for fewer than a thousand erase/write iterations.

Re: memo to hardware producers

[Anonymous Coward]

You mean to say that bean counters have an actual positive use?

Re:memo to hardware producers

[silanea]

[...] the negative publicity is sure to kill this whole UEFI thing, [...]

This is becoming increasingly annoying: Why the hell is there so much hate for UEFI? I run Linux Mint and Windows 7 in a dual-boot setup and frankly I have come to love the speed at which my rig boots since switching to a pure UEFI setup. For whatever reason BIOS-based configurations on the same hardware took ages in comparison. I like UEFI. I do not want anyone to kill it.

Now, SecureBoot, that is a different beast. I see quite a few uses, eg. preventing 'bad people' from booting anything I did not preapprove on my machine. But as long as I cannot verify which keys and possible backdoors the manufacturer might have put in it is pretty much unusable. I am waiting for the UEFI equivalent of CoreBoot. That would be a real boon.

Re: memo to hardware producers

[greg1104]

Your theory that there are capable bean counters who understand statistics and make good decisions using them is an interesting one. I'm going to pick option B however, where RMAs for the model are denied because everyone knows those users destroyed their hardware using that nasty Linux program, and they're not going to get a replacement or refund at all. Why, if anything it's proof that the ability to lock down the bootloader is even more important than ever!

The awesome thing about statistics is that the intent of person applying them suggests the outcome long before the data is analyzed. Given enough numbers, people will see what they look for.

Re:memo to hardware producers

[Klivian]

Or you could just skip the EEPROM and use a FRAM insted, they are just as cheap an have a quite nice 10^15 or higer write limit.

Re:memo to hardware producers

[drinkypoo]

BIOS is incapable of handling boot storage larger than 3TB.

Is that a fact? Or can it only address 3TB on it? Your boot partition has to be in the first 3TB? Doesn't sound like a problem to me. I'd love to replace the BIOS with Coreboot with a grub payload, and maybe someday I will try, but only because it is so goddamned slow. I don't need to fully initialize all my hardware before I boot.

Re: memo to hardware producers

[OolimPhon]

Not going to work. All the repair shop has to do is look at the HDD and see that it has only ever had the original Windows on it. No Linux is involved in this bricking campaign at all.

Re: memo to hardware producers

[greg1104]

You think there are a significant number of repair places who routinely pull hard drives from dead devices for forensic/cause analysis? If the idea is to suggest there are smart bean counters, I guess that's no more silly.

If my goal were to prove Linux is responsible for the problem, regardless of reality--which is the idea I'm parodying here in case you're not sure--I would brick one using a live CD. In an ideal situation for Samsung, not only would they not give the RMAs out, asking for one due to this problem would result in US customers being arrested for using hacking tools. Play that perfectly, and their potential competitors at Canonical would also be sued for providing the tools.

Re: memo to hardware producers

[gerddie]

[..]

I'm going to pick option B however, where RMAs for the model are denied because everyone knows those users destroyed their hardware using that nasty Linux program, and they're not going to get a replacement or refund at all.

[...]

In case you didn't RTFS: The laptop was bricked by using a program running on Windows.

Re:memo to hardware producers

[Anonymous Coward]

It's because UEFI was designed to be a DRM-based operating system that sits on your hardware and underneath your actual operating system (Linux/Windows).

Have you ever actually looked at the fucking UEFI spec. It's a hideous nightmarish festival of complexity - the vast majority of which serves no purpose OTHER THAN TO seal the hardware for DRM purposes.

The whole boot process, from a technical point of view, would have benefited from simplicity (indeed, Microsoft used to say "we don't need no stinking BIOS" - this was pre-DRM relevation circa 1999 by Billy Gates).

UEFI ignored all that because its goal isn't simplicity and reliability. It's control and DRM.

Re:memo to hardware producers

[Eunuchswear]

As a matter of fact, many BIOS writers are quite proficient assembly gurus.

hypothesis not sustained by observed facts.

Re:memo to hardware producers

[Eunuchswear]

However, at the same time, modern defective kernel modules can spam kernel messages fast enough to make me weary of simply streaming the kernel log straight to EEPROM

To tired to change your spell checker?

Re:memo to hardware producers

[mikael]

I remember tracing through the BIOS instructions to do basic VGA graphics like drawing a single pixel; save *all* registers, unlock *all* VGA registers, mask, shift, add and write pixel byte, relock *all* VGA registers, restore *all* registers.

Re:memo to hardware producers

[smallfries]

There would be plenty of money to be had. Short their stock before forcing a product recall.

Re:memo to hardware producers

[amorsen]

I am sure there is a BIOS writer somewhere who is a proficient assembly guru. I have never had the chance to use any system he wrote code for.

Re:memo to hardware producers

[MrResistor]

There is money to be had: by blackmailing Samsung. "Pay up or we brick you customers laptops." How much do you think it would be worth to Samsung to avoid that PR disaster?

Re: memo to hardware producers

[LordLimecat]

Youre missing the part where said unethical hacker could instead have made (tens of) thousands of dollars using his virus in a different way, as say a botnet, or spambots.

Re:memo to hardware producers

[gargleblast]

weary of ...

To tired to change your spell checker?

Too weary to check your dictionary?

Re:memo to hardware producers

[lsatenstein]

Add that script to the payload malware usually carries, and spread it around, a few thousands bricks later, the negative publicity is sure to kill this whole UEFI thing, or at least force the hardware makers to include linux in their testing.

====
This is not a Linux bug, it is a Windows bug. MG was trying to determine the available free UEFI space. He ran the program in Windows.

Now we just have to wait for some hackers with vandalism intentions to create the next big virus.

Re: memo to hardware producers

[lsatenstein]

Right, instead of fucking up Windows (which they could have already done) they fuck up your firmware, and you honestly think end users would even know the damned difference. Pass the pipe please.

Maybe you should stop smoking that, it's damaging your critical thinking skills.

The users are not the one receiving a message in this scenario. The manufacturer is the one receiving the message. It works like this:

1) Unethical hacker writes virus to brick Samsung laptops.
2) Thousands of Samsung laptops get sent in under warranty for repair because they inexplicably (from the users' perspective) stopped booting.
3) Samsung bean counters notice that UEFI models have an unacceptably high rate of failure under warranty.
4) Samsung bean counters decide to kill UEFI models.

===
Who is to say that the problem is limited to Samsung alone?

Re:memo to hardware producers

[bingoUV]

Why the hell is there so much hate for UEFI

People, incorrectly, use the word UEFI instead of UEFI SecureBoot.

I am waiting for the UEFI equivalent of CoreBoot

Just like yourself.

Re: memo to hardware producers

[RockDoctor]

1) Unethical hacker writes virus to brick Samsung laptops.

s/Samsung/UFEI-implementing manufacturer/

As I RTFS (I'm off to RTFA now), potentially any UEFI system with this constraint is going to be vulnerable to this.

Same substitution through the rest of your comment.

Re:memo to hardware producers

[Eunuchswear]

Ok, I mis-typed "too". But didn't you notice that Kaldaien clearly meant to type "wary"?

Re: memo to hardware producers

[crutchy]

it probably works in microsoft's favor... the more brickings, the more new products get sold to replace the brickings

They didn't get the memo

[Anonymous Coward]

it writes out 36 variables each containing a kilobyte of random data

36k clearly isn't enough for anyone.

Re:They didn't get the memo

[YurB]

The author of the blog post states that Microsoft required at least 64kb for Windows 8 machines.

Re:They didn't get the memo

[DarwinSurvivor]

b!=B

Re:They didn't get the memo

[DarwinSurvivor]

An order of magnitude of 8 is not pedantry.

Does windows crash if it has 0 temp space or 0 ram

[Joe_Dragon]

Does windows crash if it has 0 temp space or 0 ram free real+VM?

Or at least in older vers? or on systems with very low ram.

Re:Unlimited Supply of Laptops?

[Gaygirlie]

It's not irrecoverably bricked. All he needs to do is open the laptop and disconnect the battery that refreshes the CMOS storage memory and wait a few seconds.

Re:Unlimited Supply of Laptops?

[mjg59]

30-day hassle-free return policy.

OS boot entries are in NV storage

[AdamRosas]

So installing too many operating system will result in a brick, Windows in particular uses a lot of NV storage for it's boot entry, be careful when using BCDEDIT.exe...

Re:Unlimited Supply of Laptops?

[mjg59]

Unfortunately not in this case.

Free Laptops?

[Anonymous Coward]

These guys are intentionally trying to brick their laptops? I understand what they're trying to do, but don't they care about their money going down the drain, or are they getting free laptops from Samsung somehow?

Re:Free Laptops?

[Skapare]

These steps are actually NOT supposed to brick them. It is thus a proven manufacturing defect. So Samsung is obligated to "repair or replace". An external (JTAG) reflash of the ROM should be able to fix it. Samsung should also fix it by reprogramming the ROM code to perform UEFI correctly.

Re:Free Laptops?

[gmuslera]

If by software can turn their laptops into paperweights (i.e. without entering into some sort of privileged mode, like when updating bios), is the manufacturers fault, even inside windows it could happen with a trojan or a buggy program. As long as Samsung keeps giving them brain damaged laptops they should still get a refund or replacement, or else acknowledge that they are selling timebombs that could stop to work at any moment.

Re:Free Laptops?

[wvmarle]

Well, yes, in a way, they are intentionally bricking their laptops. And I would hope they can get a new one under warranty.

Reason being of course that they are trying to figure out what causes Linux to brick those laptops. And to figure that out, first of all you need to figure out what triggers that bug. Unfortunately in this case the triggering of that bug means you're destroying a perfectly good piece of hardware.

Only when you know exactly what causes a bug, can you start figuring out how to fix it. The problem seemed to be Linux related - now it's proven that is not the case, the actual bug is in the UEFI. It's not a Linux bug, it can be triggered using any OS. Windows software may do this as well - and I can really think of people wanting to write data into UEFI memory, particularly those in the malware/DRM business - and as a result bricking the machine.

And now it's up to Samsung to actually fix their UEFI firmware code.

Re:Free Laptops?

[MaskedSlacker]

It's not like the store can figure out they intentionally bricked it.

Yeah, it's a good thing that information isn't publicly available...

Re:Free Laptops?

[lsatenstein]

These steps are actually NOT supposed to brick them. It is thus a proven manufacturing defect. So Samsung is obligated to "repair or replace". An external (JTAG) reflash of the ROM should be able to fix it. Samsung should also fix it by reprogramming the ROM code to perform UEFI correctly.

===
Dont you mean the corporation that produced the bios for Samsung?

Extortionist Heaven

[resistant]

We all know perfectly well that malware makers will start including a module that purposefully bricks Samsung laptops so that extortionists can threaten to wipe out a batch of corporate-owned laptops in one blow if the company refuses to cough up a substantial amount. No matter how this affair plays out, I can't see it ending well for Samsung.

Re:Extortionist Heaven

[rudy_wayne]

Why does this only affect Samsung computers? Did they do something extra stupid to the UEFI in their computers that other vendors didn't?

Re:Extortionist Heaven

[Deliveranc3]

Just guessing from experience with Koreans, but... chances are they followed Microsoft or Intel specifications properly. Other companies probably just copied a binary and use it as a black box.

Re:Extortionist Heaven

[Forever Wondering]

From the scant details, it appears Samsung didn't provide enough storage [of whatever type] to be able to store the UEFI variables that one could reasonably be expected to store. And/or when that storage ran out [or hit a percentage threshold], simply failed to prevent the bricking with a limit check and refuse to store the new information [returning an error code instead]. It's unclear what's truly happening, but it seems that the extra UEFI data goes somewhere and scribbles on some NV memory that it shouldn't [which may have nothing to do with secure boot].

Re:Extortionist Heaven

[John Hasler]

From the scant details, it appears Samsung didn't provide enough storage [of whatever type] to be able to store the UEFI variables that one could reasonably be expected to store. And/or when that storage ran out [or hit a percentage threshold], simply failed to prevent the bricking with a limit check and refuse to store the new information [returning an error code instead].

That would imply that this bug may be present in many/most/all UEFI implementations, with others merely having higher limits.

It also implies that it may be possible to exploit this in various other ways, such as bypassing Secure Boot if you can figure out what to overwrite.

Re:Extortionist Heaven

[jones_supa]

Very possible.

Re:Extortionist Heaven

[wvmarle]

That'd be easy to test using the script posted. Just increase the 36-variable number to something much bigger, and write write write until something breaks.

FTA, UEFI specs say there should be at least 64 kB of memory available for writing data to. So start with that. This shoud ALWAYS work - 36 kB is well under that limit. Some UEFI systems may have more than that available of course, fill that up as well.

And when the memory is full, try to write some more.

Now honestly I have no idea what UEFI specs say it's supposed to do when you write more data to it than it has memory, some kind of "out of memory" error message sounds the most appropriate. At least attempting to fill up its memory with random data should never result in other data being overwritten, or it not being able to boot for not enough free memory to work with, or whatever.

Re:Extortionist Heaven

[Forever Wondering]

That would imply that this bug may be present in many/most/all UEFI implementations, with others merely having higher limits.

The important thing is the limit check. It seems that Samsung's BIOS doesn't have one. The question is which BIOS is Samsung using [and what BIOSes are other vendors using]? For example, I believe Dell's BIOS was originally Phoenix, but now they roll their own. So, if Samsung used a slightly customized version of Phoenix [or AMI], the bug may indeed be in other vendors' products. If Samsung rolled their own, or heavily customized a Phoenix/AMI BIOS, it may be Samsung's problem alone.

Matt's test program apparently blows out around 36K [a strange number--I would have expected 32K or 48K]. This should be enough to store plenty of UEFI info. For example, a signing key is on the order of 64 bytes [we could even be generous and say 256 bytes, which gives us a 2048 bit key]. The test program is stressing things way beyond normal operation. But, the BIOS should still handle it gracefully (i.e. it's still a bug).

It also implies that it may be possible to exploit this in various other ways, such as bypassing Secure Boot if you can figure out what to overwrite.

I briefly perused the UEFI spec a few years back, but I don't really know what it currently requires for secure boot. But, I would guess that being able to disable secure boot by mere overwrite would be specifically excluded. If you boot a system, and F10/Fwhatever into the BIOS config menu, you must, IIRC, be able to disable secure boot for current and subsequent ones until you go back to the config menu and change it.

But, after the BIOS turns control over to the boot loader, disabling this by the loader/kernel must be prevented. This could [easily] be accomplished by the BIOS writing to a special I/O port [just before transferring control to the boot loader] that tells the hardware that certain other ports and/or NV memory [one of which holds the "secure boot is enabled" bit] to become off limits (e.g. R/O or even unmapped in the I/O or memory space) until reboot or power cycle. That is, this is a "one-way" operation--once you do it, it can't be undone until a true reboot/cycle (e.g. even a PCIe reset won't change it).

Re:Extortionist Heaven

[fuzzyfuzzyfungus]

What I find sort of alarming is that excessive scribbling causes the firmware to fail, rather than to fall back to some sort of sane failsafe state.

It sounds like Samsung managed to make things brittle enough to be the first to fail under real-world conditions; but, no matter how much storage you provide, somebody could always demand more. You'd hope that the firmware would either behave sensibly as the storage fills up(and stop accepting requests for more) or at least fail sensibly and wipe or truncate the storage area and come right back up, ready for recovery...

Re:Extortionist Heaven

[JWSmythe]

    The spec may say that there should be at least 64K available, but that doesn't mean that it is. That is available for something to write into, so if the UEFI already writes something there, 36K or less could fill it.

    It actually seems to be a forewarning of future problems. 28K have already been used up by something, it's already 44% through its life. If it's a fairly new machine, that doesn't look so good for it's longevity. Since I don't have a problem machine in front of me (and I'm glad I don't), I can't really even hope to look in there and see what's wasting the space.

Re:Extortionist Heaven

[Forever Wondering]

While you were doing your reply to me, I just did two replies elsewhere in the same thread that might help explain in more detail the who/what/why. As I explained there, it may not be the BIOS/firmware's responsibility (e.g. it has booted a trusted, signed boot/OS, so it trusts [has to trust] anything it does)

---

But, if the UEFI data is comingled with executable code within the BIOS flash, this is extremely dangerous because the overrun can overwrite mission-critical BIOS executable code.

The UEFI spec doesn't specify where the UEFI data is to be stored. It just mandates that it be some sort of NV storage. This [vagueness] is by design, to allow each system manufacturer to use their own discretion. Some may choose to put UEFI data in CMOS/NVRAM. Others may choose to put it in the BIOS flash ROM. Others may add an additional small NAND flash, just for UEFI alone.

If Samsung is doing the comingle approach, and the system is truly "bricked" (e.g. requires a reflash with an external hardware flash device) vs. merely reset of the CMOS (e.g. to cure a simple "won't boot" as we all used to have to do, occasionally, even before UEFI), this may indicate that comingling [by any vendor] is a "very bad idea" (R).

Personally, I'd store all keys in CMOS/NVRAM. I'd also put the "standard/default" keys (e.g. MS's) in the BIOS flash as R/O data. The flashed keys are only there to reload into CMOS if the BIOS detects CMOS corruption (e.g. failed checksum). If you had used the BIOS config menu to add your own keys, you'd have to reenter them, but at least the system would never become "bricked", just "won't boot".

"Bricking" must be prevented by hardware [architecture of the memory hierarchy], but prevention of "won't boot" [because it can be corrected] can be delegated to a later stage of the software.

Re:Extortionist Heaven

[wvmarle]

    The spec may say that there should be at least 64K available, but that doesn't mean that it is. That is available for something to write into, so if the UEFI already writes something there, 36K or less could fill it.

True; making the test even easier. Just write until it's full. Should give some kind of error message; should not stop the thing from booting.

It actually seems to be a forewarning of future problems. 28K have already been used up by something, it's already 44% through its life. If it's a fairly new machine, that doesn't look so good for it's longevity.

No idea why you suggest that UEFI memory use and longevity of a computer are related, or how they even could be related.

Re:Extortionist Heaven

[JWSmythe]

I'm only suggesting longevity, because there were mentions of logging events happening there. LIke I also said, I don't have one of the vulnerable machines, so I can't see if it's true. If someone set it to store debugging messages at boot time, it could be storing stuff like drive status, and other boot messages from anything and everything before its handed off to the OS.

I do agree, it shouldn't be a show stopper. Like someone else said, there should be a routine in there that says the expected empty space is full, clear it and continue.

Re:Extortionist Heaven

[wvmarle]

The kernel message logging uses some 10 kB, but it is not kept, every time the computer boots the old logs are overwritten. The developers also know there is only 64 kB available (as per specs) which they can use.

Re:Extortionist Heaven

[lsatenstein]

From the scant details, it appears Samsung didn't provide enough storage [of whatever type] to be able to store the UEFI variables that one could reasonably be expected to store. And/or when that storage ran out [or hit a percentage threshold], simply failed to prevent the bricking with a limit check and refuse to store the new information [returning an error code instead]. It's unclear what's truly happening, but it seems that the extra UEFI data goes somewhere and scribbles on some NV memory that it shouldn't [which may have nothing to do with secure boot].

===
Not knowing better, does Windows 8 boot process write into the UEFI memory as a dynamic memory pool, as did the testing of free memory in UEFI space. And did W8 free the pool when the authentication has completed? If so, is it possible then that Windows Bricked the laptop.

Re:Extortionist Heaven

[Forever Wondering]

Not knowing better, does Windows 8 boot process write into the UEFI memory as a dynamic memory pool, as did the testing of free memory in UEFI space. And did W8 free the pool when the authentication has completed? If so, is it possible then that Windows Bricked the laptop.

I did a few more replies on other parts of this thread that have some more information. In particular, the difference between true bricking [where the laptop needs to have its BIOS reflashed by an external hardware reprogrammer] and merely making the system unbootable [the CMOS/NVRAM gets corrupted data, which can be corrected by opening the laptop and hitting the CMOS reset button]. I'll try not to repeat too much of it.

The original bricking (or "won't boot" if a CMOS reset clears it), happened because the linux "samsung laptop driver" was writing to BIOS memory. Matt had been told by Samsung that this was fine (e.g. they gave him the procedure or sample code). With UEFI enabled, this was bricking things. The workaround is to blacklist the driver. The patch to the driver is it will not allow itself to be loaded if the system is under UEFI.

Matt came up with a test program, which he ran under Windows [to eliminate any possibility that Linux itself was doing something], which is what this article is all about. The test program is just writing UEFI memory in a loop until the lockup occurs. It's doing this by getting elevated privileges for itself, then issuing a special syscall to get the WinX kernel to write the memory. It's unclear to me whether the kernel is writing to the UEFI memory directly or whether it's using either a "Boot Services" or "Runtime Services" UEFI function to do it.

The UEFI spec is 2,200 pages. I've been perusing it a bit. From what little I've been able to glean, the UEFI assumes a "chain-of-trust" model. That is, because UEFI secure boot will only boot a signed/trusted OS boot loader, it assumes [or must assume] that anything that the loader (or the kernel) does is acceptable [because it's signed, it is trusted].

The limit check has to/should be done by somebody. No amount of bad data should brick the laptop. If the kernel does the writing by invoking a BIOS call, the BIOS must check this. If the kernel is doing direct write, it must do a limit check, regardless of what a privileged program tells it to do. This is the linux kernel philosophy (e.g. given a similar situation, it would perform the limit check and disallow the hazardous operation no matter what a root user program said to do).

Some others have said that the UEFI data is stored in the same flash memory that the BIOS executable code runs from. This seems to be true for Samsung, but it is also claimed that other vendors also do this. I consider this to be less than stellar design. There is nothing in the UEFI spec that mandates this implementation (e.g. the spec just requires NV memory). Repeatedly writing to flash wears it out. More importantly, an overrun condition could scribble on executable code in the memory. If this is what is happening, then it's a true bricking. Personally, the only real solution is to have special hardware that prevents this.

But, then again, if one updates one's BIOS from a downloadable flash BIOS image, a glitchy update can brick things. This was true even before UEFI.

So, to answer your question [finally :-)], Win8 didn't brick things, per se. It just didn't prevent a privileged program from doing so. If there is a vulnerability in Win8 that allows malware to elevate its privilege [and the MS track record on this implies this is still a distinct possibility], then this means there is still a gaping hole. So, I guess you could say that Win8 is an accomplice, because it "left the keys in the ignition".

Re:Unlimited Supply of Laptops?

[pushing-robot]

I might be confused, but don't kernel devs normally destroy their instruments at the end of each show?

Forgot one detail...

[Groo Wanderer]

He forgot the line, "Try it yourself and see." :)

Reminds me of the old IRC days when n00bs would ask what the command was to get channel admin privelages. "+++ATH" was the normal answer. :)

                        -Charlie

Re:Forgot one detail...

[Prof.Phreak]

Alt+F4, Alt+F4, Alt+F4, Alt+F4, Alt+F4, Alt+F4, Alt+F4 ...I'm sure someone will hit it (even now :-).

Re:Forgot one detail...

[harrkev]

Don't forget about telling noobs about the great warez site at 127.0.0.1.

Re:Forgot one detail...

[isorox]

Alt+F4, Alt+F4, Alt+F4, Alt+F4, Alt+F4, Alt+F4, Alt+F4 ...I'm sure someone will hit it (even now :-).

Why would I want to switch to virtual desktop 4?

Re:Forgot one detail...

[Skapare]

They were probably at home. You know the old saying "don't do this at home, boys and girls". Later on they can take the laptop to a restaurant where it is safe to do it.

Re:Forgot one detail...

[shentino]

That's Ctrl+Alt+F4

Re:Forgot one detail...

[armanox]

That would be Virtual Terminal (VT) 4, not Desktop 4.

Re:Forgot one detail...

[shentino]

Alt F4 is still wrong though. It's still the "quit" function. I tested it on a linux box.

Re:Forgot one detail...

[JWSmythe]

Only for you people using a GUI. Real men read Slashdot from a text console with lynx. Insane people read it with telnet and a script to parse the HTML for text mode viewing. I hear even RMS has started using graphical web browsers on occasion, so I guess that trick may work on him now. :)

Re:Forgot one detail...

[greg1104]

Sure, Stallman uses a web browser sometimes...but only when he can't read the text from the HTML. And in any case, "I fetch web pages from other sites by sending mail to a program that fetches them, much like wget, and then mails them back to me."

Re:Does windows crash if it has 0 temp space or 0

[corychristison]

That's what swap space is for (aka the pagefile on Windows).

Your system will try to dump memory into swap space. If you don't have swap space, on Linux at least, processes will fail to run and you'll get some messages in dmesg that you're running out of available RAM.

Depending on the application, the application that is trying to allocate memory may crash.

I have yet to see a full system hault brcause of it though.

Re:Not even a brick, not a story

[mjg59]

Removing the CMOS battery didn't recover this system, which is pretty much what I'd expect - UEFI variables are typically stored in the same hardware as the firmware itself, and unplugging batteries doesn't kill your firmware.

The system doesn't fail to boot. The system doesn't even complete its power-on self checks. The screen is never turned on. It never responds to keyboard input. It's bricked. This machine's not coming back to life without an SPI programmer.

Re:Unlimited Supply of Laptops?

[Arancaytar]

UEFI data is apparently stored in NAND. Non-volatile.

No idea if there is some way to flash it, but if it's sufficiently hardwired into the board then it's entirely possible you're SOL and have to buy new hardware. Yes, this is idiotic.

Re:Not even a brick, not a story

[DarwinSurvivor]

Sorry, but if removing the battery or otherwise resetting the NVRAM to factory defaults resolves the issue, that's not even remotely "bricked".

Non-Volatile Random Access Memmory

Look up the first part and you'll figure out why removing the battery won't fix it.

Re:Does windows crash if it has 0 temp space or 0

[Dwedit]

I've seen Windows machines run out of handles. First you see applications not drawing properly, or missing buttons, then you see windows failing to be created. When it tries to create the window, it fails, then you hear the "Critical Stop" sound played instead of a dialog appearing.

Sometimes, it won't even create menus, so you can't right-click on a program in your taskbar and close it, but you can still activate the window and press Alt+F4 to close the program.

Once your system gets into that state, start closing programs (Calc, Explorer windows, etc. ) until you can use your computer again. Once you've closed enough programs, your computer works again. Don't even need to reboot.

48 vars, not 36, read the code

[insecuritiez]

The code writes 48 1kb vars. The summary is wrong.

Re:48 vars, not 36, read the code

[YurB]

The summary is quoting the blog post. It seems that the code was updated after the blog post was written.

Sample C code has implementation-defined behaviour

[Old Wolf]

(char)rand();

Extremely minor nitpick, but converting an out-of-range value to a signed integral type causes implementation-defined behaviour (which could include raising a signal).

It's pretty safe to say that Microsoft will never release a compiler that breaks this, but portability could be maximised by making 'testdata' be 'unsigned char' and removing the cast in the quoted code (out-of-range conversions of unsigned integral types causes the value to be reduced using modular arithmetic - no cast is required or desired).

Re:Does windows crash if it has 0 temp space or 0

[xaxa]

I have yet to see a full system hault brcause of it though.

Last time I discussed it, Linux would kill a heuristically-chosen process (the "OOM Killer", it will avoid killing a process owned by root, balanced by killing something using lots of RAM and maybe CPU, I can't remember). Windows will crash.

Both behaviours are acceptable. Arguably, the Linux one is worse in some cases -- it might leave the system in an unnoticed but inconsistent state.

Not ready

[Anonymous Coward]

This just goes to show that UEFI is top-heavy, fragile, and not ready for prime time.

Re:Not ready

[gweihir]

Indeed. I suspect the only reason we see UEFI in practice are Microsofts desperate attempts to slow the spread of Linux by making it to hard to install it for the average user. That "secure boot" is everything but secure has been adequately demonstrated already. That Microsoft has tried despicable and immoral practices like this before is also well known.

Re:Sounds like this is by design

[gmuslera]

Don't attribute to malice what can be explained by stupidity, at least if not lawyers involved.

Re:Unlimited Supply of Laptops?

[Dragonslicer]

It's okay, kernel developers and heavy metal bands are easily mistaken for each other.

Re:Does windows crash if it has 0 temp space or 0

[whoever57]

That's not what the OOM killer is for. Linux will allow over-commitment of memory (programs can malloc more memory (RAM plus swap) than is available). If all the malloc'ed memory is actually used, this can lead to more memory having been allocated than is available. This is when the OOM killer starts work killing tasks.

This behavior can be modified by changing the values in /proc/sys/vm/overcommit_ratio and /proc/sys/vm/overcommit_memory.

As an experiment, I wrote a little progrem that malloc'ed 200MB chunks of memory. I ran this on a Linux box with 2GB of RAM and all the SWAP disabled. The program could malloc 3GB of RAM before the allocation requests failed.

Re:Does windows crash if it has 0 temp space or 0

[GigaplexNZ]

That's often a case of running out of desktop heap rather than handles.

Re:Not even a brick, not a story

[GigaplexNZ]

Sorry, but if removing the battery or otherwise resetting the NVRAM to factory defaults resolves the issue, that's not even remotely "bricked".

Non-Volatile Random Access Memmory

Look up the first part and you'll figure out why removing the battery won't fix it.

"Or otherwise". Even though they were wrong about it not being bricked in this instance, to be fair the AC wasn't completely clueless. Some hardware includes procedures to recover from bad NVRAM data.

Re:Not even a brick, not a story

[Forever Wondering]

Traditional CMOS memory, a moniker for the NV storage used by the BIOS to store configuration information can be implemented as battery backed RAM or other types of memory (e.g. NAND) at the manufacturer's discretion.

---

Some systems have a small reset switch on the motherboard for this purpose that is supposed to reset it to factory default when removing the battery [which might only be used for the system time-of-day clock chip] wouldn't work.

Whether the UEFI data is being stored in the CMOS area, or, as some other posts indicate, being stored in the same flash memory as the BIOS executable code is unclear. Or, there might be a special NAND memory, just for UEFI data, but this would add extra cost. But, if the BIOS executive flash is being co-opted to store UEFI data, this would make either updating the UEFI or the BIOS code a dicey proposition at best.

This is dicey because the BIOS flash is dual banked. When reflashing the BIOS, [which is running out of bank A], the new code is loaded into bank B, a flag gets set, the system is rebooted, and if the [new] bank B code runs correctly, the system will mark bank B as the new default bank to boot from. In the interim mode, if the bank B code fails, the system is reverted to the older but still good bank A code. The process ping pongs on each new BIOS update.

Trying to lay UEFI key data in the same memory space seems ripe for problems.

Hm. Good supply of refurbs?

[Fencepost]

Interesting. Does this mean that before too long there's going to be a nice glut of Samsung laptops being sold as refurbs? Replace, reflash, resell?

Re:Not even a brick, not a story

[DigiShaman]

Depends. Some motherboard vendors will include methods of reflashing a BIOS in the event the boot EEPROM code is hosed. Obviously this process is hard coded in ROM someplace. So perhaps Samsung has such a method in place for unblicking the units.

Re:Unlimited Supply of Laptops?

[snspdaarf]

I might be confused, but don't kernel devs normally destroy their instruments at the end of each show?

Well, when on the Ed Sullivan Show, they have been known to pack explosives into the drum memory.

Re:Unlimited Supply of Laptops?

[Kaldaien]

You can almost certainly re-program it using a JTAG interface... Samsung can do this at the factory if you return it to them. JTAG is not intended for consumer use, though. My old university had a JTAG probe and several adapters to interface with various hardware vendors proprietary interfaces - without this we would have had several multi-thousand dollar bricks in our hardware lab :)

I would hope that Samsung would have the decency to admit a flaw in their design and provide the reprogramming free of charge, but ...

Re:Does windows crash if it has 0 temp space or 0

[amorsen]

As an experiment, I wrote a little progrem that malloc'ed 200MB chunks of memory. I ran this on a Linux box with 2GB of RAM and all the SWAP disabled. The program could malloc 3GB of RAM before the allocation requests failed.

You were running on 32 bit? You will hit the same limit whether you have 256MB or 16GB then.

Re:Does windows crash if it has 0 temp space or 0

[PlusFiveTroll]

Windows 7 and 8 give you messages that you are running low on memory. I'm not 100 percent sure, but I think they kill the largest userspace program (though this just might be the program dying from lack of ram). Running out of (disk) space is generally the bigger problem, linux doesn't like to log you in if it cannot syslog the attempt to disk.

Re:Does windows crash if it has 0 temp space or 0

[whoever57]

You were running on 32 bit? You will hit the same limit whether you have 256MB or 16GB then.

Sorry, what? You are saying that a 32-bit machine with no swap and 256MB or RAM would allow 3GB of memory to malloc'ed? I don't think so. My point was that with a total of 2GB of memory in the system (2GB RAM and zero swap), a program can malloc 3GB.

Re:Does windows crash if it has 0 temp space or 0

[mjg59]

You can malloc() as much as you want until you run out of address space. That's 3GB on 32-bit systems, no matter how much RAM you have. Things will only go wrong if you attempt to use it for anything.

Re:Does windows crash if it has 0 temp space or 0

[whoever57]

Sorry, but no. My tests showed that the amount of memory you can malloc() is dependent on the values in /proc/sys/vm/overcommit_ratio and /proc/sys/vm/overcommit_memory

Re:Does windows crash if it has 0 temp space or 0

[complete loony]

That's definitely a resource leak that I've hit before. It doesn't seem to be cleaned up completely by closing the offending process. Sure you can prolong the reboot for a while. But eventually you can only keep a couple of application windows open before hitting the limit and you'll need to reboot anyway to actually get some work done.

Re:Does windows crash if it has 0 temp space or 0

[mjg59]

I'm sorry, you're right - I was under the impression that overcommit_memory defaulted to permissive rather than heuristic allocation. However, overcommit_ratio is also ignored by default.

Re:Garrett should've kept his mouth shut

[blauregen]

Fix the bug for Linux, let M$ rot in hell.

As I see it, he left the problem to Samsung. I mean, how can you be more blatant in saying: 'Fix this, or else....', than by posting ( supposedly ) working exploit code for the majority of the installed OS-base?

buffer overrun?

[Joe_Dragon]

buffer overrun? and when the storage gets full it starts to over write other config data with junk.

Re:buffer overrun?

[Forever Wondering]

buffer overrun? and when the storage gets full it starts to over write other config data with junk.

Exactly, that's my guess. The question is who/what is/should be responsible for the limit check? The BIOS, OS, app, or hardware?

I got curious so I downloaded the latest UEFI spec. It's a mere 2,224 pages ;-). But, after a quick perusal, it seems that there is a demarcation point. There is a call named "ExitBootServices". Before issuing that, all resources are available, both "Boot Services" and "Runtime Services". After calling ExitBootServices, only runtime services are available. Presumably, this is a limited subset. But, the interesting thing to note is that the BIOS doesn't issue ExitBootServices. It's up to the OS loader or kernel to do so [if they choose to do so at all].

To me, the implication is that each stage, BIOS, OS loader, kernel, etc. are passed the "security responsibility baton" if you will. Thus, it would seem that the Win7/Win8 kernel is responsible to do the limit check, but since Matt's program is given elevated privileges, WinX just assumes that whatever it does is okay.

This is a divergence from Linux (or BSD) kernel philosophy, where the kernel would most likely do some sanity checks before allowing the operation to proceed. That is, linux would probably do the limit check for overrun, but it might trust the [priviledged] app with the data content.

Some others have claimed that the UEFI data is not stored in CMOS/NVRAM, but, rather, comingled within the BIOS flash memory. I mentioned this in another posting about the dual bank flash upgrade process. If the UEFI data goes to CMOS, the damage can be undone via battery removal (or CMOS reset button) as others have suggested.

If, however, the UEFI is truly comingled in the BIOS flash, an overrun could scribble on executable machine instructions that are critical to BIOS operation. The normal flash upgrade program could not fix this, because the BIOS doesn't stay alive long enough to boot it. The only way to recover would be to use a specia external hardware flash programmer (e.g. what they use the first time at the factory).

Old recipe

[manu0601]

That remind me of an assembly language course I took at the University, where we had to implement a mathematical algorithm in x86 assembly. My implementation bricked the PC, leaving it with a BIOS unable to boot or to enter setup. I never understood how it did it, but I now suspect that removing the battery for a while would have cured the disease.

Re:Old recipe

[mikael]

Easy enough to do with early days DOS programming. PC's would cache various disk drive information in unprotected system memory (disk type, number of sectors, number of tracks, number of platters, clusters/sectors chains of open files), then write that stuff back when the file was closed. Anything that corrupted this area of memory would make the PC unbootable. Things could be well and truly messed up if you didn't use the same memory model as third-party API's (tiny, small, medium, large, huge), so 32-bit pointers became 16-bit pointers and vice versa.

Just about everyone those days used Norton Utilities to defragment their drives, clean up lost cluster chains, cluster rings, shared sectors, and everything else that could go wrong like losing files if the PC crashed while the files were still open. Recovering deleted files was the biggest selling point. Fortunately, journaled file systems were invented because of this.

Re:Old recipe

[manu0601]

Easy enough to do with early days DOS programming. PC's would cache various disk drive information in unprotected system memory

Yes, but the bricked PC did not suffered from bad information on disk. It did not attempt to boot, and it could not even enter BIOS setup anymore. IIRC all we had was a message saying BIOS chekcsum was bad

Re:Does windows crash if it has 0 temp space or 0

[wvmarle]

Which is far better than this UEFI issue as Windows while misbehaving doesn't crash, and can actually be recovered (and if you don't know how, a simple reboot will fix it ).

Re:Garrett should've kept his mouth shut

[rahvin112]

Samsung was claiming this is a Linux problem. This needs to be shown to be either a problem with UEFI directly or Samsung's implementation.

The important thing here is that this bug may exist in other hardware with different thresholds. UEFI is just like BIOS in that the only difference between a Phoenix Bios on Dell and a Phoenix BIOS on Samsung is a couple minor changes because of hardware differences. By releasing the code into the wild they are FORCING the parties responsible to fix the problem or face a public relations nightmare of potentially thousands of bricked machines.

Difference between Windows and Linux developers:

[gweihir]

The Linux folks actually read and understand the documentation and then use the mechanisms described. The Windows-folks are usually not so capable.

Re:Sounds like this is by design

[gweihir]

Given that MS has tried this type of "marketing" before, I would say it is a safe bet it is not stupidity this time either. Just a complete lack of morals.

Re:Unlimited Supply of Laptops?

[imnotanumber]

I think it was The Who who popularized that style. Not exactly Heavy Metal...

So secure.

[MadMaverick9]

And I thought that uefi was supposed to make this a better and more secure world.

Now this ...

And uefi can not boot iso9660 file systems. So no booting from a cd or dvd without jumping through hoops.

And uefi relies exclusively on the fat filesystem for its efi partition. That seems kinda backward to me.

Looks to me like we're losing functionality by using uefi.

https://en.wikipedia.org/wiki/Extensible_Firmware_Interface

The UEFI specification explicitly requires support for FAT32 for system partitions, and FAT12/FAT16 for removable media;

Samsung Killswitch malware

[CanEHdian]

It's just a matter of time until this exploit is included in malware, so Samsung better start pumping out those firmware upgrades that guarantee enough space will be left to boot.

Re:32kb should be enough for everyone...

[CanEHdian]

Actually, Bill (Gates) got this one right when he (I have the audio recording) stated that no one needs more than 640k on any computer.

Right. Release the recording or it didn't happen!

Oh no. Guess what I just bought...

[madmarcel]

I bought a Samsung laptop at the start of January :( Not only that...I bought it specifically to install Ubuntu :( Bah.

Now what do I do?

Re:Oh no. Guess what I just bought...

[friend function]

I bought a Samsung laptop at the start of January :( Not only that...I bought it specifically to install Ubuntu :( Bah.

Now what do I do?

I installed Arch in UEFI mode on my new Samsung Series 9 in December... I was getting constant machine check exceptions[1] and found that I had to blacklist the samsung-laptop module from the boot menu (append modprobe.blacklist="samsung-laptop" to your kernel cmdline at boot); this will prevent the samsung-laptop module from loading. Without that I couldn't even boot the Arch USB in UEFI mode! If your Linux distro is using a kernel from 3.7.6+ then this workaround is unneeded, as that module has been disabled from Linux 3.7.6[2]).

Or... you could just choose to install your OS in BIOS mode. :)

[1] http://mjanja.co.ke/2012/12/machine-check-exception-on-samsung-np900x3c-on-uefi-boot/
[2] https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commit;h=98e1ea492c1cf36ea3b391d9b5161681ee4ea18a

Re:Unlimited Supply of Laptops?

[greg1104]

Next you'll be suggesting the Samsung bug is triggered by someone driving a car into their memory pool.

P.S. The boom was at the Smothers Brothers Comedy Hour.

Re:Sounds like this is by design

[Paradigma11]

Given that MS has tried this type of "marketing" before, I would say it is a safe bet it is not stupidity this time either. Just a complete lack of morals.

Ofcourse aside from the minor detail that your safe bet turned out to be wrong.

Re:Sample C code has implementation-defined behavi

[greg1104]

Your suggestion is a good idea to avoid this code being copied to another platform and breaking there. Microsoft does specify what happens here though, and the program as written does the right thing. Both char and unsigned char casts get "Preserve low-order byte" when you start with a larger integer.

I wonder

[drolli]

if that test was covered by warranty. That is an honest question; if i try to reproduce a bug which bricks a device, i do something which if partially intentionally. Its like dropping the device from a height which it should survive but does not.

Re:Unlimited Supply of Laptops?

[snspdaarf]

Apparently, my memory was also packed with explosives. Of course it was the Smothers Brothers. Ed would have had a stroke if someone had blown up a drum (or anything else) on his show.

Re:Does windows crash if it has 0 temp space or 0

[Eunuchswear]

Running out of (disk) space is generally the bigger problem, linux doesn't like to log you in if it cannot syslog the attempt to disk.

Rubbish. There is no way a syslog caller can know whether the log worked or not.

login might fail if it can't write the utmp/wtmp record, if it still does that.

Re:Unlimited Supply of Laptops?

[bill_mcgonigle]

Many flash parts are set up so that if you short two adjacent pins, the flash chip will zero itself out.

Certainly non-trivial, though, and if the parts have any kind of water-proof coating, even more difficult. Once in a while a manufacturer will be kind enough to provide a surface-mount pushbutton momentary switch to make this easier.

Re:Does windows crash if it has 0 temp space or 0

[amorsen]

If you set overcommit aggressively enough or use a sufficiently old Linux kernel, you will be able to malloc() 3GB on any 32 bit system. Assuming you stay with the default 3/1GB memory split.

Any testing of overcommit done on 32 bit systems is a bit useless. 32 bit systems are pretty much embedded-only.

Re:Sounds like this is by design

[gweihir]

Oh? And what evidence do you have for that?

MS manages to be malicious and stupid at the same time...

Re:Difference between Windows and Linux developers

[TheSkepticalOptimist]

Really, so every Linux distro works with every piece of hardware right out of the box then?