Most active commenters
  • ryacko(6)
  • pjmlp(3)
  • standupstandup(3)
  • nickpsecurity(3)

←back to thread

441 points ploggingdev | 21 comments | | HN request time: 1.449s | source | bottom
Show context
snvzz ◴[] No.15734641[source]
Their weakest point is the hypervisor, Xen, which while a better choice than Linux/KVM, is still extremely bloated and has a poor security history.

Thankfully, better designs such as seL4's VMM do exist, although it might need a little more work [1] until usable for the purpose.

[1] https://sel4.systems/Info/Roadmap/

replies(6): >>15734676 #>>15734739 #>>15734803 #>>15734841 #>>15734956 #>>15735067 #
mmrezaie ◴[] No.15734739[source]
Xen's hypervisor's size is very small. Qubes is about security and trustability of the whole system. In operating systems for measuring the trustability of the system, one very important measure is the lines of the code. Xen has a smaller footprint in the hypervisor part. Additionally, Xen has a robust model isolation for the drivers. That's why they went for Xen not KVM. But boy I wish to see more seL4. It was sad to see Gnu Hurd/seL4 didn't make it.
replies(3): >>15734755 #>>15734790 #>>15735029 #
1. xyzzyz ◴[] No.15734755[source]
The problem with Xen is that no major industry player is backing it, especially with Amazon going KVM now.

(disclaimer: working at Google on virtualization security)

replies(3): >>15734816 #>>15734838 #>>15737654 #
2. pjmlp ◴[] No.15734816[source]
What about Cisco?
replies(2): >>15738401 #>>15738863 #
3. ryacko ◴[] No.15734838[source]
Any chance Google will sponsor secure processor architecture standards?

I mean, the US government no doubt had influence on the Trusted Computing Group (too bad the EFF totally shunned it), and through the magic of product binning and chip fab costs, we all have trusted platform modules.

ASLR currently seems wimpy.

I'm certain you are in a position to accomplish a great deal, no matter where you are in the hierarchy. Maybe the future is x86 hardware emulation for user mode processes.

replies(2): >>15734873 #>>15737871 #
4. standupstandup ◴[] No.15734873[source]
It's Intel pushing that stuff forward, with SGX.
replies(1): >>15734993 #
5. ryacko ◴[] No.15734993{3}[source]
Then from recent Defcon and Black Hat talks, they are an absymal failure. ( https://www.youtube.com/watch?v=lR0nh-TdpVg Memory Sinkhole - Unleashing An X86 Design Flaw Allowing Universal Privilege Escalation ) (I don't understand it beyond what everyone says it can achieve)

Intel should be considered to be totally unreliable and incompetent.

I mean, no one buys office store safes and expects their things to be secure in them. But a processor is a little more expensive than a cheap safe and holds more valuable things.

Edit: and besides, Fortezza is an SSL protocol option.

replies(2): >>15735025 #>>15735058 #
6. standupstandup ◴[] No.15735025{4}[source]
SGX is designed to shield software against SMM exploits.
7. ryacko ◴[] No.15735058{4}[source]
>SGX is designed to shield software against SMM exploits.

Perhaps if we add one more thing, x86 will finally be secure. You are right, Intel should be left to their own devices.

replies(2): >>15735415 #>>15735868 #
8. hateduser2 ◴[] No.15735415{5}[source]
Seems like you replied to the wrong comment, the intended parent might not see your reply because of this.. probably should repost it in the right place
replies(1): >>15736733 #
9. standupstandup ◴[] No.15735868{5}[source]
I'm not arguing that x86 will ever really be secure. However you handwaved a hypothetical "secure processor architecture". Realistically the way you do that is by making a very simple CPU, however, that would then be too slow to be usable for many applications. As a consequence nobody is doing so.

SGX is at least a middle ground - it integrates the memory access checks very deep into the memory access circuitry, sufficiently deep to block all other privilege levels on the CPU. Whilst there may well be implementation flaws in SGX itself so far most attacks have been mounted via side channels, not directly exploiting CPU bugs.

In this sense my original statement was correct. Intel is pushing secure CPUs forward more than any other vendor.

replies(1): >>15736746 #
10. ryacko ◴[] No.15736733{6}[source]
Hmm. I thought comment chains were limited in length.
replies(1): >>15739964 #
11. ryacko ◴[] No.15736746{6}[source]
I think a secure processor is very complex, not very simple. The smartest person's working memory cannot operate on more than a few hundred lines of code. A high performance processor that induces a fault when a programming error occurs is certainly very complex.

It is the wrong sense. Intel is playing catchup more than any other vendor and are selling a product that is nothing more than a bunch of cobbled together features, my opinion in the view of the statement that AMD is glued together.

replies(1): >>15737906 #
12. antod ◴[] No.15737654[source]
I was under the (possibly outdated) impression that Amazon wasn't really backing Xen much anyway, so AWS changing hypervisors might not mean much to Xen anyway.

I haven't used Xen for a while, but seemed to recall that Amazon forked it way back in the 3.x days and had been doing their own incompatible thing with it since then.

Corrections welcome of course :)

