I have about 30. You've made a good start.

First, Felix Salmon says USA Today's numbers are wrong, and student loans are around $600 billion: http://blogs.reuters.com/felix-salmon/2011/10/19/fact-and-fiction-about-student-loans/. But it still is a big number.

Here's the current system: if someone with a pulse wants to go to a for-profit school, he will get in. He will pay high tuition, almost all covered by student loans. He gets a worthless degree and cannot get a job. But federal student loans cannot be discharged in bankruptcy, so his life is now ruined.

There's some blame to go to the student, he should have known better. But chances are this is a young kid, and his first exposure to the adult world is a recruiter telling him he's smart, he's going places, he just needs to graduate college, preferably this really expensive for-profit school. He's been preyed upon as well. And this used to be considered fraud, preying on vulnerable people. If a guy went around to old ladies selling them useless junk, we used to toss him in jail. I'm not sure why our attitudes have changed.

I think federal student loans need a major overhaul--right now, it's a huge giveaway to the banks and for-profit schools with students as victims. Limit federal loans to for-profit institutions to 50% of non-profit tuition (it can go higher based on merit), and force for-profit schools to be accredited every year. Just somehow change the incentive system to reduce the number of non-qualified kids funneled into expensive and useless programs. Change the law so that student loan defaults impact the school they went to: say, reduce loans in the future, with no more student loans to that school if the default rate tops 15% (or whatever number makes sense).

This is another bubble, and the popping of it will be another huge blow to the economy.

Also, kids need to told loudly: getting a degree from a school not competitive in the field is not worth anything more than going to your closest state school. Expensive schools that aren't competitive to get in are just a place for rich kids to go get drunk. Don't take out loans to go to those schools!

Unix began the commoditization of minicomputers. With Unix, you could run your application on many vendors' systems, choosing which one you bought this year based on price and performance, not because you were locked in to the vendor you bought last time. This opened up computing to be much more competitive, and was a great benefit to all users. This change affected technical computing very quickly, but took a while longer for business computing.

C is a very clever language, and Unix even more so. Both assume the least-common denominator in hardware, which was a very smart decision. I still remember the awe I had of Unix when I first logged in on a teletype in 1980 to play Adventure and Hunt the Wumpus. Very little else from this era has endured as well as C and Unix.

Thank you, Dennis.

Code size doesn't really apply--this is a discussion about Linux. If you're running Linux, you're not counting KBs. Maybe you're counting MBs. You may only be counting GBs (the smallest iPhone was 8GB). And ARM does provide a timer, interrupt controller, and memory controller. Not all customers use them, and only the interrupt controller has a generic "architecture" which could be said to apply to any interrupt controller. It's ironic, though, since I think everyone uses the ARM interrupt controller in any case.

It's basically ARM's fault. ARM has a predilection for leaving specs more vague than they should, and then making minor improvements that aren't backwards compatible at the OS level with each new CPU generation. User-level code tends to be backwards-compatible at least. As an example, they changed the page table format between ARMv6 (ARM11xx series) and ARMv7 (Cortex series). ARM's move to multiprocessors is new and its not clear the current OS-level view will change in the future. ARM also only documents the CPU and the IP they provide (interconnect, a memory controller, an L2 cache controller, and an interrupt controller). There is no larger system architecture, like x86 has, not even a de facto one. The x86 architecture is basically PCI based--generally, all devices appear in PCI space, with a BIOS interface for OS'es to use to discover memory layouts. The x86 world was crazy before Pentium and PCI came along, and then very stable since then.

Part of it is Linux's fault. If Linus had a distaste for #ifdefs, and instead required patches use if()/else, then vendors would be forced to adopt a more common architecture. As it is now, the vendors push their incompatibilities into huge patches in Linux, at no real code size or speed cost when run, but complicating Linux with very complex #ifdef mazes. Basically, Linux pays the cost of everyone doing something different.

So, if your CPU vendor requires pretty deep OS changes for each CPU, there's no incentive for licensees to create a system architecture so that the old OS runs on new hardware. If ARM were to accept running old OSes on new hardware as a requirement, they would have to create a system architecture. Just having a standardized memory layout would be a nice start. Having hardware be more self-descriptive could be done very simply and cheaply. PCI is probably not the best choice, but having hardware have the equivalent of Vendor/Device ID that was globally unique, and a way to find peripherals would be a start. It's just that ARM doesn't care, and probably won't care until its customers demand it to care.

Thanks, it was fun diversion. I don't mind the NOM NOM sounds, but perhaps they could be at a softer volume compared to the other sounds.

As for difficulty, it feels a little like the ghosts are ignoring me much of the time. I think your post was trying to say the ghosts have line-of-sight? So they don't head for me until they see me?

I like the idea of the walls which you can only go through in one direction, but the ghosts can go through in either direction.

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.