Slashdot Mirror

← Back to Stories (view on slashdot.org)

Samsung Laptop Bug Is Not Linux Specific

Posted by timothy on from the using-french-or-korean-does-it-too dept.

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

70 of 215 comments (clear)

  1. memo to hardware producers by RichMan · · Score: 5, Interesting

    Embrace Linux as an additional test suite for your hardware.

    1. Re:memo to hardware producers by Anonymous Coward · · Score: 5, Interesting

      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.

    2. Re:memo to hardware producers by CheshireDragon · · Score: 4, Informative

      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.

      --
      "That's right...I said it."
    3. Re:memo to hardware producers by PolygamousRanchKid+ · · Score: 3, Funny

      How about a warning sticker?

      "Warning: UEFI Inside!"

      --
      Schroedinger's Brexit: The UK is both in and out of the EU at the same time!
    4. Re:memo to hardware producers by neonsignal · · Score: 5, Insightful

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

    5. Re:memo to hardware producers by CheshireDragon · · Score: 2

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

      --
      "That's right...I said it."
    6. Re:memo to hardware producers by msauve · · Score: 5, Interesting

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

      --
      "National Security is the chief cause of national insecurity." - Celine's First Law
    7. Re:memo to hardware producers by Anonymous Coward · · Score: 5, Funny

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

    8. Re:memo to hardware producers by iced_773 · · Score: 2

      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.

    9. Re:memo to hardware producers by marcello_dl · · Score: 3, Interesting

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

      --
      ---- MISSING MISCELLANEOUS DATA SEGMENT --- [sigdash] trolololol
    10. Re:memo to hardware producers by Anonymous Coward · · Score: 5, Interesting

      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

    11. Re:memo to hardware producers by DarwinSurvivor · · Score: 4, Informative

      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.

    12. Re:memo to hardware producers by xaxa · · Score: 5, Interesting

      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.

    13. Re:memo to hardware producers by gmuslera · · Score: 2

      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.

    14. Re:memo to hardware producers by RichMan · · Score: 4, Insightful

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

    15. Re:memo to hardware producers by Kaldaien · · Score: 2

      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 :-\

    16. Re:memo to hardware producers by LordLimecat · · Score: 2

      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.

    17. Re:memo to hardware producers by LordLimecat · · Score: 3, Insightful

      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.

    18. Re: memo to hardware producers by Anonymous Coward · · Score: 5, Insightful

      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.

    19. Re:memo to hardware producers by John+Hasler · · Score: 2

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

      --
      Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
    20. Re:memo to hardware producers by wvmarle · · Score: 2

      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.

    21. Re:memo to hardware producers by rahvin112 · · Score: 2

      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.

    22. Re:memo to hardware producers by Anonymous Coward · · Score: 2, Informative

      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.

    23. Re:memo to hardware producers by Culture20 · · Score: 2

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

    24. Re:memo to hardware producers by tlhIngan · · Score: 4, Informative

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

    25. Re:memo to hardware producers by PPH · · Score: 2

      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.

      --
      Have gnu, will travel.
    26. Re: memo to hardware producers by MaskedSlacker · · Score: 5, Insightful

      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.

    27. Re:memo to hardware producers by sdsucks · · Score: 2

      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.

    28. Re:memo to hardware producers by pjt33 · · Score: 2

      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.

    29. Re: memo to hardware producers by Anonymous Coward · · Score: 2, Funny

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

    30. Re:memo to hardware producers by silanea · · Score: 2, Insightful

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

      --
      Rudolf Hess edited Mein Kampf. He was the very first grammar nazi.
    31. Re:memo to hardware producers by drinkypoo · · Score: 2

      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.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    32. Re: memo to hardware producers by greg1104 · · Score: 2

      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.

    33. Re: memo to hardware producers by gerddie · · Score: 3, Insightful

      [..]

      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.

    34. Re:memo to hardware producers by Anonymous Coward · · Score: 2, Interesting

      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.

    35. Re:memo to hardware producers by amorsen · · Score: 2

      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.

      --
      Finally! A year of moderation! Ready for 2019?
  2. They didn't get the memo by Anonymous Coward · · Score: 4, Funny

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

    36k clearly isn't enough for anyone.

    1. Re:They didn't get the memo by YurB · · Score: 3, Informative

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

    2. Re:They didn't get the memo by DarwinSurvivor · · Score: 2

      b!=B

  3. Re:Unlimited Supply of Laptops? by mjg59 · · Score: 4, Interesting

    30-day hassle-free return policy.

  4. OS boot entries are in NV storage by AdamRosas · · Score: 4, Interesting

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

  5. Re:Unlimited Supply of Laptops? by mjg59 · · Score: 2

    Unfortunately not in this case.

  6. Extortionist Heaven by resistant · · Score: 2

    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.

    --
    A truly excellent pizza parlor is a delight unto the heavens. Treasure the sauce and the toppings!
    1. Re:Extortionist Heaven by Deliveranc3 · · Score: 3, Interesting

      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.

    2. Re:Extortionist Heaven by Forever+Wondering · · Score: 3, Insightful

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

      --
      Like a good neighbor, fsck is there ...
    3. Re:Extortionist Heaven by John+Hasler · · Score: 2

      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.

      --
      Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
    4. Re:Extortionist Heaven by Forever+Wondering · · Score: 2

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

      --
      Like a good neighbor, fsck is there ...
    5. Re:Extortionist Heaven by fuzzyfuzzyfungus · · Score: 2

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

    6. Re:Extortionist Heaven by JWSmythe · · Score: 2

          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.

      --
      Serious? Seriousness is well above my pay grade.
  7. Re:Unlimited Supply of Laptops? by pushing-robot · · Score: 4, Funny

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

    --
    How can I believe you when you tell me what I don't want to hear?
  8. Forgot one detail... by Groo+Wanderer · · Score: 2

    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

    1. Re:Forgot one detail... by isorox · · Score: 4, Funny

      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?

    2. Re:Forgot one detail... by JWSmythe · · Score: 2

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

      --
      Serious? Seriousness is well above my pay grade.
  9. Re:Not even a brick, not a story by mjg59 · · Score: 5, Informative

    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.

  10. Re:Unlimited Supply of Laptops? by Arancaytar · · Score: 3, Informative

    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.

  11. Re:Free Laptops? by Skapare · · Score: 4, Insightful

    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.

    --
    now we need to go OSS in diesel cars
  12. Re:Does windows crash if it has 0 temp space or 0 by Dwedit · · Score: 2

    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.

  13. Re:Sounds like this is by design by gmuslera · · Score: 2

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

  14. Re:Unlimited Supply of Laptops? by Dragonslicer · · Score: 2, Funny

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

  15. Re:Does windows crash if it has 0 temp space or 0 by whoever57 · · Score: 3, Informative

    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.

    --
    The real "Libtards" are the Libertarians!
  16. Re:Does windows crash if it has 0 temp space or 0 by GigaplexNZ · · Score: 3, Interesting

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

  17. Hm. Good supply of refurbs? by Fencepost · · Score: 2

    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?

    --
    fencepost
    just a little off
  18. Re:Unlimited Supply of Laptops? by snspdaarf · · Score: 3, Funny

    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.

    --
    Why, without your clothes, you're naked, Miss Dudley!
  19. Re:Unlimited Supply of Laptops? by Kaldaien · · Score: 4, Informative

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

  20. Old recipe by manu0601 · · Score: 2

    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.

    1. Re:Old recipe by mikael · · Score: 2

      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.

      --
      Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
  21. Re:Free Laptops? by wvmarle · · Score: 3, Informative

    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.

  22. Difference between Windows and Linux developers: by gweihir · · Score: 3, Insightful

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

    --
    Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
  23. Re:Not ready by gweihir · · Score: 2

    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.

    --
    Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
  24. Re:Oh no. Guess what I just bought... by friend+function · · Score: 2

    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