The Trustzone CPU hardware is documented in the ARM Architecture Reference Manual v7-a (yes, the ARM ARM). This manual is free, but requires registration at the ARM website, and you may have to explain why you need it (I did when I downloaded it 2 years ago, and it's not easy to tell if that's still the case or not). It is not under NDA, but you have to agree to some terms, such as I can't make a CPU and say it is an ARM CPU. As far as I know, all ARM instruction set references are under this type of registration protection now (although that wasn't always the case).
The CPU resets to secure mode. It's then up to the boot firmware to decide whether to go through the effort to set up the non-secure domain, or just stay secure when the OS is loaded. In general, the OS doesn't care. But some CPU registers are locked down and cannot be changed from non-secure mode. It's generally easier to stay secure since less has to be initialized, and you don't need hypervisor code, even if it's a trivial implementation.
What I suspect TI is doing is they have some "interesting" hardware which they don't want ordinary users to be able to see. Rather than providing their own hardware protection (write-once to disable, for instance), they rely on the CPU security model to hide it. And that's a problem for me. I don't care about their special hardware, but I care that certain CPU registers are locked down because of their design choice.
I've bought about 5 different ARM-based development boards over the past 2 years.
One big issue is ARM CPUs have a security feature called TrustZone which can run an OS with privileged code, but still restrict some hardware to only "secure" software (basically, a hypervisor above the OS). Unfortunately, for example, TI in its OMAP platforms has decided to force Linux to run non-secure always in the cheap development platforms. This is a problem for me since I want to be able to change those registers, and in some cases ARM CPUs have a variety of bugs which require setting workaround bits in CPU registers which cannot be changed by non-secure code. And of course those bits aren't set.
This problem affects the PandaBoard, Beagleboard, and a Zoom board I got from LogicPD with an OMAP chip. All use TI OMAP chips, all boot Linux in non-secure mode. I've been happy with a board I got from Freescale, the MX.51, which lets me run secure code just fine. Unfortunately, Freescale development boards are around $1000, and these TI-based boards are around $200.
So, does anyone know how Samsung is going to handle TrustZone--will Linux be able to run in secure mode?
I'm not sure if you were sarcastic or not, but your email address is at gmail, and I'm gonna mention Fight Club, and there's no I in team. Do you want me to post your email address more plainly?
So, yeah, posting email hashes is only a little bit safer than posting the full text.
I browsed the PDF, and it seems they have some trampoline code in the first 64KB of memory that has unsafe instructions that allow that code to do more dangerous things. The idea is that the untrusted code can only interface with the trampoline code, which checks that nothing funny is going on, then it interacts with the real OS.
I see a primary weakness is that they support threads. Start a thread, and have it try to interfere with another thread calling the trampoline code. Basically, mess about with the "stack" trying to get it to jump to a non-32-byte boundary. The trampoline code seems to be a very weak spot, and attacking it seems like the easiest area to go after. It's very difficult to make the trampoline code safe from attacks from other threads in the same address space (it actually may not be possible to make it bullet proof). Try to attack the trampoline to make failing security checks into passing ones--the idea is the trampoline code has to store data somewhere--just try to modify it.
I think they may have some weaknesses in mmap, mprotect, etc.--they need to check these calls very carefully. Try to remap the trampoline code to another address (which would then be vulnerable). Try to map in a library over the trampoline code. The PDF itself said they check open() carefully, but then not read()...this shows they are probably being too clever and not defensive enough.
Another area is create races--is it possible to provide one copy of the code to the checker, and another copy actually gets loaded into memory? This is surprisingly difficult to get right, but depends a great deal on how they load code (or, rather, how the code is presented to them in the first place, I guess by a browser).
Note that any check the trampoline code makes might be bypassable by a clever thread, which changes the data after the sandbox check is complete but before the OS call is made. OS calls which take in buffers probably don't "snapshot" the data to protect it being changed by threads, so there may be a large window in which threads can break the sandbox security (the security check passed, but then a thread changes the data to unsafe values before the OS acts on it).
And of course, try to break out of the sandbox by exposing OS-level bugs or just extreme events such as opening too many files, overflowing structures, to create a way out of the sandbox.
If you have time to try all of the above, enjoy your $512.
However, it is my understanding there is no settled legal basis for this extreme view. Can you cite any court cases where copying concepts from code was considered illegal even though the copy differed significantly? And where it was ruled that a clean-room technique would have been valid?
I think the closest analogy which seems pretty settled is book authorship. If I write a book about a girl, her dog, a scarecrow, and a tin man heading to Oz to meet a wizard, etc., then I have a good chance of losing a copyright infringement claim by the owners of the Wizard of Oz. Even if I didn't read the book, and if only a 3rd party told me the broad outline of the story. Unless it's funny. (Which is true--parody is an exception).
However, lots of people write books inspired by other books, even "borrowing" characters, and generally this is OK. It doesn't matter whether you read the book or not, or whether some 3rd party told you the story.
I do not think Gates has total control over the Foundation's money. In fact, I think it's his father who actually runs it. (You can't donate to something you control).
As for giving away Microsoft's products, the Foundation does not own them--it is an entity completely independent of Microsoft. It would cost the Foundation just as much to give away $1 million in Macs as it does to give away $1 million in Windows machines and Office licenses.
However, I think we can all agree the Foundation is probably not funding Macs or Linux.
I decided to respond to the troll, since it's a good way to explain how the rich can pay no taxes.
Let's assume you bought some stock for $1, and now it's worth $100million--all profit. You only pay taxes on stock appreciation when you sell it. You work for a company who pays you a $1 million salary.
In the simplest sense, if you donate $1 million in stock to your own foundation, then you will pay no personal income tax since your effective earnings for the year are $1million - $1 million = $0. (This math doesn't work for simple folk, it requires clever accounting which the rich can afford). So by transferring $1 million in stock to your foundation, you pay no taxes. Your foundation can then pay $100k for your personal secretary, and $800k for corporate jet rental, and donate $100k to some actual charitable group. You get $1 million in cash in your bank, and you only spend $100k to a charity, and pay no taxes.
If Bill Gates did not give money to his Foundation, he would need to send that money to the US Govt, and reduce everyone's taxes by probably about $1. So it's cost me at least $1.
If Bill Gates gave his money to someone else, it would be a donation. But he's giving it to himself, since he controls his own Foundation.
The Foundation has restrictions on what it can do (it's a non-profit), but so did Microsoft, and we see how well that worked out.
My look at the Bill & Melinda Gates Foundation shows it was founded with two primary purposes:
- Tax dodge--giving money to a charity reduces his personal income taxes. By giving it to a charity he controls, he gets additional benefits. - As PR for Microsoft against the anti-trust investigation.
Bill Gates has been rich since the 1980s, but his Foundation didn't really get any significant money until 1999. And then Bill then realized around 2004 that he could run his Foundation as his "retirement", and so started giving it more focus.
By checking out the contributions provided at www.gatesfoundation.org, you can see (this is complicated by the fact he had two charities, with the primary one now being the Bill & Melinda Gates Foundation): - As of 1998, Bill Gates had donated a grand total of $300million to both of his charities. That's not for that year, that's over all previous years combined, with interest/appreciation. This number is embarrassingly low for a person worth $100billion. However, it's probably just about the right amount to maximize his tax savings on a yearly basis. Also, the charity was building an endowment, and not spending all that much money. - Then suddenly, in 1999, in the middle of the Microsoft anti-trust lawsuit, he gives $15 billion. He gives another $5 billion in 2000. - Then, once the anti-trust lawsuit effectively ended, in 2001, he gives $0. Yup, check it out yourself. Probably because he took a loss that year due to the stock market drop, didn't need the tax writeoff anymore, and didn't need the PR. - In 2002, he gives $82.5million, again, back to the tax dodge. He gives $81.9 million in 2003. He's still worth $40-50 billion dollars due to Microsoft stock. - In 2004, he starts to give his charity a little more notice, and starts donating $700million in 2004, $442 million in 2005, $333million in 2006, and $1.2billion in 2007.
I wouldn't be surprised if the recipients of his money found it had lots of strings attached, but I'm not interested enough to dig up all this dirt. Although it's nice he's giving some of his money away, IMNSHO, it's just about the least he could do (except for the $20billion PR stunt). I also think the expenses for this foundation are quite high, and are probably more of a tax dodge. The foundation also spends considerably less than he has contributed, so it's building a very large endowment. It seems benign. So far.
I liken it to a king tossing silver coins to the rabble around his carriage--but doing it only when the press is around.
Here's what happens if the telco's are sued and lose billions: All companies learn there is tremendous financial downside to agreeing to illegal government programs. All companies will resist any future government intrusions, protecting the rights of their customers for fear of being sued. This all looks good to me as a customer of various monopolies.
Now, if immunity is granted, the precedent is reversed: Companies are rewarded for violating their customer's rights, and protected by a memo written by a low-ranking government employee. Future abuses could dwarf the privacy invasion of the past eavesdropping (well, what we think we know of it, which is actually very little). The US government has shown they will tend to abuse any right they've granted themselves, even if the power was originally granted for a good purpose (e.g., social security is a handout for votes now, not a safety net).
It will be a huge loss for personal liberty if immunity is granted--it sets the precedent that "he asked me to do it; I therefore am innocent" will be codified in history. Anyone who favors personal responsibility should be appalled at this bill.
Language, environment, or any buzzword from the last 20 years don't make or break a project (although they certainly can be the proverbial straw that breaks the camel's back).
The development team needs to be as small as possible. If it's more than about 10, it needs to have technical leaders who own areas with team(s) under them. A good seasoned architect (or two) should lead the project. You cannot have 3 (or more) co-leads, they will have trouble agreeing and may fracture the project. A hierarchy tends to work best, with clear ownership.
Balance leadership with team experience--plan on the leads doing mostly mentoring if the rest of the team is inexperienced.
There needs to be more effort in the schedule working on testing then on development. If developers write tests, try to have them not own testing their own code.
Integrate often, and set up processes so that it is more work for developers to do "the wrong thing" than the right thing. Examples: make it more work for developers if they check in code which doesn't compile (immediately eject their code, adopt other penalties as you see fit); reduce overhead as much as possible when developers are following the right processes; automate builds and releases.
Reward the testing team for finding bugs. Reward the development team for quickly fixing bugs. Plan on a lot of bugs. Use a bug tracker. Don't let bugs get old.
The most successful teams are usually doing something similar to what the technical leads have done before (so the problem is well understood), following known methods. Limit new major risk areas to 2, maybe 3. (E.g., switching to a new language or platform which no one has experience on would be one new major risk; going from unthreaded to a high-thread-count design would be another; using a new buzzword-compliant tool/strategy would be another; etc.). Try to have realistic fallback plans for at least one risk, or carefully watch any risk without a fallback plan.
The above pretty much are true of any successful engineering group.
Linux has several problems, almost none of them are major problems with Mac OS X or MS Windows. I think it's biggest problem is that in 4 major ways, Linux is hostile to folks writing GUI apps. And people will run the OS with the applications they need/want.
First, the problem is what is "Linux"? The different distributions are really not that compatible. Imagine if Apple produced 7 similar-yet-incompatible versions of Mac OS X, and then wondered why people weren't using it. It seems that HP-UX and Solaris have more in common than RHEL and Ubuntu. This is far and away the top problem with "Linux."
Second, it is incredibly difficult to produce a Linux binary that works on multiple distributions. Actually, I have no idea how to do it, so maybe it's even impossible. Even with source included, it's incredibly nice to get a binary so you can try using something without spending hours compiling it first. If all you ever use is vendor-supplied packages (i.e., whatever your vendors installer will install), you might not see much issue. But imagine only using Microsoft software on Windows--if that's what Linux can achieve, then that's not much to brag about.
Third, it feels like every release, each Linux distribution decides to break backwards compatibility in some way. There's a reason Microsoft supports 10+ year old programs.
Fourth, what GUI library should I use? This seems like a total mess, made even worse by the other issues.
As a developer who despises Windows, I can see that it is much easier to distribute a Windows executable that will just work for everyone than to distribute a Linux GUI application. It's easy to develop a Linux command-line application, though, since POSIX standardized that for everyone. Linux will not get supported by general developers for desktop use until this can be fixed.
Sure, it's easy to make a pipeline divide, but to pipeline 17-60 stages for an uncommon instruction is not usually done. It also would complicate pipeline control to have such a long pipeline delay.
The throughput for divide shows some CPUs having two divide units, but none have pipelining. However, they could add an abort operation to kill a pending long-latency divide as well, but I don't know if they do that either. Since Intel has been bitten very badly by a divide bug, I could see them being a bit shy adding risky optimizations in this area.
Assuming this is an honest question, when placed under oath, you are supposed to tell the truth, not just what you know the other lawyers can prove.
If someone believes otherwise, you probably already know which technology companies you'd feel right at home at.
A more funny response would be to pick up a phone and over the dialtone shout and ask the NSA for my web browsing history. I didn't just give that answer since I'm annoyed at how many people seem to think lying and cheating are OK.
I only briefly read the patent (due to triple damages for knowingly infringing a patent, it's best to not read any patents ever), and although it's not a typical troll, it has the problem of most patents--it's not that special of an idea.
I worked with the HP PA8000 processor since around 1994. It was an out-of-order CPU, meaning it would execute past cache misses or other long delays to find future instructions which it could do now to save time later. The big win for out-of-order is that it can start cache misses for future work early, acting as a prefetch to bring data into the cache.
Unfortunately, sometimes bad speculation can cause a loop of instructions to result in future instructions causing misses that won't be needed, or other bad effects like starting a divide, and blocking the divide unit for a long time for a divide that won't be used. Recovering from this bad speculation takes time and so it's a performance loss. These are second-order effects--the out-of-order is a big enough win that it almost always outweighs any drawbacks.
All current major CPU designs use out-of-order execution, so everyone's aware of these issues now. I remember at the time looking at a bus trace of some code running on the PA8000 and remarking to the CPU designers at HP that they could improve performance by trying to avoid mis-speculating over and over. At that time, it wasn't worth the silicon space to try to fix it. I'm saying this to show it's obvious speculation can cause some performance issues.
And this is the problem with patents--technology changed so that now it's worth it to spend silicon to fix this problem, to eek out another 1-2% performance. And once it's been decided to fix it, there are some obvious ideas. Like modify the branch prediction hardware to add some state to track that a branch is not being predicted well, to tone down execution after that branch. Or doing whatever it is this patent says to do.
But since academic research often doesn't concern itself with practicalities as silicon real estate, it doesn't surprise me that some university has looked into this problem before Intel. And patents are a way to show you're doing research. However, ask 10 CPU designers how to fix bad speculation, and I would be surprised if several of them didn't give an idea that would infringe on this patent. So is the patent really novel or non-obvious? (I'm aware of the legal definition of obvious, which almost always makes any patent legally non-obvious).
However, I don't necessarily have much sympathy for Intel since they use patents to bar competitors from directly interfacing with their chips. If you control a bus specification, you can add an oddball design quirk, patent it, and thereby block competitors from using your bus. I tried to find the patent for "Intel burst order", but couldn't find it in a few minutes of trying.
Intel is probably a good target to sue for patent infringement because they rely on patents and so are less likely to want to set any precedents weakening their own patents. Generally, they go for cross-licensing, which won't make much sense in this case, though.
My emulator, KEGS, gets most of the low-level disk details right. You can get it at http://kegs.sourceforge.net/. It's not that hard to do low-level disk timings. It's even easier to do straight bits from the drive, but I wrote KEGS for Pentium-class machines, so it worries about performance.
However, I would have needed to create a new disk-image format for KEGS to use (the.nib format is woefully inadequate), and I never bothered. So there's no easy way to get a low-level description of an Apple II disk into KEGS, other than.nib images, which can't encode many types of copy protection.
If I understand it correctly, this theory is that natural selection in England killed off the lower classes and replaced them with descendants of the upper class from 1200-1800AD. These descendants had new values such as hard-working and thrifty (that the lower classes didn't have), and these new values in the population reached critical mass around 1800 in England--leading to the Industrial Revolution.
I won't bother to try to dispute the details of this theory, but it doesn't seem to explain the prosperity of other nations. Other countries other than England became prosperous "first-world" nations--and not all were populated by English descendants. So the theory appears to have a big stumbling block showing causation, when it seems clear upper-class English descendants could not be responsible for prosperity in other countries.
I like the general theory described in the book Birth of Plenty that it's the following institutions that lead to prosperity: property rights, efficient transportation, fast communication, and one or two others I've forgotten. A society with the right institutions will become wealthy. What I like about this theory is that it helps explain why some modern countries are more prosperous than others--USA/Japan/Europe all are similar in the necessary institutions, while "backwards" societies lack them. And it's usually property rights that modern third-world countries lack since transportation and communications are mostly solved technological issues.
Property rights includes the following: buying and selling of land is "easy" and not unduly restricted; your land and wealth are generally protected from others by the state and its courts; the state is not confiscating your land. In short, basic capitalistic principles (but not necessarily capitalism) where you keep most of what you earn, so that you have incentive to earn more.
My opinion is: the Industrial Revolution of England (and other countries, such as the USA) were primed by advances made during the 1700s--technological advances were required to break out of the Malthusian trap, and some place had to be first. A number of secondary factors led to England being first and becoming so prosperous in the 1800's. I think the existence of colonies as new places for investment and new resources (which are not really considered significant in "Birth of Plenty"), a common law legal system, a general peace (in England itself--foreign wars aren't as big an economic issue--sometimes they can be profitable even), and the encouragement of efficient capital markets are key factors in why England became prosperous first.
However, modern prosperity seems to come down to institutions. To avoid wealth as a nation seems to require active effort to suppress people's natural initiative. Unfortunately, this seems to be fairly easy to do, even unintentionally. As a small example, I'm reminded of a recent article by an African academic begging the West to stop giving them free stuff--it's destroying their economies. And then there are the obvious train wreck economies where the government confiscates foreigner-owned land, etc.
I don't believe the parent post is really correct about any recent Intel/AMD processor.
I think the 25+ year old 8086 was fully microcoded, but recent processors have only limited microcode. Most instructions are natively executed--no microcode is involved. Granted, Intel converts "macro-instructions" into "uops" but this isn't really microcode--it's all hardwired to be fast. There is no "microcode table" that converts macro-ops to micro-ops.
However, the x86 has so many complex instructions, that those are microcoded. For example, I would expect FSIN and FCOS and all the transcendental functions to be microcoded. It's also likely things like loading segment registers, taking interrupts, and TLB handling are all microcoded.
After the FDIV bug, Intel realized that microcode could be a good way to patch bugs. So they came up with downloaded microcode. They added a hardware detected signature, so effectively only Intel can generate microcode patches. So it's safe for any OS to load it since the hardware checks the signature. But in general, the BIOS loads microcode patches so that the OS'es don't need to.
I have no information on this, but I suspect the downloaded "microcode" can change chip features other than just the actual microcode. Now that chips have 100+ million transistors, it would seem to be wise to spend a few redundantly to allow clever patches to "hardwired" logic.
The article is a very good troll--thus the score 9 out of a possible 10. It's long, presents lots of facts (some correct, some flawed) and lots of unjustified opinions. Nearly every opinion and many of the facts can easily be argued with. So everyone can argue over almost every point. I'd consider giving it 10/10, but I save that score for trolls who actually intend to troll, and I'm not convinced the author is that clever.
I especially enjoyed how one of his biggest gripes, a lack of a free MS Office clone on the Mac, hinges completely on the fact that he discounts NeoOffice due to not being able to italicize Helvetica text. I've used NeoOffice for many purposes, and I use it instead of Pages due to an annoying Pages bug with section numbering (2.1, 2.2, 3.1, 3.2 would become 2.1, 2.2, 3.3, 3.4 when you loaded the file, but would correct itself if you made edits in section 3). I'd never run across the italics problem with Helvetica and Courier he ran into because I don't italicize much, and notice he didn't in his article either. Apparently if you avoid those 2 fonts you won't have a problem with italics in NeoOffice. The Mac has many other Courier and Helvetica fonts which you can use--just the ones with the exact names Helvetica and Courier appear affected. I had to use the comments here to even figure out which fonts are susceptible since my first attempts worked fine.
I find fark's complete lack of even a mention of this issue on its front page quite telling. Fark's strong editorial policy is quite visible on this issue, and it feels like fark is no longer much "fun". And I saw that a fark thread today with a lot of pics that had all pictures removed by a moderator for fear that some might be NSFW. It's not fark, it's nanny.com. But, I've learned a new catch phrase: "You'll get over it."
The listed site links to it itself--http://www.sump.org/projects/analyzer/ is where it is getting the logic analyzer hardware design from. It's not clear to me what flash-plaice.wikispaces.com is adding, other than porting the design to the Spartan-3E proto board (from a Spartan-3 proto board).
A commercial LA system has carefully designed probes to reduce the load on the signals being probed. I made a home-made PCI data capture "card" by soldering stubs to a blank PCI connector, and connecting directly to an HP analyzer I bought on ebay. I needed the probes to not be a large load on the PCI bus, and using the HP probes solved that problem for me.
If you want cheap logic analyzers, you can get a very nice HP analyzer on ebay for about $500--and have it capture at least 96 bits wide at 100MHz, and have a usable interface. You can upgrade to capturing a million states at 135MHz for a few hundred more. And you can add in a correlated scope for another few hundred bucks. Although this is a bit beyond what folks would want to pay, it's pretty reasonable for hardware that used to cost $10,000+ and is less than a new decked out PC.
Thank you for pointing out Centos.org, but you may have missed the part where I said "I'm not a Linux expert." I just read the CentOS.org website, and let's just say sites pirating movies and music are less cryptic in their intentions. If I hadn't bought RHEL and now recognize the numbering scheme of the versions, I would have had no idea that was RHEL 4 available. A quick google search found an article that said centos.org was asked by Redhat to remove all references to Redhat on the website, which explains the oddness of the site.
As for me trying Fedora: Umm, why shouldn't that work? I had read that RHEL 4 was based on Fedora Core 3, which is why I picked that version. It sure sounded reasonable to me.
Redhat addreses a problem many Linux distributions have: guaranteed compatibility. I needed Linux to run the FPGA design tools from Xilinx. Xilinx makes their software tools available for Windows, Solaris, and Redhat Enterprise Linux WS 3 and 4. And I learned the hard way why they only support RHEL--every Linux is so different that I had a hard time getting the Xilinx tools to work on Fedora Core 3 even (the Fedora that's most similar to RHEL 4) and gave up and bought RHEL 4. I'm a long-time Unix user, so I know what I'm doing, but I'm not a Linux expert. For those interested, Xilinx tools need to install a binary kernel driver, and it seems every Fedora release changes some subtlety in how that should work, and I pulled the plug on my attempts after a day of trying (although about half that time was fighting partitioning problems--I eventually made a Knoppix Live CD and fixed everything with parted).
But RHEL WS is $180. Per year. This their "desktop" version--the server is $350-$1500. So if I want to get security updates for 3 years, my cost for one machine is $540. I know I'm getting more than security updates, but I don't really want more. Compare this to Windows XP Pro, which costs $120 (OEM), and provides free updates for many years. Or Mac OS X--about $120 (or "free" with a new machine) which provides free updates for many years. I think Redhat needs to cut their prices in half at least, and realize they're missing sub-enterprise customers: small businesses that want to run a stable Linux, but don't need a lot of support, just serve us the bits.
Now that I've made RHEL 4 work, and can see how the kernel driver install is supposed to work, I bet I could make Fedora work. It would seem to be in Redhat's interests to provide a desktop pricing point between $540 and $0.
The Trustzone CPU hardware is documented in the ARM Architecture Reference Manual v7-a (yes, the ARM ARM). This manual is free, but requires registration at the ARM website, and you may have to explain why you need it (I did when I downloaded it 2 years ago, and it's not easy to tell if that's still the case or not). It is not under NDA, but you have to agree to some terms, such as I can't make a CPU and say it is an ARM CPU. As far as I know, all ARM instruction set references are under this type of registration protection now (although that wasn't always the case).
The CPU resets to secure mode. It's then up to the boot firmware to decide whether to go through the effort to set up the non-secure domain, or just stay secure when the OS is loaded. In general, the OS doesn't care. But some CPU registers are locked down and cannot be changed from non-secure mode. It's generally easier to stay secure since less has to be initialized, and you don't need hypervisor code, even if it's a trivial implementation.
What I suspect TI is doing is they have some "interesting" hardware which they don't want ordinary users to be able to see. Rather than providing their own hardware protection (write-once to disable, for instance), they rely on the CPU security model to hide it. And that's a problem for me. I don't care about their special hardware, but I care that certain CPU registers are locked down because of their design choice.
I've bought about 5 different ARM-based development boards over the past 2 years.
One big issue is ARM CPUs have a security feature called TrustZone which can run an OS with privileged code, but still restrict some hardware to only "secure" software (basically, a hypervisor above the OS). Unfortunately, for example, TI in its OMAP platforms has decided to force Linux to run non-secure always in the cheap development platforms. This is a problem for me since I want to be able to change those registers, and in some cases ARM CPUs have a variety of bugs which require setting workaround bits in CPU registers which cannot be changed by non-secure code. And of course those bits aren't set.
This problem affects the PandaBoard, Beagleboard, and a Zoom board I got from LogicPD with an OMAP chip. All use TI OMAP chips, all boot Linux in non-secure mode. I've been happy with a board I got from Freescale, the MX.51, which lets me run secure code just fine. Unfortunately, Freescale development boards are around $1000, and these TI-based boards are around $200.
So, does anyone know how Samsung is going to handle TrustZone--will Linux be able to run in secure mode?
I'm not sure if you were sarcastic or not, but your email address is at gmail, and I'm gonna mention Fight Club, and there's no I in team. Do you want me to post your email address more plainly?
So, yeah, posting email hashes is only a little bit safer than posting the full text.
I browsed the PDF, and it seems they have some trampoline code in the first 64KB of memory that has unsafe instructions that allow that code to do more dangerous things. The idea is that the untrusted code can only interface with the trampoline code, which checks that nothing funny is going on, then it interacts with the real OS.
I see a primary weakness is that they support threads. Start a thread, and have it try to interfere with another thread calling the trampoline code. Basically, mess about with the "stack" trying to get it to jump to a non-32-byte boundary. The trampoline code seems to be a very weak spot, and attacking it seems like the easiest area to go after. It's very difficult to make the trampoline code safe from attacks from other threads in the same address space (it actually may not be possible to make it bullet proof). Try to attack the trampoline to make failing security checks into passing ones--the idea is the trampoline code has to store data somewhere--just try to modify it.
I think they may have some weaknesses in mmap, mprotect, etc.--they need to check these calls very carefully. Try to remap the trampoline code to another address (which would then be vulnerable). Try to map in a library over the trampoline code. The PDF itself said they check open() carefully, but then not read()...this shows they are probably being too clever and not defensive enough.
Another area is create races--is it possible to provide one copy of the code to the checker, and another copy actually gets loaded into memory? This is surprisingly difficult to get right, but depends a great deal on how they load code (or, rather, how the code is presented to them in the first place, I guess by a browser).
Note that any check the trampoline code makes might be bypassable by a clever thread, which changes the data after the sandbox check is complete but before the OS call is made. OS calls which take in buffers probably don't "snapshot" the data to protect it being changed by threads, so there may be a large window in which threads can break the sandbox security (the security check passed, but then a thread changes the data to unsafe values before the OS acts on it).
And of course, try to break out of the sandbox by exposing OS-level bugs or just extreme events such as opening too many files, overflowing structures, to create a way out of the sandbox.
If you have time to try all of the above, enjoy your $512.
This is called "clean room" engineering.
However, it is my understanding there is no settled legal basis for this extreme view. Can you cite any court cases where copying concepts from code was considered illegal even though the copy differed significantly? And where it was ruled that a clean-room technique would have been valid?
I think the closest analogy which seems pretty settled is book authorship. If I write a book about a girl, her dog, a scarecrow, and a tin man heading to Oz to meet a wizard, etc., then I have a good chance of losing a copyright infringement claim by the owners of the Wizard of Oz. Even if I didn't read the book, and if only a 3rd party told me the broad outline of the story. Unless it's funny. (Which is true--parody is an exception).
However, lots of people write books inspired by other books, even "borrowing" characters, and generally this is OK. It doesn't matter whether you read the book or not, or whether some 3rd party told you the story.
I do not think Gates has total control over the Foundation's money. In fact, I think it's his father who actually runs it. (You can't donate to something you control).
As for giving away Microsoft's products, the Foundation does not own them--it is an entity completely independent of Microsoft. It would cost the Foundation just as much to give away $1 million in Macs as it does to give away $1 million in Windows machines and Office licenses.
However, I think we can all agree the Foundation is probably not funding Macs or Linux.
I decided to respond to the troll, since it's a good way to explain how the rich can pay no taxes.
Let's assume you bought some stock for $1, and now it's worth $100million--all profit. You only pay taxes on stock appreciation when you sell it. You work for a company who pays you a $1 million salary.
In the simplest sense, if you donate $1 million in stock to your own foundation, then you will pay no personal income tax since your effective earnings for the year are $1million - $1 million = $0. (This math doesn't work for simple folk, it requires clever accounting which the rich can afford). So by transferring $1 million in stock to your foundation, you pay no taxes. Your foundation can then pay $100k for your personal secretary, and $800k for corporate jet rental, and donate $100k to some actual charitable group. You get $1 million in cash in your bank, and you only spend $100k to a charity, and pay no taxes.
If Bill Gates did not give money to his Foundation, he would need to send that money to the US Govt, and reduce everyone's taxes by probably about $1. So it's cost me at least $1.
If Bill Gates gave his money to someone else, it would be a donation. But he's giving it to himself, since he controls his own Foundation.
The Foundation has restrictions on what it can do (it's a non-profit), but so did Microsoft, and we see how well that worked out.
My look at the Bill & Melinda Gates Foundation shows it was founded with two primary purposes:
- Tax dodge--giving money to a charity reduces his personal income taxes. By giving it to a charity he controls, he gets additional benefits.
- As PR for Microsoft against the anti-trust investigation.
Bill Gates has been rich since the 1980s, but his Foundation didn't really get any significant money until 1999. And then Bill then realized around 2004 that he could run his Foundation as his "retirement", and so started giving it more focus.
By checking out the contributions provided at www.gatesfoundation.org, you can see (this is complicated by the fact he had two charities, with the primary one now being the Bill & Melinda Gates Foundation):
- As of 1998, Bill Gates had donated a grand total of $300million to both of his charities. That's not for that year, that's over all previous years combined, with interest/appreciation. This number is embarrassingly low for a person worth $100billion. However, it's probably just about the right amount to maximize his tax savings on a yearly basis. Also, the charity was building an endowment, and not spending all that much money.
- Then suddenly, in 1999, in the middle of the Microsoft anti-trust lawsuit, he gives $15 billion. He gives another $5 billion in 2000.
- Then, once the anti-trust lawsuit effectively ended, in 2001, he gives $0. Yup, check it out yourself. Probably because he took a loss that year due to the stock market drop, didn't need the tax writeoff anymore, and didn't need the PR.
- In 2002, he gives $82.5million, again, back to the tax dodge. He gives $81.9 million in 2003. He's still worth $40-50 billion dollars due to Microsoft stock.
- In 2004, he starts to give his charity a little more notice, and starts donating $700million in 2004, $442 million in 2005, $333million in 2006, and $1.2billion in 2007.
I wouldn't be surprised if the recipients of his money found it had lots of strings attached, but I'm not interested enough to dig up all this dirt. Although it's nice he's giving some of his money away, IMNSHO, it's just about the least he could do (except for the $20billion PR stunt). I also think the expenses for this foundation are quite high, and are probably more of a tax dodge. The foundation also spends considerably less than he has contributed, so it's building a very large endowment. It seems benign. So far.
I liken it to a king tossing silver coins to the rabble around his carriage--but doing it only when the press is around.
Here's what happens if the telco's are sued and lose billions: All companies learn there is tremendous financial downside to agreeing to illegal government programs. All companies will resist any future government intrusions, protecting the rights of their customers for fear of being sued. This all looks good to me as a customer of various monopolies.
Now, if immunity is granted, the precedent is reversed: Companies are rewarded for violating their customer's rights, and protected by a memo written by a low-ranking government employee. Future abuses could dwarf the privacy invasion of the past eavesdropping (well, what we think we know of it, which is actually very little). The US government has shown they will tend to abuse any right they've granted themselves, even if the power was originally granted for a good purpose (e.g., social security is a handout for votes now, not a safety net).
It will be a huge loss for personal liberty if immunity is granted--it sets the precedent that "he asked me to do it; I therefore am innocent" will be codified in history. Anyone who favors personal responsibility should be appalled at this bill.
Language, environment, or any buzzword from the last 20 years don't make or break a project (although they certainly can be the proverbial straw that breaks the camel's back).
The development team needs to be as small as possible. If it's more than about 10, it needs to have technical leaders who own areas with team(s) under them. A good seasoned architect (or two) should lead the project. You cannot have 3 (or more) co-leads, they will have trouble agreeing and may fracture the project. A hierarchy tends to work best, with clear ownership.
Balance leadership with team experience--plan on the leads doing mostly mentoring if the rest of the team is inexperienced.
There needs to be more effort in the schedule working on testing then on development. If developers write tests, try to have them not own testing their own code.
Integrate often, and set up processes so that it is more work for developers to do "the wrong thing" than the right thing. Examples: make it more work for developers if they check in code which doesn't compile (immediately eject their code, adopt other penalties as you see fit); reduce overhead as much as possible when developers are following the right processes; automate builds and releases.
Reward the testing team for finding bugs. Reward the development team for quickly fixing bugs. Plan on a lot of bugs. Use a bug tracker. Don't let bugs get old.
The most successful teams are usually doing something similar to what the technical leads have done before (so the problem is well understood), following known methods. Limit new major risk areas to 2, maybe 3. (E.g., switching to a new language or platform which no one has experience on would be one new major risk; going from unthreaded to a high-thread-count design would be another; using a new buzzword-compliant tool/strategy would be another; etc.). Try to have realistic fallback plans for at least one risk, or carefully watch any risk without a fallback plan.
The above pretty much are true of any successful engineering group.
Linux has several problems, almost none of them are major problems with Mac OS X or MS Windows. I think it's biggest problem is that in 4 major ways, Linux is hostile to folks writing GUI apps. And people will run the OS with the applications they need/want.
First, the problem is what is "Linux"? The different distributions are really not that compatible. Imagine if Apple produced 7 similar-yet-incompatible versions of Mac OS X, and then wondered why people weren't using it. It seems that HP-UX and Solaris have more in common than RHEL and Ubuntu. This is far and away the top problem with "Linux."
Second, it is incredibly difficult to produce a Linux binary that works on multiple distributions. Actually, I have no idea how to do it, so maybe it's even impossible. Even with source included, it's incredibly nice to get a binary so you can try using something without spending hours compiling it first. If all you ever use is vendor-supplied packages (i.e., whatever your vendors installer will install), you might not see much issue. But imagine only using Microsoft software on Windows--if that's what Linux can achieve, then that's not much to brag about.
Third, it feels like every release, each Linux distribution decides to break backwards compatibility in some way. There's a reason Microsoft supports 10+ year old programs.
Fourth, what GUI library should I use? This seems like a total mess, made even worse by the other issues.
As a developer who despises Windows, I can see that it is much easier to distribute a Windows executable that will just work for everyone than to distribute a Linux GUI application. It's easy to develop a Linux command-line application, though, since POSIX standardized that for everyone. Linux will not get supported by general developers for desktop use until this can be fixed.
Sure, it's easy to make a pipeline divide, but to pipeline 17-60 stages for an uncommon instruction is not usually done. It also would complicate pipeline control to have such a long pipeline delay.
Intel hasn't pipelined its divide, as can be seen in the instruction throughput numbers in Appendix C of this manual: http://www.intel.com/design/processor/manuals/248966.pdf
The throughput for divide shows some CPUs having two divide units, but none have pipelining. However, they could add an abort operation to kill a pending long-latency divide as well, but I don't know if they do that either. Since Intel has been bitten very badly by a divide bug, I could see them being a bit shy adding risky optimizations in this area.
Assuming this is an honest question, when placed under oath, you are supposed to tell the truth, not just what you know the other lawyers can prove.
If someone believes otherwise, you probably already know which technology companies you'd feel right at home at.
A more funny response would be to pick up a phone and over the dialtone shout and ask the NSA for my web browsing history. I didn't just give that answer since I'm annoyed at how many people seem to think lying and cheating are OK.
I only briefly read the patent (due to triple damages for knowingly infringing a patent, it's best to not read any patents ever), and although it's not a typical troll, it has the problem of most patents--it's not that special of an idea.
I worked with the HP PA8000 processor since around 1994. It was an out-of-order CPU, meaning it would execute past cache misses or other long delays to find future instructions which it could do now to save time later. The big win for out-of-order is that it can start cache misses for future work early, acting as a prefetch to bring data into the cache.
Unfortunately, sometimes bad speculation can cause a loop of instructions to result in future instructions causing misses that won't be needed, or other bad effects like starting a divide, and blocking the divide unit for a long time for a divide that won't be used. Recovering from this bad speculation takes time and so it's a performance loss. These are second-order effects--the out-of-order is a big enough win that it almost always outweighs any drawbacks.
All current major CPU designs use out-of-order execution, so everyone's aware of these issues now. I remember at the time looking at a bus trace of some code running on the PA8000 and remarking to the CPU designers at HP that they could improve performance by trying to avoid mis-speculating over and over. At that time, it wasn't worth the silicon space to try to fix it. I'm saying this to show it's obvious speculation can cause some performance issues.
And this is the problem with patents--technology changed so that now it's worth it to spend silicon to fix this problem, to eek out another 1-2% performance. And once it's been decided to fix it, there are some obvious ideas. Like modify the branch prediction hardware to add some state to track that a branch is not being predicted well, to tone down execution after that branch. Or doing whatever it is this patent says to do.
But since academic research often doesn't concern itself with practicalities as silicon real estate, it doesn't surprise me that some university has looked into this problem before Intel. And patents are a way to show you're doing research. However, ask 10 CPU designers how to fix bad speculation, and I would be surprised if several of them didn't give an idea that would infringe on this patent. So is the patent really novel or non-obvious? (I'm aware of the legal definition of obvious, which almost always makes any patent legally non-obvious).
However, I don't necessarily have much sympathy for Intel since they use patents to bar competitors from directly interfacing with their chips. If you control a bus specification, you can add an oddball design quirk, patent it, and thereby block competitors from using your bus. I tried to find the patent for "Intel burst order", but couldn't find it in a few minutes of trying.
Intel is probably a good target to sue for patent infringement because they rely on patents and so are less likely to want to set any precedents weakening their own patents. Generally, they go for cross-licensing, which won't make much sense in this case, though.
My emulator, KEGS, gets most of the low-level disk details right. You can get it at http://kegs.sourceforge.net/. It's not that hard to do low-level disk timings. It's even easier to do straight bits from the drive, but I wrote KEGS for Pentium-class machines, so it worries about performance.
.nib format is woefully inadequate), and I never bothered. So there's no easy way to get a low-level description of an Apple II disk into KEGS, other than .nib images, which can't encode many types of copy protection.
However, I would have needed to create a new disk-image format for KEGS to use (the
If I understand it correctly, this theory is that natural selection in England killed off the lower classes and replaced them with descendants of the upper class from 1200-1800AD. These descendants had new values such as hard-working and thrifty (that the lower classes didn't have), and these new values in the population reached critical mass around 1800 in England--leading to the Industrial Revolution.
I won't bother to try to dispute the details of this theory, but it doesn't seem to explain the prosperity of other nations. Other countries other than England became prosperous "first-world" nations--and not all were populated by English descendants. So the theory appears to have a big stumbling block showing causation, when it seems clear upper-class English descendants could not be responsible for prosperity in other countries.
I like the general theory described in the book Birth of Plenty that it's the following institutions that lead to prosperity: property rights, efficient transportation, fast communication, and one or two others I've forgotten. A society with the right institutions will become wealthy. What I like about this theory is that it helps explain why some modern countries are more prosperous than others--USA/Japan/Europe all are similar in the necessary institutions, while "backwards" societies lack them. And it's usually property rights that modern third-world countries lack since transportation and communications are mostly solved technological issues.
Property rights includes the following: buying and selling of land is "easy" and not unduly restricted; your land and wealth are generally protected from others by the state and its courts; the state is not confiscating your land. In short, basic capitalistic principles (but not necessarily capitalism) where you keep most of what you earn, so that you have incentive to earn more.
My opinion is: the Industrial Revolution of England (and other countries, such as the USA) were primed by advances made during the 1700s--technological advances were required to break out of the Malthusian trap, and some place had to be first. A number of secondary factors led to England being first and becoming so prosperous in the 1800's. I think the existence of colonies as new places for investment and new resources (which are not really considered significant in "Birth of Plenty"), a common law legal system, a general peace (in England itself--foreign wars aren't as big an economic issue--sometimes they can be profitable even), and the encouragement of efficient capital markets are key factors in why England became prosperous first.
However, modern prosperity seems to come down to institutions. To avoid wealth as a nation seems to require active effort to suppress people's natural initiative. Unfortunately, this seems to be fairly easy to do, even unintentionally. As a small example, I'm reminded of a recent article by an African academic begging the West to stop giving them free stuff--it's destroying their economies. And then there are the obvious train wreck economies where the government confiscates foreigner-owned land, etc.
I don't believe the parent post is really correct about any recent Intel/AMD processor.
I think the 25+ year old 8086 was fully microcoded, but recent processors have only limited microcode. Most instructions are natively executed--no microcode is involved. Granted, Intel converts "macro-instructions" into "uops" but this isn't really microcode--it's all hardwired to be fast. There is no "microcode table" that converts macro-ops to micro-ops.
However, the x86 has so many complex instructions, that those are microcoded. For example, I would expect FSIN and FCOS and all the transcendental functions to be microcoded. It's also likely things like loading segment registers, taking interrupts, and TLB handling are all microcoded.
After the FDIV bug, Intel realized that microcode could be a good way to patch bugs. So they came up with downloaded microcode. They added a hardware detected signature, so effectively only Intel can generate microcode patches. So it's safe for any OS to load it since the hardware checks the signature. But in general, the BIOS loads microcode patches so that the OS'es don't need to.
I have no information on this, but I suspect the downloaded "microcode" can change chip features other than just the actual microcode. Now that chips have 100+ million transistors, it would seem to be wise to spend a few redundantly to allow clever patches to "hardwired" logic.
My emulator, KEGS, does a reasonable job at double-hires as well, and it doesn't look all blurry:
http://kegs.sourceforge.net/screenshots.html
The article is a very good troll--thus the score 9 out of a possible 10. It's long, presents lots of facts (some correct, some flawed) and lots of unjustified opinions. Nearly every opinion and many of the facts can easily be argued with. So everyone can argue over almost every point. I'd consider giving it 10/10, but I save that score for trolls who actually intend to troll, and I'm not convinced the author is that clever.
I especially enjoyed how one of his biggest gripes, a lack of a free MS Office clone on the Mac, hinges completely on the fact that he discounts NeoOffice due to not being able to italicize Helvetica text. I've used NeoOffice for many purposes, and I use it instead of Pages due to an annoying Pages bug with section numbering (2.1, 2.2, 3.1, 3.2 would become 2.1, 2.2, 3.3, 3.4 when you loaded the file, but would correct itself if you made edits in section 3). I'd never run across the italics problem with Helvetica and Courier he ran into because I don't italicize much, and notice he didn't in his article either. Apparently if you avoid those 2 fonts you won't have a problem with italics in NeoOffice. The Mac has many other Courier and Helvetica fonts which you can use--just the ones with the exact names Helvetica and Courier appear affected. I had to use the comments here to even figure out which fonts are susceptible since my first attempts worked fine.
I find fark's complete lack of even a mention of this issue on its front page quite telling. Fark's strong editorial policy is quite visible on this issue, and it feels like fark is no longer much "fun". And I saw that a fark thread today with a lot of pics that had all pictures removed by a moderator for fear that some might be NSFW. It's not fark, it's nanny.com. But, I've learned a new catch phrase: "You'll get over it."
The listed site links to it itself--http://www.sump.org/projects/analyzer/ is where it is getting the logic analyzer hardware design from. It's not clear to me what flash-plaice.wikispaces.com is adding, other than porting the design to the Spartan-3E proto board (from a Spartan-3 proto board).
A commercial LA system has carefully designed probes to reduce the load on the signals being probed. I made a home-made PCI data capture "card" by soldering stubs to a blank PCI connector, and connecting directly to an HP analyzer I bought on ebay. I needed the probes to not be a large load on the PCI bus, and using the HP probes solved that problem for me.
If you want cheap logic analyzers, you can get a very nice HP analyzer on ebay for about $500--and have it capture at least 96 bits wide at 100MHz, and have a usable interface. You can upgrade to capturing a million states at 135MHz for a few hundred more. And you can add in a correlated scope for another few hundred bucks. Although this is a bit beyond what folks would want to pay, it's pretty reasonable for hardware that used to cost $10,000+ and is less than a new decked out PC.
Thank you for pointing out Centos.org, but you may have missed the part where I said "I'm not a Linux expert." I just read the CentOS.org website, and let's just say sites pirating movies and music are less cryptic in their intentions. If I hadn't bought RHEL and now recognize the numbering scheme of the versions, I would have had no idea that was RHEL 4 available. A quick google search found an article that said centos.org was asked by Redhat to remove all references to Redhat on the website, which explains the oddness of the site.
As for me trying Fedora: Umm, why shouldn't that work? I had read that RHEL 4 was based on Fedora Core 3, which is why I picked that version. It sure sounded reasonable to me.
Redhat addreses a problem many Linux distributions have: guaranteed compatibility. I needed Linux to run the FPGA design tools from Xilinx. Xilinx makes their software tools available for Windows, Solaris, and Redhat Enterprise Linux WS 3 and 4. And I learned the hard way why they only support RHEL--every Linux is so different that I had a hard time getting the Xilinx tools to work on Fedora Core 3 even (the Fedora that's most similar to RHEL 4) and gave up and bought RHEL 4. I'm a long-time Unix user, so I know what I'm doing, but I'm not a Linux expert. For those interested, Xilinx tools need to install a binary kernel driver, and it seems every Fedora release changes some subtlety in how that should work, and I pulled the plug on my attempts after a day of trying (although about half that time was fighting partitioning problems--I eventually made a Knoppix Live CD and fixed everything with parted).
But RHEL WS is $180. Per year. This their "desktop" version--the server is $350-$1500. So if I want to get security updates for 3 years, my cost for one machine is $540. I know I'm getting more than security updates, but I don't really want more. Compare this to Windows XP Pro, which costs $120 (OEM), and provides free updates for many years. Or Mac OS X--about $120 (or "free" with a new machine) which provides free updates for many years. I think Redhat needs to cut their prices in half at least, and realize they're missing sub-enterprise customers: small businesses that want to run a stable Linux, but don't need a lot of support, just serve us the bits.
Now that I've made RHEL 4 work, and can see how the kernel driver install is supposed to work, I bet I could make Fedora work. It would seem to be in Redhat's interests to provide a desktop pricing point between $540 and $0.
Edit your /etc/hosts (works on Mac or Linux), add:
127.0.0.1 ad.doubleclick.net
and 90% of all annoying ads disappear! If you run across another site feeding annoying ads, just add a line redirecting it to 127.0.0.1.
I usually don't mind ads (I just ignore them), but when they started the large-pop-up-when-you-mouseover stuff, then they get perma-banned.