6 ms·
Ahem http://rationalviews.com/t/presentation-on-fully-open-source-computing/89 http://rationalviews.com/t/presentation-on-fully-open-source... You could go int
by this-dang-guy 10y ago
Ahem http://rationalviews.com/t/presentation-on-fully-open-source-computing/89 http://rationalviews.com/t/presentation-on-fully-open-source...
You could go into that rabbit hole. I'd recommend against it... I lost days reading all the docs and playing with this
- nickpsecurity 10y agoAhem what? That proves nothing. Here's a write-up I did on verifying hardware against subversion. https://news.ycombinator.com/item?id=10468624 https://news.ycombinator.com/item?id=10468624 It's a hard problem. That's why DARPA is throwing tons of money and brains at it right now. Also why a number of defense contractors maintain their own fabs and packaging plants despite the technology aging.
- this-dang-guy 10y agoAnd your point is? It's not a hard problem. You either trust your fabricator and tools, or you don't. End of freaking story. If you don't, and/or you can't throw a fab plant at it, your options are limited. You can read all the docs on the open CPU stuff (as far as that goes), you can literally do everything from scratch, but unless you're a Nation State or a massive company, you're pretty much wasting your time. /edit: I don't mean this as a criticism of your writeup (where you basically state the same thing), or even some of your other comments (where you state much the same thing). It's literally an issue where there are VERY few people in the entire world capable of doing cutting edge processor design, coding, and implementation. They cost phenomenal amounts of money, and even with the money, people, and the best of intentions - a motivated nation state actor can muck things up. The only real defense we have, as regular people, is to basically see if anything we own is misbehaving. Even that is a specialized skill set and time investment beyond what most folks are interested in committing.
- nickpsecurity 10y ago"you either trust your fabricator and tools, or you don't." Equals you trust blindly or don't trust at all. There's a whole range of verifiability between those two. It's worth exploring. "but unless you're a Nation State or a massive company, you're pretty much wasting your time." There's smaller firms on buying and supply side of the equation benefiting from simpler, easier-to-inspect stuff. Especially for energy or cost savings. Examples include Moore's Forth processors, Java CPU's, Plasma MIPS (FOSS), 16-bitters in smartcards, etc. Those on 0.35 micron or up can have random samples inspected by eye with microscopes if user wants to go extra mile. Alternatively, they at least have black boxes they can analyze or test for conformance to white-box designs they're supposed to be. Or more easily monitor at analog or digital levels for inconsistencies w/ power shut off during such an event. Much more to this topic than you're suggesting.
- this-dang-guy 10y agoEven the aerospace/defense companies I work with use almost 100% off-the-shelf hardware pre-installed with OS and software by the vendors, or at least with some minimal IT work (often offshore). I'm happy to hear that there are some smaller fabs and things that are easier to inspect, but I think that the commodity level of most hardware still makes it super unlikely. If a company is willing to use Office 365 (which I can neither confirm nor deny some very large shops might use, but wouldn't be out of the usual), you cannot seriously expect them to pay proper attention to what their processors are doing. I would hope that if someone worked in high-clearance, there would be MANY such measures in place. The ease with which a fully loaded laptop can walk out of Los Alamos wouldn't really lend credence to them patching the biggest hole... the people. You are my favorite form of security guy - the insanely suspicious sort who is always looking for the weakest point. But when it comes right down to it, there's billions of weak points at much higher levels and much more easily compromised than a chipset or compiler. It's a good academic exercise though.
- nickpsecurity 10y ago"but I think that the commodity level of most hardware still makes it super unlikely." "If a company is willing to use Office 365" Oh I'm with you on this. Steve Walker's Computer Security Initiative and the Orange Book gave us lots of highly-secure stuff for defense, etc. They got rid of that for cheap, fast, fully-featured COTS. The same happens in business, aerospace, etc. The exceptions are usually pre-made appliances or, in aerospace, better components in the DO-178B Level A stuff. Much of it is shoddy. A good chunk of the defense fabs' business is probably replacing legacy parts in old equipment at prices guaranteed through corrupt contracts. They don't give a shit about security in general: just money. ;) "But when it comes right down to it, there's billions of weak points at much higher levels and much more easily compromised than a chipset or compiler." There's lots of weak points. Stopping code injection from all known vectors with simple, proven techniques at CPU and language levels eliminates the whole malware problem if apps are whitelisted, built from source, and include no executable scripting/JIT. There's ways to conveniently enforce POLA within a system (eg CapDesk), do secure (even automated) configurations of networks (Boeing's Survivability Grammers), and so on. There's components for most use-cases just waiting to be productized, integrated and sold to larger audience. Given this is 90+% of attacks, it's certainly worth pushing to establish a stronger baseline for companies that want less loss of secrets, availability, data, etc. There's only so much the traditional methods like coaching and monitoring can do if one can simply open a folder (not a file!) that immediately results in full-control of machine by malware since a thumbnail rendered. Endless crap like that exploiting underlying foundation of quicksand. The HW and SW of endpoints, at least at lowest layers, need to get in check for that other stuff to be meaningful. I'm also in favor of an integrated networking stack that makes different applications, even if using TCP or HTTP, look visibly different at the packet level so NIDS spots weird patterns more easily. Like the MLS extension but not MLS policy itself. Do it at application layers with stuff like Ethos's eTypes or security-enhanced ZeroMQ where developers don't worry about plumbing much. " It's a good academic exercise though." It's also an industry bringing in tens of millions of dollars at least. That's with costs that are too high, lack of key software support, and little to no advertising. I imagine it could be larger than tens of millions with such obstacles reduced or eliminated.
- valarauca1 10y agoPOWER8/9 isn't fully open. Read the license agreements. While you get access to a lot of stuff, there is a lot of fine print you are ignoring. A lot of the deep docs are behind paywalls. To get access to POWER8/9 literature you sign away your rights to OPEN-POWER. Also if you make anything for POWER8/9, under a public license (what license you can/can't use are dictated by the license agreement), using docs obtained from an OPEN-POWER member company if that member company upon leaving the OPEN-POWER may claim ownership of your code. They'll really only let you use 3 Clause BSD or Apache2. Linux has the only exception for GPLv2, and GPLv3 is banned, using it on a project can have your membership to OPEN-POWER revoked, and your code ownership transferred to IBM. If they decide to purpose it. OPEN-POWER isn't open. The docs are free and if you write anything too useful a high paying member can seize your software. The only protection from this, is to buy in as a high level enterprise member. OPEN-POWER is down right predatory for research free-tier membership.
- this-dang-guy 10y agoYeah, I went down that rabbit hole a bit. The point is - it's about the only way to do a real actual code audit on what your processor is doing.
- nickpsecurity 10y agoYou can pay a company to fab a Leon3 or Leon4 for you. Leon3 is GPL with eASIC already supporting it in their Nextreme's. There's also Rocket RISC-V core that was fabbed on a 45nm SOI process. Do it on the same node with anything extra an external, swappable component on the PCB for supplier diversity. Additionally, Cambridge has FreeBSD running on a capability-secure version of 64-bit MIPS on FPGA's. It's called CHERI CPU and CHERIBSD. One might put that processor on an ASIC. There's been many options but basically little individual, non-profit, or corporate work to make them happen. (shrugs)
- this-dang-guy 10y agoUnlikely to be much unless there's a prevailing need. I think it's easier to do deep packet inspection if you're that concerned, honestly.