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".
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.
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).
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).
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.
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].
On the other hand, it could break things horribly especially for those failsafe situations.
it sounds like yet another example for of change for it's own sake not driven by any actual end user requirements that is actually being done DESPITE end user objections.
I think you and the person you replied to have hit the mark. Very few people use VT's. They're more likely to log into X11 and bring up an xterm [or whatever]. Personally, I only use VT's if I want to fix an autostart program before logging into X11. Minimal functionality, such as VT100/xterm compatibility to run vi/emacs is all that is really needed. The guy's time might be better spent in developing a super-duper xterm replacement [that also works with non-X11 graphics systems like Unity].
As long as the kernel is alive, but X11 is not, being able to CTRL-ALT-F2 to get a [guaranteed] VT is important. Also, if the kernel panics, goes to single user or emergency mode, this isn't something that one wants to leave to userspace to perform.
If anything, I'd like to see it go the other way. Being able to boot without rhgb/quiet and prompt/single-step:
- ramdisk operations
- the kernel bringup [initializations before systemd can be started]
- the boot sequence [all operations after systemd and before X11 is ready to go]
to be able to see the messages that get scrolled off the screen before the kernel ultimately freezes or panics, due to misconfiguration or an errant driver or malfunctioning piece of hardware.
NDA can't extend to things learned independently from the company,
True, but that doesn't apply here as this was all about the layout of one of the company's printed circuit boards.
and his "friend" does not represent the company because he was not authorized to do so.
Where do you think this "authorization" comes from [has to come from] if there's an NDA in place? Once an NDA is in place, any engineer can talk to anybody who is under an NDA for anything covered under the NDA. If you think otherwise, you've never worked in an engineering organization before.
Also, how do you know that the "friend" was not "authorized"? He could easily have been told by his VP of engineering to go ask the poster about the board "on the quiet". This goes on more than you seem to realize.
Besides, the company in question is a chip design company. The company's proprietary "secret sauce" is in the chip they design, not the layout of the board that it goes on. It was the layout of the PC board that had the mistakes in question. They don't really care about the board--it's just a necessary evil.
In fact, this board is probably a "reference design" board and not an end product. Chip companies almost give these SDK boards away for free to other companies that will "design in" the chips into consumer designs. For the chip company, it's "give them the razor" [the SDK board], so you can sell them the blades [the chips that they design].
The board layout mistakes could have been things like [to name but a few]:
- the clock lines on the board were too long
- multiple ASIC's sharing a single voltage regulator
- voltage regulator for an ASIC was placed on the far end of the board instead of directly next to its ASIC
- improper shielding/isolation of analog circuitry [if any]
- blind and buried vias
None of these problems are at all proprietary [or unique] to the given company.
One might question the poster's trusting nature, but not his trustworthiness. In short, the scenario described is entirely plausible, based upon my 35+ years experience as a computer engineer.
That we know this much about the project means it's not one of the projects that are THAT deep and dark.
Actually, we only know about what Shawley has.
We don't know whether Phantom Works had such a project, has one, or will have one in the future. Even if they had one, they could not admit to having it, even if it were blatantly obvious to the whole world that they were working on it, they would still be required to deny its existence.
They probably met with Shawley because, in part, refusing to would have tipped their hand a bit (e.g. that they were working on something). Also, they might have sat there stone faced [or poker faced] and let him talk. If they got insight from it, so much the better. They could then, quite easily, just say they have no interest whatsoever. In the end, they gave away nothing (e.g. we neither confirm nor deny...).
No, given their nature, if it worked they would be producing glossy brochures showing spacecraft flying to Mars or where-ever.
While that might be true for Boeing in general, for true black project departments, this is a no-no. For example, at Perkin Elmer, which was doing the engineering for the KH-9, one of the engineers had a heart attack on the job and died. The other engineers were not permitted to tell the guy's widow even how he died (e.g. peacefully, etc.) until after the project was declassified some 25 years after the last KH-9 was decommissioned. That's how secretive they can be.
There is no reason why they would keep this a secret;
Once again, I think you underestimate just how deep and dark these projects sometimes are.
the spy satellite world is not suffering from a lack of reaction mass.
Most KH satellites don't just go around in a fixed [polar] orbit. Their orbits must be constantly adjusted so they can observe a trouble spot in real time (e.g. they can't wait 5 days for the orbit to pass over the spot naturally--they must burn fuel to change the orbit so it's in the right place on the next pass). Considerable mathematical effort is expended in the orbital adjustment calculations, designed to minimize the fuel cost of adjusting the orbit. Sometimes, compromises have to be made, to conserving fuel cost against getting there ASAP. Having a satellite that has no such downside, would be a [closely guarded] strategic advantage.
If they even thought it possibly could work, they would hire Shawyer.
Given that he's a U.K. citizen, it's unlikely he could get the security clearance necessary. Or, the Phantom Works people had reservations about him specifically, for whatever reason (e.g. either his general ability to work well with others, or his desire to keep his work public--to name just a few).
Phantom Works just said they're not working with Shawyer. They didn't say the drive doesn't work. Given their nature, if the drive did work, they wouldn't disclose that because it would have profound advantages for classified work (e.g. KH-11/KH-12/etc. spy satellite maneuvering).
I have a 2wire 2701HG-B router (the standard one AT&T uses for DSL). It also records number of bytes sent/received. I have a program that wakes up every 5 minutes and logs these values to disk. So, I have a persistent record of usage, dating back years that can produce a strip chart for each 5 minute interval. Another program reads the log and produces reports for usage per-hour, per-day, per-month for all time periods since AT&T first introduced its cap. Should I ever need to dispute, I've got the [better] evidence [hopefully;-)]
How about using the [very simple] hash (e.g. slight mangling) of a common phrase. The phrase is easy to remember. A simple program produces a password.
---
The criteria that a lot of websites need:
- uppercase and lowercase
- must have digits
- must have some non-alphanumeric chars [many don't allow the full set but underscore is usually safe]
I created a very simple perl script to do this. Here are some generated passwords from common phrases that are 2-4 words in length:
12_kCq_wRb_xFn_205
16_pMj_rVd_yZl_sGd_221
The mangling isn't trying to be cryptographically hard by any means. I don't consider the mangling to particularly clever. But, these seem to me to be sufficiently strong passwords. I haven't run them over a PW strength assessment algorithm but they're stronger than PWs I've used at various websites that rate my personal ones as strong.
The groupings used here are deliberate as one PW in a group might clue in the other(s). If you'd like to take up the challenge, a few hints: (1) phrases you've surely typed before, (2) a common comparison, (3) part of a well known company logo/trademark, (4) an author, a novel, and the author's real name.
[If anyone's interested] I'll post the original phrases, the algorithm description, and the perl script [if I can figure out the html tag slashdot needs for unformatted] tomorrow as a reply to this post.
He's still under NDA, so the employee would be free to do so. In its heyday, that's how Silicon Valley companies used to work before all the lawyers got involved.
As I am not a biologist, feel free to correct anything I say here.
---
As I understand it, the ribosome is responsible for taking the RNA and creating the protein. IIRC, it also folds the protein. A single protein can be folded in a few different ways to produce different building blocks.
There is also some sort of checking mechanism that checks for proper sequence and proper folding. If there is an error, the constructed/folded protein is broken down and the process is retried. Sometimes, the error checking mechanism fails and bad proteins are released, resulting in certain diseases such as Parkinson's or Creutzfeldt-Jakob.
There are parallel projects to computationally model protein folding. Also, there is a highly successful project, based on crown sourcing, the "protein folding game".
So, my question is, isn't it necessary to understand the folding first, and then go for the protein function annotation? Or, more broadly, how do the two projects/approaches interact?
Using study in this way [along with threads] suggests you work for Yahoo [which used a lot of perl in the early days], or Google, or Ask. I've not used study personally [because I'm only applying a few regexs/line], but for "big data" searches, it can be a true win.
I do, however, have a few programs that use threads. I wrote a [thin] layer above the threads to implement a boss/worker model easily and the programs implement a map/reduce-like operation. I used to have a script that did a "grep -r -l" and then vi'ed the resulting list. Now that same script uses perl regexes with multiple threads and feeds the final reduce list to vi. It's _much_ faster.
I've been using perl since perl4 circa 1993 and I had about 250,000 lines of tcsh shell script, sed, awk, etc. I tossed that all away after I discovered perl and now have about 120,000 lines of perl (30% is comments/whitespace).
One of the truly nice things about perl is that many of the features are grown "organically". That is, it wasn't like somebody said "Oh, the theoretical literature says that a modern language should have thus-n-such feature so let's add it" (e.g. the Gnome 3 model). Most of perl's features came out as solutions to practical problems. That's why it's comparatively lean-and-mean. The backported features of perl6 are an example of this. One of my [minor] peeves has always been the lack of switch/case functionality from C. With perl6's "given" having been backported into perl5, it takes away that issue.
The people that find perl's syntax "scary" assume that they have to use the "scary" syntax. I'm also a C programmer, so most of my perl looks a lot like C. This is done intentionally as my style preference. I implement C structs as hashes: $x = {}; $x->{y} = 5; $x->{z} = 7; Everything is in a function of some kind. I do a C main function [renamed "master" to avoid confusion with perl's "main" package]. The first line of each of my perl programs [after use statements] is: "master(@ARGV);"
But, I've also used many of perl's advanced features (classes, blessed references, etc.) at one time or another. perl allows filters to be tacked onto its interpreter so that input files can be filtered. This was originally done to implement the byteloader. I co-op'ed this to implement a filter that implements CPP-like functionality for my scripts. Perhaps not what the designers originally intended. When I first started using this in the 1990's it was undocumented [and I thought I was being really clever in figuring it out]. Now it's part of the standard perl docs.
perl6 is no longer referred to as a [future] rev of perl5. It's now referred to as a "sister language". But, IIRC, the perl6 interpreter [when it finally gets finished], will be able to auto-detect perl5 or perl6 and allow one to intermix perl5 and perl6 from different files in one program. In short, perl5 isn't going away any time soon. The perl5 team will be maintaining/improving the perl5 interpreter for a long time after perl6 is truly deployed. In fact, the perl5 guys might just implement 100% of perl6 as extensions to perl5 because they got tired of waiting for the perl6 team to produce a robust interpreter:-)
You are so right. I benchmarked about 5 regex engines [a _long_ time ago], and at that time perl's engine was [minimum] 10x faster. If I get some spare time, I'll have to resurrect that benchmarker from the deep archive and run it again to see how the current competition stacks up.
Linux has already solved the problem in the x32 port. The various time related types have already been switched to 64 bit in anticipation of this. This was/is a non-issue for 64 bit mode [because the time_t was a long which is 64 bits]. In x32, time_t-like types have already been defined as 64 bit entities (e.g. long long). Something similar is already being done for ports to other architectures. My guess is that all this anticipatory work will be 100% complete within 2-3 years max [if it hasn't been already]
--
This would not work for current i686 ports, but they will all be long gone. Here's why:
- All x86 CPUs sold today are 64 bit. They can support x86 kernel/app mode.
- All legacy systems currently in the field that have 32 bit only hardware will simply wear out and die.
- The useful lifetime for hard disks is about 5 years. Most systems get replaced then.
- But, even after trying to keep a system alive after 5 years by upgrading the disks, most systems (e.g. the motherboard) die after 10 years
Since the software is being changed _now_ and we're talking 25 years until the problem shows up, this is a non-issue...
Your response makes me think... How about a FOIA request against a given petition? They _would_ be required [by law] to respond to that. Ups the ante a bit. They could only not provide such info if they declared it as a matter of national security [or some such]. That would be hard to do given that the petitions are public domain.
Slashdot Mirror
See my other replies
http://science.slashdot.org/comments.pl?sid=3443657&cid=42829549
and http://science.slashdot.org/comments.pl?sid=3443657&cid=42840735
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".
---
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.
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).
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).
---
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.
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].
On the other hand, it could break things horribly especially for those failsafe situations.
it sounds like yet another example for of change for it's own sake not driven by any actual end user requirements that is actually being done DESPITE end user objections.
I think you and the person you replied to have hit the mark. Very few people use VT's. They're more likely to log into X11 and bring up an xterm [or whatever]. Personally, I only use VT's if I want to fix an autostart program before logging into X11. Minimal functionality, such as VT100/xterm compatibility to run vi/emacs is all that is really needed. The guy's time might be better spent in developing a super-duper xterm replacement [that also works with non-X11 graphics systems like Unity].
As long as the kernel is alive, but X11 is not, being able to CTRL-ALT-F2 to get a [guaranteed] VT is important. Also, if the kernel panics, goes to single user or emergency mode, this isn't something that one wants to leave to userspace to perform.
If anything, I'd like to see it go the other way. Being able to boot without rhgb/quiet and prompt/single-step:
- ramdisk operations - the kernel bringup [initializations before systemd can be started]
- the boot sequence [all operations after systemd and before X11 is ready to go]
to be able to see the messages that get scrolled off the screen before the kernel ultimately freezes or panics, due to misconfiguration or an errant driver or malfunctioning piece of hardware.
NDA can't extend to things learned independently from the company,
True, but that doesn't apply here as this was all about the layout of one of the company's printed circuit boards.
and his "friend" does not represent the company because he was not authorized to do so.
Where do you think this "authorization" comes from [has to come from] if there's an NDA in place? Once an NDA is in place, any engineer can talk to anybody who is under an NDA for anything covered under the NDA. If you think otherwise, you've never worked in an engineering organization before.
Also, how do you know that the "friend" was not "authorized"? He could easily have been told by his VP of engineering to go ask the poster about the board "on the quiet". This goes on more than you seem to realize.
Besides, the company in question is a chip design company. The company's proprietary "secret sauce" is in the chip they design, not the layout of the board that it goes on. It was the layout of the PC board that had the mistakes in question. They don't really care about the board--it's just a necessary evil.
In fact, this board is probably a "reference design" board and not an end product. Chip companies almost give these SDK boards away for free to other companies that will "design in" the chips into consumer designs. For the chip company, it's "give them the razor" [the SDK board], so you can sell them the blades [the chips that they design].
The board layout mistakes could have been things like [to name but a few]:
- the clock lines on the board were too long
- multiple ASIC's sharing a single voltage regulator
- voltage regulator for an ASIC was placed on the far end of the board instead of directly next to its ASIC
- improper shielding/isolation of analog circuitry [if any]
- blind and buried vias
None of these problems are at all proprietary [or unique] to the given company.
One might question the poster's trusting nature, but not his trustworthiness. In short, the scenario described is entirely plausible, based upon my 35+ years experience as a computer engineer.
That we know this much about the project means it's not one of the projects that are THAT deep and dark.
Actually, we only know about what Shawley has.
We don't know whether Phantom Works had such a project, has one, or will have one in the future. Even if they had one, they could not admit to having it, even if it were blatantly obvious to the whole world that they were working on it, they would still be required to deny its existence.
They probably met with Shawley because, in part, refusing to would have tipped their hand a bit (e.g. that they were working on something). Also, they might have sat there stone faced [or poker faced] and let him talk. If they got insight from it, so much the better. They could then, quite easily, just say they have no interest whatsoever. In the end, they gave away nothing (e.g. we neither confirm nor deny ...).
No, given their nature, if it worked they would be producing glossy brochures showing spacecraft flying to Mars or where-ever.
While that might be true for Boeing in general, for true black project departments, this is a no-no. For example, at Perkin Elmer, which was doing the engineering for the KH-9, one of the engineers had a heart attack on the job and died. The other engineers were not permitted to tell the guy's widow even how he died (e.g. peacefully, etc.) until after the project was declassified some 25 years after the last KH-9 was decommissioned. That's how secretive they can be.
There is no reason why they would keep this a secret;
Once again, I think you underestimate just how deep and dark these projects sometimes are.
the spy satellite world is not suffering from a lack of reaction mass.
Most KH satellites don't just go around in a fixed [polar] orbit. Their orbits must be constantly adjusted so they can observe a trouble spot in real time (e.g. they can't wait 5 days for the orbit to pass over the spot naturally--they must burn fuel to change the orbit so it's in the right place on the next pass). Considerable mathematical effort is expended in the orbital adjustment calculations, designed to minimize the fuel cost of adjusting the orbit. Sometimes, compromises have to be made, to conserving fuel cost against getting there ASAP. Having a satellite that has no such downside, would be a [closely guarded] strategic advantage.
If they even thought it possibly could work, they would hire Shawyer.
Given that he's a U.K. citizen, it's unlikely he could get the security clearance necessary. Or, the Phantom Works people had reservations about him specifically, for whatever reason (e.g. either his general ability to work well with others, or his desire to keep his work public--to name just a few).
Phantom Works just said they're not working with Shawyer. They didn't say the drive doesn't work. Given their nature, if the drive did work, they wouldn't disclose that because it would have profound advantages for classified work (e.g. KH-11/KH-12/etc. spy satellite maneuvering).
I have a 2wire 2701HG-B router (the standard one AT&T uses for DSL). It also records number of bytes sent/received. I have a program that wakes up every 5 minutes and logs these values to disk. So, I have a persistent record of usage, dating back years that can produce a strip chart for each 5 minute interval. Another program reads the log and produces reports for usage per-hour, per-day, per-month for all time periods since AT&T first introduced its cap. Should I ever need to dispute, I've got the [better] evidence [hopefully ;-)]
---
The criteria that a lot of websites need:
- uppercase and lowercase
- must have digits
- must have some non-alphanumeric chars [many don't allow the full set but underscore is usually safe]
I created a very simple perl script to do this. Here are some generated passwords from common phrases that are 2-4 words in length:
12_kCq_wRb_xFn_205
16_pMj_rVd_yZl_sGd_221
37_lPp_dNs_gNr_S_99
193_mSh_rTs_cVs_194
104_mRt_pCn_T_105
109_lCn_lBd_D_180
55_mRt_tSn_kCr_pSf_nSr_S_186
The mangling isn't trying to be cryptographically hard by any means. I don't consider the mangling to particularly clever. But, these seem to me to be sufficiently strong passwords. I haven't run them over a PW strength assessment algorithm but they're stronger than PWs I've used at various websites that rate my personal ones as strong.
The groupings used here are deliberate as one PW in a group might clue in the other(s). If you'd like to take up the challenge, a few hints: (1) phrases you've surely typed before, (2) a common comparison, (3) part of a well known company logo/trademark, (4) an author, a novel, and the author's real name.
[If anyone's interested] I'll post the original phrases, the algorithm description, and the perl script [if I can figure out the html tag slashdot needs for unformatted] tomorrow as a reply to this post.
He's still under NDA, so the employee would be free to do so. In its heyday, that's how Silicon Valley companies used to work before all the lawyers got involved.
---
As I understand it, the ribosome is responsible for taking the RNA and creating the protein. IIRC, it also folds the protein. A single protein can be folded in a few different ways to produce different building blocks.
There is also some sort of checking mechanism that checks for proper sequence and proper folding. If there is an error, the constructed/folded protein is broken down and the process is retried. Sometimes, the error checking mechanism fails and bad proteins are released, resulting in certain diseases such as Parkinson's or Creutzfeldt-Jakob.
There are parallel projects to computationally model protein folding. Also, there is a highly successful project, based on crown sourcing, the "protein folding game".
So, my question is, isn't it necessary to understand the folding first, and then go for the protein function annotation? Or, more broadly, how do the two projects/approaches interact?
In Russia, they had a saying: "With capitalism, man exploits man. With communism, it's the other way 'round ..."
Using study in this way [along with threads] suggests you work for Yahoo [which used a lot of perl in the early days], or Google, or Ask. I've not used study personally [because I'm only applying a few regexs/line], but for "big data" searches, it can be a true win.
I do, however, have a few programs that use threads. I wrote a [thin] layer above the threads to implement a boss/worker model easily and the programs implement a map/reduce-like operation. I used to have a script that did a "grep -r -l" and then vi'ed the resulting list. Now that same script uses perl regexes with multiple threads and feeds the final reduce list to vi. It's _much_ faster.
I've been using perl since perl4 circa 1993 and I had about 250,000 lines of tcsh shell script, sed, awk, etc. I tossed that all away after I discovered perl and now have about 120,000 lines of perl (30% is comments/whitespace).
One of the truly nice things about perl is that many of the features are grown "organically". That is, it wasn't like somebody said "Oh, the theoretical literature says that a modern language should have thus-n-such feature so let's add it" (e.g. the Gnome 3 model). Most of perl's features came out as solutions to practical problems. That's why it's comparatively lean-and-mean. The backported features of perl6 are an example of this. One of my [minor] peeves has always been the lack of switch/case functionality from C. With perl6's "given" having been backported into perl5, it takes away that issue.
The people that find perl's syntax "scary" assume that they have to use the "scary" syntax. I'm also a C programmer, so most of my perl looks a lot like C. This is done intentionally as my style preference. I implement C structs as hashes: $x = {}; $x->{y} = 5; $x->{z} = 7; Everything is in a function of some kind. I do a C main function [renamed "master" to avoid confusion with perl's "main" package]. The first line of each of my perl programs [after use statements] is: "master(@ARGV);"
But, I've also used many of perl's advanced features (classes, blessed references, etc.) at one time or another. perl allows filters to be tacked onto its interpreter so that input files can be filtered. This was originally done to implement the byteloader. I co-op'ed this to implement a filter that implements CPP-like functionality for my scripts. Perhaps not what the designers originally intended. When I first started using this in the 1990's it was undocumented [and I thought I was being really clever in figuring it out]. Now it's part of the standard perl docs.
perl6 is no longer referred to as a [future] rev of perl5. It's now referred to as a "sister language". But, IIRC, the perl6 interpreter [when it finally gets finished], will be able to auto-detect perl5 or perl6 and allow one to intermix perl5 and perl6 from different files in one program. In short, perl5 isn't going away any time soon. The perl5 team will be maintaining/improving the perl5 interpreter for a long time after perl6 is truly deployed. In fact, the perl5 guys might just implement 100% of perl6 as extensions to perl5 because they got tired of waiting for the perl6 team to produce a robust interpreter :-)
You are so right. I benchmarked about 5 regex engines [a _long_ time ago], and at that time perl's engine was [minimum] 10x faster. If I get some spare time, I'll have to resurrect that benchmarker from the deep archive and run it again to see how the current competition stacks up.
--
This would not work for current i686 ports, but they will all be long gone. Here's why:
- All x86 CPUs sold today are 64 bit. They can support x86 kernel/app mode.
- All legacy systems currently in the field that have 32 bit only hardware will simply wear out and die.
- The useful lifetime for hard disks is about 5 years. Most systems get replaced then.
- But, even after trying to keep a system alive after 5 years by upgrading the disks, most systems (e.g. the motherboard) die after 10 years
Since the software is being changed _now_ and we're talking 25 years until the problem shows up, this is a non-issue ...
The Boris Katz comment, IIRC, was opined by Steve Wozniak a number of years back [not a ripoff, just that clever minds sometimes think alike].
Your response makes me think ... How about a FOIA request against a given petition? They _would_ be required [by law] to respond to that. Ups the ante a bit. They could only not provide such info if they declared it as a matter of national security [or some such]. That would be hard to do given that the petitions are public domain.
IIRC, current lithium ion battery production produces a fair amount of pollution. Would the new process improve on that?
Getting 100,000 signatures on a petition to lower the requirement to 50,000 might have just the right touch of irony ...
It's resting.
No, it's pining ...