Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Samsung Laptop Bug Is Not Linux Specific

timothy posted about a year and a half ago | from the using-french-or-korean-does-it-too dept.

Bug 215

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

cancel ×

215 comments

Sorry! There are no comments related to the filter you selected.

memo to hardware producers (5, Interesting)

RichMan (8097) | about a year and a half ago | (#42845975)

Embrace Linux as an additional test suite for your hardware.

Re:memo to hardware producers (5, Interesting)

Anonymous Coward | about a year and a half ago | (#42846013)

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 (1, Insightful)

Anonymous Coward | about a year and a half ago | (#42846193)

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 (5, Funny)

Anonymous Coward | about a year and a half ago | (#42846307)

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 (5, Interesting)

Anonymous Coward | about a year and a half ago | (#42846333)

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 (2)

LordLimecat (1103839) | about a year and a half ago | (#42847005)

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 (5, Insightful)

Anonymous Coward | about a year and a half ago | (#42847105)

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 (0)

Anonymous Coward | about a year and a half ago | (#42846417)

Pretty sure you could just pull the drive out and drop it in a replacement computer.

Re:memo to hardware producers (2)

iced_773 (857608) | about a year and a half ago | (#42846309)

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 (5, Interesting)

xaxa (988988) | about a year and a half ago | (#42846583)

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 (0)

Anonymous Coward | about a year and a half ago | (#42847389)

I can't imagine the number of defective Samsung laptops out there is large enough to dissuade anyone from disabling a command server. They'd need working exploits for all UEFI capable devices. And even then it's unlikely.

Re:memo to hardware producers (2)

gmuslera (3436) | about a year and a half ago | (#42846649)

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 (1)

Anonymous Coward | about a year and a half ago | (#42847037)

Apple should include it in the next version of iTunes.

Re:memo to hardware producers (0)

Anonymous Coward | about a year and a half ago | (#42846027)

for bricking ur hardware u mean

Re:memo to hardware producers (0)

Anonymous Coward | about a year and a half ago | (#42846171)

you're mom.

Re:memo to hardware producers (4, Informative)

CheshireDragon (1183095) | about a year and a half ago | (#42846037)

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 (5, Insightful)

neonsignal (890658) | about a year and a half ago | (#42846085)

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 (2)

CheshireDragon (1183095) | about a year and a half ago | (#42846163)

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 (4, Informative)

DarwinSurvivor (1752106) | about a year and a half ago | (#42846507)

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 (-1, Troll)

amorsen (7485) | about a year and a half ago | (#42847113)

Yes, UEFI has lots of interesting features. Carefully coded by the BIOS programmers we know and love so much. The ones who failed even the Visual Basic course and so had to settle for BIOS programming.

Re:memo to hardware producers (1)

jedidiah (1196) | about a year and a half ago | (#42847517)

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 (2)

John Hasler (414242) | about a year and a half ago | (#42847523)

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

Re:memo to hardware producers (5, Interesting)

msauve (701917) | about a year and a half ago | (#42846269)

"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 (2)

Kaldaien (676190) | about a year and a half ago | (#42846901)

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 (0)

Anonymous Coward | about a year and a half ago | (#42847139)

How many writes is the EEPROM good for? The last computer of mine that actually told me how many writes was left put it in the 20s and had a countdown every time I flashed it. Of course that was 15 years ago or so; I assume flash memory has gotten much better in terms of write, especially the more expensive stuff, but I have a hard time imagining that they would use stuff that could be written to a lot so they could save money. So I again ask, how many writes are they good for?

Re:memo to hardware producers (1)

Kaldaien (676190) | about a year and a half ago | (#42847305)

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 (3, Funny)

PolygamousRanchKid (1290638) | about a year and a half ago | (#42846055)

How about a warning sticker?

"Warning: UEFI Inside!"

Re:memo to hardware producers (3, Interesting)

marcello_dl (667940) | about a year and a half ago | (#42846311)

"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 (3, Insightful)

LordLimecat (1103839) | about a year and a half ago | (#42847027)

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 (0)

Anonymous Coward | about a year and a half ago | (#42846527)

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

Re:memo to hardware producers (4, Insightful)

RichMan (8097) | about a year and a half ago | (#42846713)

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

They didn't get the memo (4, Funny)

Anonymous Coward | about a year and a half ago | (#42845989)

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 (3, Informative)

YurB (2583187) | about a year and a half ago | (#42846023)

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

Re:They didn't get the memo (2)

DarwinSurvivor (1752106) | about a year and a half ago | (#42846511)

b!=B

Re:They didn't get the memo (0)

Anonymous Coward | about a year and a half ago | (#42846883)

&& k != Ki

If you're going to be a pedant, go big or go home.

Does windows crash if it has 0 temp space or 0 ram (1)

Joe_Dragon (2206452) | about a year and a half ago | (#42846005)

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:Does windows crash if it has 0 temp space or 0 (1)

corychristison (951993) | about a year and a half ago | (#42846331)

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:Does windows crash if it has 0 temp space or 0 (2)

Dwedit (232252) | about a year and a half ago | (#42846579)

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.

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

Anonymous Coward | about a year and a half ago | (#42846749)

Thanks for the Windows 95 tech support tip.

Re:Does windows crash if it has 0 temp space or 0 (3, Interesting)

GigaplexNZ (1233886) | about a year and a half ago | (#42846817)

That's often a case of running out of desktop heap [msdn.com] rather than handles.

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

complete loony (663508) | about a year and a half ago | (#42847533)

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 (1)

xaxa (988988) | about a year and a half ago | (#42846631)

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.

Re:Does windows crash if it has 0 temp space or 0 (3, Informative)

whoever57 (658626) | about a year and a half ago | (#42846797)

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 (1)

amorsen (7485) | about a year and a half ago | (#42847137)

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 (1)

whoever57 (658626) | about a year and a half ago | (#42847441)

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 (1)

mjg59 (864833) | about a year and a half ago | (#42847497)

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 (1)

whoever57 (658626) | about a year and a half ago | (#42847531)

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 (1)

mjg59 (864833) | about a year and a half ago | (#42847567)

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:Does windows crash if it has 0 temp space or 0 (0)

Anonymous Coward | about a year and a half ago | (#42846689)

The point is, this is reserved NVRAM space for UEFI's settings, and not memory or hard drive space that can usually be accessed from Windows or Linux userspace (some other comments have mentioned that UEFI-ready Linux kernels can save small crash dumps to this space). It's not that Windows hangs when the machine starts in this state, it's that the machine doesn't even POST far enough to start Windows (or Linux, or OS X, or any other OS).

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

PlusFiveTroll (754249) | about a year and a half ago | (#42847279)

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.

Unlimited Supply of Laptops? (0)

Anonymous Coward | about a year and a half ago | (#42846029)

It doesn't appear to bother Matthew too much when he irrecoverably bricks a laptop. I wonder if his new employer Nebula is proving all the hardware to destroy or is it his previous employer Red Hat?

Re:Unlimited Supply of Laptops? (1, Informative)

Gaygirlie (1657131) | about a year and a half ago | (#42846067)

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? (2)

mjg59 (864833) | about a year and a half ago | (#42846087)

Unfortunately not in this case.

Re:Unlimited Supply of Laptops? (3, Informative)

Arancaytar (966377) | about a year and a half ago | (#42846379)

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:Unlimited Supply of Laptops? (4, Informative)

Kaldaien (676190) | about a year and a half ago | (#42847135)

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:Unlimited Supply of Laptops? (4, Interesting)

mjg59 (864833) | about a year and a half ago | (#42846075)

30-day hassle-free return policy.

Re:Unlimited Supply of Laptops? (4, Funny)

pushing-robot (1037830) | about a year and a half ago | (#42846143)

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

Re:Unlimited Supply of Laptops? (2, Funny)

Dragonslicer (991472) | about a year and a half ago | (#42846757)

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

Re:Unlimited Supply of Laptops? (3, Funny)

snspdaarf (1314399) | about a year and a half ago | (#42847127)

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.

OS boot entries are in NV storage (4, Interesting)

AdamRosas (2775561) | about a year and a half ago | (#42846077)

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:OS boot entries are in NV storage (0)

Anonymous Coward | about a year and a half ago | (#42846251)

its

Re:OS boot entries are in NV storage (0)

Anonymous Coward | about a year and a half ago | (#42846727)

More windows bloat...

Free Laptops? (1, Interesting)

Anonymous Coward | about a year and a half ago | (#42846103)

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?

Nebula? Red Hat (0)

Anonymous Coward | about a year and a half ago | (#42846219)

Is this the same Matthew Garrett? [linkedin.com] and this one? [wikia.com]

I'm pretty confident that this isn't out of pocket for him ... or he's REALLY dedicated to the Linux kernel and in that case, he needs to get a girlfriend.

Re:Free Laptops? (0)

Anonymous Coward | about a year and a half ago | (#42846481)

You can just get a free replacement from the store if it breaks during the first X days and that is what they probably do. It's not like the store can figure out they intentionally bricked it.

Re:Free Laptops? (4, Insightful)

Skapare (16644) | about a year and a half ago | (#42846559)

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? (1)

gmuslera (3436) | about a year and a half ago | (#42846701)

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.

Extortionist Heaven (2)

resistant (221968) | about a year and a half ago | (#42846109)

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 (1)

rudy_wayne (414635) | about a year and a half ago | (#42846327)

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 (3, Interesting)

Deliveranc3 (629997) | about a year and a half ago | (#42846431)

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 (3, Insightful)

Forever Wondering (2506940) | about a year and a half ago | (#42846529)

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 (2)

John Hasler (414242) | about a year and a half ago | (#42847111)

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.

Online Earn (-1, Offtopic)

rutafalu (2837245) | about a year and a half ago | (#42846121)

http://www.cloud65.com/ [cloud65.com] what Rhonda said I am in shock that a mom can get paid $7233 in four weeks on the internet. did you read this site

Forgot one detail... (2)

Groo Wanderer (180806) | about a year and a half ago | (#42846147)

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... (1)

Prof.Phreak (584152) | about a year and a half ago | (#42846229)

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... (4, Funny)

isorox (205688) | about a year and a half ago | (#42846485)

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... (1)

shentino (1139071) | about a year and a half ago | (#42847173)

That's Ctrl+Alt+F4

Re:Forgot one detail... (1, Funny)

harrkev (623093) | about a year and a half ago | (#42846267)

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

Re:Forgot one detail... (0)

Anonymous Coward | about a year and a half ago | (#42846495)

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

Oh man. That place had all my favorite porn!

Re:Forgot one detail... (0)

Anonymous Coward | about a year and a half ago | (#42846619)

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

Oh man. That place had all my favorite porn!

Meh, they never had anything new, I already had all the porn they had.

Re:Forgot one detail... (1)

Skapare (16644) | about a year and a half ago | (#42846573)

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.

Not even a brick, not a story (0)

Anonymous Coward | about a year and a half ago | (#42846235)

Sorry, but if removing the battery or otherwise resetting the NVRAM to factory defaults resolves the issue, that's not even remotely "bricked".
There are TONS of ways to screw something up to the point of needing factory default reset. Just because you find some new clever way of doing it doesn't make it a bricking... Please reserve the word for cases where firmware is so screwed up the problem can only be resolved with a soldering iron.

Also, what is so special about a userspace program preventing the system from booting. The OS installer was a userspace program.

The OS SHOULD be able to manipulate your firmware, this lets it do fancy things like manage boot order, detect the current boot device - which is an educated guess on a legacy BIOS, configure addon firmware - LAN/SAN boot, configure OOB management cards etc. Most of you already flash your BIOS from userspace. [If] You have access to entirely overwrite the thing, you SHOULD have more fine grained control over firmware from the OS. Of course the OS requires administrator access to do this... DUH.

Queue up EFI haters (cuz teh Macs haz it) & people who think requiring kernels drivers to do double duty providing both kernel and their own special userspace interfaces to addon cards is AWESOME because dood, you should just give all your driver source to us anyway that way we can haz (semi-not-really) standard /sys interface to it for uzer to VI it.

Yes, I am jaded.

Re:Not even a brick, not a story (5, Informative)

mjg59 (864833) | about a year and a half ago | (#42846351)

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:Not even a brick, not a story (1)

DigiShaman (671371) | about a year and a half ago | (#42847089)

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:Not even a brick, not a story (1)

DarwinSurvivor (1752106) | about a year and a half ago | (#42846537)

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:Not even a brick, not a story (1)

GigaplexNZ (1233886) | about a year and a half ago | (#42846887)

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 (0)

Anonymous Coward | about a year and a half ago | (#42847337)

I wouldn't be surprised if there was such a procedure for these Samsungs. Even cheap tablets like those old GTablets had an interface to recover from bad flashes to NVRAM.

Re:Not even a brick, not a story (1)

Forever Wondering (2506940) | about a year and a half ago | (#42846929)

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.

32kb should be enough for everyone... (0)

Anonymous Coward | about a year and a half ago | (#42846385)

oooops

Re:32kb should be enough for everyone... (0)

Anonymous Coward | about a year and a half ago | (#42847499)

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.
Man was a genius!

Sounds like this is by design (0)

fustakrakich (1673220) | about a year and a half ago | (#42846413)

Microsoft doesn't want you installing other OSs on their machines.

Re:Sounds like this is by design (2)

gmuslera (3436) | about a year and a half ago | (#42846721)

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

48 vars, not 36, read the code (1)

insecuritiez (606865) | about a year and a half ago | (#42846593)

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

Re:48 vars, not 36, read the code (1)

YurB (2583187) | about a year and a half ago | (#42847361)

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 (1)

Old Wolf (56093) | about a year and a half ago | (#42846605)

(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:Sample C code has implementation-defined behavi (0)

Anonymous Coward | about a year and a half ago | (#42847477)

Huh? Someone needs a K&R refresher...

Not ready (1)

Anonymous Coward | about a year and a half ago | (#42846661)

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

Re:Not ready (0)

Anonymous Coward | about a year and a half ago | (#42847275)

shows me that samsung was to arrogant or ignorant to follow spec

Hm. Good supply of refurbs? (2)

Fencepost (107992) | about a year and a half ago | (#42846955)

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?

Garrett should've kept his mouth shut (0)

Mister Liberty (769145) | about a year and a half ago | (#42847301)

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

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>