13. nickpsecurity ◴[] No.15737871[source]
The US and UK governments especially have been sponsoring great architectures for security that are described in enough detail for hardware engineers to implement or straight-up open source. CHERI at Cambridge is one of the latter which already runs FreeBSD. All Google has to do is pay a good team/company to build one that's reusable for their various products and services. Then, they can start targeting those to it at software level for better efficiency.

The project would cost money that Google has. There's not much new to invent, though. They just have to apply what's there. The performance penalties and ASIC costs are even much lower than they were in the past. Google refuses to do these things because either (a) they don't know about them or (b) more likely their management doesn't want to commit that much money to secure hardware. Typical of the big companies with the smartcard market the only exception far as stuff non-enterprises could afford.

For a quick example, they did retool software to support OpenPOWER architecture but could've also funded Raptor Workstation in a desktop or esp server form themselves. It would've been to their budget like pennies are to ours. Not even that. At least they did the Chromebooks, though, which are good for a lot of non-technical folks.

14. nickpsecurity ◴[] No.15737906{7}[source]
They're actually pretty simple if you're mostly trying to defeat software/firmware attacks. You just add some part to run in parallel with the processor, which can be arbitrarily simple or complex, that checks certain things about the data such as length or data type. The first one was implemented in 1961 hardware with it being secure from code injection until the invention of ROP. That's a long time. I'll add a modern take on that which led to a flexible mechanism that can do a dozen or maybe more policies.

http://www.smecc.org/The%20Architecture%20%20of%20the%20Burr...

http://www.crash-safe.org/papers.html

A more complex one is below that was also designed by one person for his dissertation. Knocks out all kinds of issues without modifying the processor. It has stuff to improve for sure but it think it proves the point pretty well. The stuff corporate teams were designing comes nowhere near this because they don't know much about high-security design. A critical part of that isn't features so much as a balancing act between what protection mechanisms do and don't that tries to minimize complexity to low as is possible.

https://theses.lib.vt.edu/theses/available/etd-10112006-2048...

And one open-source one on MIPS for capability-based security that runs FreeBSD:

https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/

A company or group of hardware volunteers could develop this into something at least as usable as a multi-core ARM CPU on RISC-V or OpenSPARC. It wouldn't take tons of money esp if they worked their way up in complexity. The hard stuff is already done. People just need to apply it. They could even pay these academics to do it for them with open-sourced results. They even get a huge discount on the EDA tools that can be six digits a seat.

You're right that Intel is screwing up and playing catchup cobbling together features. There was stuff in the available literature better than most of what they're doing. They even have a separation kernel from Wind River they're not employing. Managers without security expertise must be pushing a lot of this stuff.

replies(2): >>15738135 #>>15738393 #
15. ryacko ◴[] No.15738135{8}[source]
The theory is simple. I'm somewhat inclined to think it is not so easily applicable.

It is easy to make a secure coprocessor, since the formal logic proofs aren't for such a long set of code.

The fact that rootkits are even possible, that without malware that doesn't involve an elaborate rewrite of the kernel, shows how terrible everything is.

If I didn't know any better, I'd say that Intel is hiring the designers who thought Internet Explorer should be in the kernel.

16. gggvvh ◴[] No.15738393{8}[source]
Ain’t no problem that couldn’t be solved by adding another layer of indirection, eh?
replies(1): >>15740298 #
17. pjmlp ◴[] No.15738696{3}[source]
I don't know, doing business like every other major IT company?
18. walterbell ◴[] No.15738863[source]
Where does Cisco use Xen?
replies(1): >>15739028 #
19. pjmlp ◴[] No.15739028{3}[source]
It has common products with Citrix for Citrix XenServer, https://blogs.cisco.com/datacenter/citrix-synergy-round-up-c...
20. hateduser2 ◴[] No.15739964{7}[source]
Not that I know of.. although the reply button sometimes doesn’t show up.. you just have to click Into a comment if it’s missing for you
21. nickpsecurity ◴[] No.15740298{9}[source]
Maybe in web or application software. In hardware, it all runs in parallel. The mechanism of something like SAFE becomes another component receiving input in the CPU pipeline. A conditional of sorts is added so the final write back to whatever memory doesn't happen unless the safety/security checks passed. The failure mode might also do an interrupt for OS so it could log the where and why of the failure. As in, application flaws could be patched quickly.