4 ms·

That serves my point that introducing a security-enhanced processor didn't work for Intel. i432 APX and i960 also failed at a loss of over a billion dollars so

• close04 8y ago
  > Intel should continue to make deliberately insecure processors and patch them since that's what people pay for. Unfortunately... What's more disappointing is that while you expect the average Joe to go for shiny-new-fast, enterprises should have been a little more restrained. But hey, it's only an issue when it's found and with the power of hindsight all decisions are easy.
  • nickpsecurity 8y ago
    It wasn't hindsight: we've been publishing and describing these risks along with techniques to mitigate them for decades. https://news.ycombinator.com/item?id=16092183 https://news.ycombinator.com/item?id=16092183 Mainstream security ignores it for political reasons. They're like a cliche that pretend all prior work that's not like theirs or are outside their social groups didn't happen. Enterprise ignores it since management gets rewarded for either high-growth or low-cost deployments. Those tend to favor insecure deployments. The consumers don't care enough for I guess psychological reasons. They don't even adopt usable, free stuff like Signal most of the time. Much less paid options. The high-assurance, security field has steadily done their part producing secure versions of hardware and software to address these risks. They usually knock out entire classes of attack. Almost nobody uses them outside of aerospace and defense. For hardware, few companies will build the secure prototypes since prior examples went bankrupt. The Spectre/Meltdown situation gives potential to use it as a buzzword pushing new hardware. That hardware needs to be totally compatible with existing OS's/RTOS's and C language, though, with almost no performance or cost hit. I think secure ARM's or MIPS's are best start. CoreGuard is example targeting them plus RISC-V. We'll see what happens.
    • close04 8y ago
      Because the regular timing attacks were always relatively easy to mitigate in software with low performance penalties? Unless I'm misreading your comment, you're saying Meltdown and Spectre are just the "run of the mill" cache timing attacks about which tens or hundreds of papers were written in the past years. In which case the same mitigations should still apply since they have been used in cryptography for decades. If this is the case and there's nothing more to them, and since you appear to be working in the field, I have one question: what is it that triggered this kind of response now that wasn't already triggered by the swath of already existing papers?
      • nickpsecurity 8y ago
        Now you're putting words in my mouth. I'm saying almost all of the advice and techniques were ignored by security community for years whether it incurred a performance penalty or not. That's covert channels in general plus cache-based timing channels. I mean, when is the last time you saw someone writing FOSS with crypto or for security say they did a covert, channel analysis of their software? Pretty much never happens even though it was a mandated step in older and current evaluations with every certified product at EAL5 or above getting one. Heck, we couldn't even get a lot of developers to stop using C when safer languages like Ada or Modula-3 were available that fit their use case. Companies that claimed to take security seriously and had money for secure products wouldn't buy them. People who had money or whose uses could fit safer processors often didn't buy them. Hell, one company whose products got lots of analysis were selling a secure RTOS, file system, and network stack for $50,000 license with no royalties. A router company could've greatly reduced attack surface that way on top of reliability/predictability improvements. The big players had huge piles of money, too. IIRC, only one company, not a big vendor, put a separation kernel in a network switch. And withdrew it later since nobody bought it. Sirrix is still selling stuff with similar design (Google Mikro-SINA architecture) but not same assurance or amount of evaluation. GENU is using OpenBSD variant. Only two I can think of that probably sell a lot of product and will be around a while. It's pretty systematic that strong methods and products are ignored. Far as security folks, most of them don't know anything about this stuff despite it being in colleges, conferences, here on HN, and so on a long time. Those that hear about it mostly dismiss it often not even knowing what's in it. A cultural thing given they're dismissing stuff that resists attack well in favor of stuff that often fails. If they didn't, they'd have known about cache-based, timing channels in 1992. A paper somewhere in 1992-1995 range referencing that work analyzing either VAX or x86 noted potential leaks in many components and modes. It called for every component to be made leak proof to maintain the security policy. As usual, both private sector and security folks acted like that stuff didn't exist. They patted themselves on the back when rediscovering the same shit in 2005. Others digging into it more found Meltdown/Spectre many years later. NICTA doing a systematic analysis more like 1990's work found all kinds of attack surface in one pass: https://ts.data61.csiro.au/publications/nicta_full_text/9074.pdf https://ts.data61.csiro.au/publications/nicta_full_text/9074... Meanwhile, those in CompSci and industry that paid attention were working on hardware architectures that minimized problems. Partitioning caches, asynchronous execution with randomization (I independently invented this), and masking are examples. An product example is Rockwell-Collins' AAMP7G CPU that was mathematically verified for correctness, embedded a separation kernel that does time/space partitioning between processes, did a proof it was correct, and triplicated the registers with voting to increase reliability in face of cosmic rays or individual failures. So, the CPU itself mitigates timing channels plus separates processes with maybe stronger assurance than seL4 given a microcode-level proof on verified CPU. They also have tools to prove your algorithm and assembly code match to prevent abstraction attacks. They sell those CPU's commercially in aerospace and defense. They use the tools to build stuff for their customers, esp crypto for NSA. Cambridge is doing CHERI which runs FreeBSD; Microsemi's CodeSEAL has control-flow integrity with encrypted, authenticated RAM for FreeRTOS; Softbound/Hardbound/Watchdog team has theirs for safety; several teams have done non-interference for hardware with one proven down to the gates; Edmison did encrypted/authenticated RAM in a way that preserved legacy processor architecture and blocked some software attacks; Dover is doing SAFE architecture (crash-safe.org) for ARM/MISP/RISC-V called CoreGuard; SCOMP, first system certified by NSA, had security kernel, leak analysis, and an IO/MMU in 1985; AS/400's predecessor had capability-based security at hardware level; Burroughs B5000, the first mainframe in 1961, was immune at CPU level to most forms of code injection at CPU level. These methods were published enough that all kinds of people were building on them. Most security professionals ignore them, even claiming nothing was ever achieved (just "red tape"). That's straight-up slander. The industry and consumers mostly didn't buy them since they wanted to either minimize cost (security is externality) or wanted specific benefits of insecure stuff (often got hacked). If they want secure CPU's, they can just buy some I mentioned that still exist and/or (supply side) build them based on highly-detailed descriptions of other stuff. CHERI is even open-source running C language and FreeBSD on FPGA board. You can bet a MIPS licensee hasn't built a CHERI SoC since they believe market won't pay for it. " I have one question: what is it that triggered this kind of response now that wasn't already triggered by the swath of already existing papers?" You'll find that most things in IT, including INFOSEC, are driven by mass psychology more than technical reasons. I'll demonstrate instead of explain using Heartbleed. It drove a lot of security discussion and fixes. Yet, it would've been prevented by pre-existing advice on using safe languages like Ada or a combo of tools plus development practices on C code. David A. Wheeler illustrates all the stuff that was available which developers were ignoring here: https://www.dwheeler.com/essays/heartbleed.html https://www.dwheeler.com/essays/heartbleed.html So, someone finds the attack, they publish it with a catchy name, and suddenly people are all over this issue. It drove even more activity in that part of the field. They can either adopt the advice of the people who managed to dodge all that or they can't focus on the narrow problem affecting them right now. Most response to Heartbleed did the latter with them still using unsafe practices and underusing available tooling. Baseline did increase in some places, though. That was good. I think Spectre/Meltdown is just another example of that effect in action. It probably has a name already like herd behavior, getting on bandwagons, etc. Like before, they have at least two choices: listen to the people who used specific techniques to discover everything from cache-based channels to operating system leaks, using those same techniques that worked again; ignore all that to focus on every way you can squeeze a side channel out of the same or other components of x86. The correct answer is the first since it will do the second as a side effect plus show you all the other channels elsewhere. Kemmerer's and Wray's methods were universally applicable. Most work following Meltdown/Spectre is ignoring that to react to the specifics of the attack with narrower focus. Most, hopefully not all, of the solutions being designed will fail since they clean up a problem here while ignoring those over there. And we'll get another fix and another. Avoidable damage will keep happening. I am hoping that a better scenario plays out with things like CoreGuard coming to market right as hardware is getting attacked. The better scenario is it sells profitably due to heightened awareness which fuels further development of secure hardware/software. We'll see.