costan

Thank you very much for this feedback!

Re: 1 - I re-read the relevant SDM sections, and saw that there is no requirement that the new upgrade version exceeds the current microcode version. Thank you very much for pointing that out! The next published revision will have the fix.

Do you have any public references for 3 and 4? That looks like it'd help make the case that SGX rests on very complex and unstable foundations.

SGX serves a good purpose, at least in theory. Many people, myself included, wanted it to turn out to be good. So, I don't think many Intel folks objected to it.

Instead, I think that a bunch of MBAs showed up and decided SGX is security, security is an enterprise thing, so SGX must be pay-to-play. For whatever it's worth, I think the SGX designers did a pretty good job of separating the objectionable parts from the rest of the design.

For example, the EPID homebrew crypto is all in software, so Intel can change the algorithm without hardware mods or microcode updates.

Also, the way they set up the Launch Enclave gives Intel time until the very last minute to not be a douche. They still have the option to release a permissive Launch Enclave that only includes the checks needed to keep attestation secure.

The SGX design that doesn't come from MBAs is quite clean, given that it addresses the multi-layered crap pile that is X86. There are some cool tricks in there.

But enclaves are worthless without attestation.

If the OS is evil and you don't do attestation, it can emulate SGX and run your code in a simulated enclave environment where EGETKEY returns keys that the OS knows about.

If the OS is not evil, you can use process isolation to generate and protect the keys.

Do you happen to know if the Launch Enclave has the debug flag set? If so, you can't use it to launch production enclaves.

There's some support in Intel's Management Engine for DRM, called Intel Insider (the successor of PAVP). One of the SGX papers mentions plans for hooking up SGX enclaves with PAVP.

Based on public docs, you can't do DRM decoding in an enclave. But you can execute some complex logic to validate a user's license and decide whether you want to release the encryption key to the ME or GPU.

TXT requires an ACM, which is essentially a small signed BIOS subset. At least ACMs are freely downloadable from Intel, and they don't look into what you'd like to run under TXT.

https://software.intel.com/en-us/articles/intel-trusted-exec...

It gives Intel control over developers. In general, a computer will execute what you ask it to. SGX will not let you run production enclaves without Intel's permission. This is like Verified Boot, except there's no credible security benefit to be gained from it.

Sadly, leaking the key is not the answer. You'd give independent developers the freedom to use SGX, but at the same you'd make SGX worthless.

Details: if the key used to sign architectural enclaves (like the Launch Enclave) would leak, this would completely break SGX. Anyone with the key could create their own Quoting Enclave and the guarantees behind software attestation would go down the drain.

I expect this to play out like the W3C EME standard. Software attestation separates debug from non-debug enclaves, so your kernel will need to load production enclaves for you to watch Netflix. If Mozilla/Firefox caved, so will Linux.

Perhaps it means they're trying to be thorough?

A Xeon implementation would have to secure the QPI links between the CPU chips. These run at significantly higher speeds than DRAM, so the current MEE design would likely not be able to keep up. Also, a Xeon implementation would have to somehow have the chips mutually authenticate each other.

That being said, I wouldn't be surprised if Intel was trying to see if they can get away with the licensing bs in desktops before committing resources to tackling the challenges that I mentioned above.

I'm terrible at writing. I am trying to say that SGX cannot restore things from the SSA, and it has to use some protected area. To the best of my knowledge, they're using the non-architectural area of the TCS, which is protected from any sort of write.

If SGX becomes successful, Intel becomes the Verizon+ATT+Tmobile+Sprint of hardware security. No signed enclave, no security.

Thanks! Platform for 6.470 day 1? (html / css / js)

I can't promise anything, but I can assure you that we're well-aware of the pains of the current authentication model.

Did you try using Prey? Do you know when and how is the GPS used?

Flashed the Insyde BIOS using http://hexxeh.net/?p=328117655 and got Ubuntu 11.04 at it, when it was just an alpha. Filing bugs since. Will switch to the 11.10 dev version when the first alpha is out.

I always liked to test the development version of Ubuntu and file bugs. I used to do it on my main machine, but the probability of failed boots increased sharply after 9.10, so I stopped.

I consider that I did pay my due to Google: I filed ~40 ChromeOS bugs, 5 Chrome bugs, and developed a Chrome extension. The extension mitigates against a ChromeOS issue and is available in the store https://chrome.google.com/webstore/detail/fopmmgbckkdhedhndl...

I wouldn't expect performance to be a problem. For computational tasks, Ruby works just as fine on Windows as on a UNIX platform.

Windows perf suffers because (1) in some rare cases, the needed primitives aren't provided by the kernel, and (2) Windows does some things differently, and Ruby library authors don't have the incentives to design and maintain a separate codepath for Windows.

The issues above don't usually arise in desktop applications. They're seen most often in server code -- fork is missing and that sucks, asynchronous I/O works differently, file monitoring and pipes also work differently, etc.

Censorship is horrible. But if you think it's restricted to China... think about what would happen if 10,000 people would tweet something sensitive on 9/11. My guess is something along the lines of http://www.huffingtonpost.com/2010/05/10/paul-chambers-convi...

Spam-following people on twitter to promote your app: bad idea. I reported you as a spammer.

I like the nice succinct description of claims. Thanks!

Zipped source code: http://6.470.scripts.mit.edu/lectures/security/security_in_w...

Live source code: http://github.com/costan/security_in_webapps_slides

Good overview of the issues you'll need to deal with: (read the paper, not so much the class notes)

http://pdos.csail.mit.edu/6.893/2009/schedule.html

Thank you for the recommendations! I didn't know about the Cputech product.

Your intuition was right, they are too expensive for me. So, I should clarify: I am happy with using current-generation smart-card chips, but I would like to use them directly. The folks who wrote the JavaCard VM must have used some SDK... I want that SDK, so I can write my own OS.

Thanks!

Same here. 4-5 people, at most 3 / project.

Hm, I just saw this question, sorry. I should definitely clarify. I witnessed NO racism or xenophobia at Apple. I was treated very well throughout my internship.

To the best of my knowledge (2006), Apple does H1 visas, but they don't sponsor green card applications. When your H1-B expires, they'll have you work elsewhere until you're eligible for an H1-B again. This is based on a small sample (rumors).