Schneier on Security

Nick P • March 28, 2014 10:21 PM

New site design threw me off at first. Figured it was glitching. Anyway, it looks alright except that it’s so bright. Grayish, thin text on a background of lots of white. Squinting at it gave me a headache on one of my machines. Red links are an interesting choice. They fit with the design. I like the top right image and prominent ‘featured essays’ section, too.

Nick P • March 29, 2014 8:39 AM

@ Jacob

re targeting Windows OS vs .NET

Microsoft’s security initiatives under Steve Lipner seem to have worked. From XP to Vista, the number of severe vulnerabilities went down despite amount of code going way up. Then Win7 seemed to do better. Overtime, the low hanging fruit in Windows OS goes away more and more. So, what to attack next?

Answer: privileged, complex libraries and runtimes! They might be written by less capable programmers or simply be less understood in a security sense. The result is more vulnerabilities. A good example of this trend is Java. The attackers are hitting Java at every layer, while using it to compromise Windows OS. Apparently, Windows OS is harder to hack than Java. This might be case for .NET, too, so TLA attackers could look for (or plant) weaknesses in it.

Along same lines, I’d also check their C++ redistributable and anything else major enterprise apps from Microsoft depend on. Such dependencies sometimes create a “hack one, compromise many” effect professionals would definitely look for.

Nick P • March 29, 2014 11:51 AM

@ Steve

I agree about the readability. I usually zoomed in on my phone on old site. That’s no longer necessary. So, if they can just fix the aspect that makes it seem blinding, perhaps add contrast, then new design would be fine.

Nick P • March 29, 2014 9:26 PM

@ Coyne

I saw that and was disturbed by it as well. Taken literally, shutting down for such a reason would be the lamest defeat in history of mailing lists. I mean, some individual is ticking you off so you shut down your whole project? It’s almost unbelievable.

Like you, I wondered if there was something else that happened (maybe with NSA), they can’t talk about it, and are trying to convey it without risking harm to them. If so, then they couldn’t give us the specifics and what they’re doing is already risky. I hope it’s the latter.

Nick P • March 30, 2014 8:52 PM

@ Coyne

On Mobile, the right-side menu appears at the bottom after the post and all the comments. This is in both default Android browser and Chrome. Of course, the recent comments link is the only one of them that’s critical, so it’s the only one I asked to be on top. Saves around 10 seconds of scrolling or tricks going to bookmark manager a lot (current approach).

Nick P • March 30, 2014 9:28 PM

@ Figureitout

I respond to him for the sake of other readers just dropping in. He’s a much more sophisticated plant than the usual type. So, I like providing alternative view to any dropping in on the page.

” stated that if you wanted to join NSA to join the military”

That was true a long time ago. The NSA is a quasi-military organization with a huge chunk of its people either coming from the military or on loan from military. They also work closely with military as military units depend on their SIGINT. So, naturally, being a person in the military who could get things done and understand tech can get a foot in the door.

In past decade, NSA and its contractors experienced a lot of growth. Hayden also transformed the agency. The result was that they wanted to hire many more people in many categories. It was easier than ever to get in the NSA if you had a degree, a decent resume, and could get a clearance. There’s plenty of job posts for them even as I type this. So, the old wisdom stopped applying with options being broader.

However, post Snowden and paranoia over inside threats, it wouldn’t surprise me if getting into good NSA positions is harder now. That they wanted to fire half their [loyal] sys admins after Snowden leaks should make people pause before sending in that job application. Of course, any job that produces something (intel, 0-days, etc) is usually fairly safe so long as their budget stays high.

All that said, people wanting to do real security should get a job at a private organization. There’s a few in commercial sector, the defense contractors, and some with academic/R&D focus. These have groups that put extra effort into security of their products. Working for NSA is only for people who’d rather compromise systems as their information assurance offerings are mostly a joke designed to lead to hacks.

Nick P • March 31, 2014 11:11 AM

@ Skeptical

re ad hominem, personal assult, or merely due consideration?

I certainly won’t condone personal attacks on you as it only weakens’ attackers’ credibility or character in mind of casual readers. However, it’s entirely reasonable for them to think you’re trying to spin the discussion based on the content of your posts, the timing of you appearing, your conversational style and other attributes that suggest a spinner. It’s even more important given that psy ops is a common technique in both US and British intelligence. Both of these organizations oppose people like Bruce publishing leaks and hence might go on the attack. There was even a nice leak with tactics eerily reminiscent of your conversational tactics.

In any case, considering whether you’re paid to influence discussion is valid as spy agencies are paying people to do that. Yet, I still try to avoid downright trash talking you as I think (a) it won’t change anything and (b) reduces the appeal of this typically civil blog. Regarding (b), I’d rather it continue to attract new commenters with interesting perspectives and keeping things civil helps.

Nick P • April 2, 2014 3:57 PM

@ Skeptical

“You argue that (I’m putting these in my words not to twist what you’ve said, but to verify that I actually understand what you’ve said):”

Close enough.

“These would include court orders under Section 215 of the Patriot Act and Section 702 of the FISA.”

The NSA representative mentioned a program that does massive collection, not invidual requests. It’s obviously much broader form of coercion than that. If they can be legally coerced into modifying their systems for this program, we must assume they can be coerced into others. Given the deception so far, the only reason an American should assume different is if a credible independent review with full access & legal authority to declassify information tells us otherwise. The legal authority isn’t for leaks as much as circumventing any rules of “you can’t talk about that so you might as well lie or use these weasel words.” That sort of thing.

“I’ve yet to hear of an example of a company receiving a request from the NSA to knowingly weaken its product and doing so. The closest example is the RSA case, but that’s not clearly a case of NSA subversion, much less RSA’s knowing complicity. And even then, that would be a single case.”

It’s clearly a case of NSA subversion as RSA’s customers secrets were put in NSA’s control without their knowledge due to a partnership between RSA and NSA. Single case or not, it establishes that NSA is willing to pay companies to backdoor their products. Then, we see all these potential backdoors in products of other companies who are in a position to be influenced by US govt. A default of no trust is reasonable here.

If US govt is concerned, they can pass laws explicitly banning subversion of US products and instead only allow selective information sharing (a la per target or group intercepts). That they’re unwilling to do something like this shouldn’t inspire trust.

“Abroad, it has been reported that the CIA works with the NSA in the deployment of signals intelligence capabilities, and certainly that the NSA has personnel who are “in the field” in the sense that they are outside secured facilities while collecting intelligence. But it has not been reported, as far as I’m aware, that the NSA has a HUMINT capability, nor can I see any reason why the NSA would.”

All the outsourcing and partnerships mean that whether NSA owns the capability isn’t relevant. Whether NSA has access to HUMINT assets to further its mission is. This is one such organization although I’m not endorsing all that material on this particular link. One can look for other sources on the agency. NSA and GCHQ also work very closely on these capabilities. We know GCHQ has a team dedicated to HUMINT against telecom companies via recruiting their employees to sabotage their security. That BULLRUN partly used relationships with companies to bypass their security in combination with GCHQ says enough.

Of course, mentioning these in speculation was just to see if you’ve read the actual slides. That they work with (or coerce) companies to backdoor their products is indisputable. There’s already a smoking gun:”

“The SIGNINT Enabling Project actively engages the US and foreign IT industries to influence and/or overtly leverage their commercial products’ designs. These design changes make the system in question exploitable through SIGINT collection (e.g. Endpoint, MidPoint, etc.) with foreknowledge of the modification. To the consumer and other adversaries, however, the systems’ security remains intact.” (NSA document)

“Insert vulnerabilities into commercial encryption systems, IT systems, networks, and endpoint communications devices used by targets.” (NSA document)

“Influence policies, standards and specifications for public key technologies.” (NSA document)

QED. You’re faith in them was mistrusted. They are influencing vendors here and abroad to backdoor their products, even up to “design” level changes and standards.

Note: I also found it interesting that they said “to the consumer and other adversaries.” Implies the consumer is an adversary to them. Normally, I’d write it off as a phrasing issue, but their programs try to target nearly everything. So, it’s probably how they look at all of us.

re economic pressure

“First, a company that knowingly weakened a product design on government request could face enormous legal liabilities once exposed in the form of securities litigation. ”

They wouldn’t if they were required to under law via national security. I believe those involved in the warrantless wiretapping got criminal immunity, as well. No doubt those involved with other programs would get this. The only criminal decision is not following the legal mandate.

“This is especially the case if the company represented its product falsely.”

Whether they lie participating in a national security program is typically irrelevant in court. Those getting even NSL’s were typically prohibited from talking about them to the public. The court documents in the Lavabit trial, linked here at one point, feature the Lavabit owner making that exact argument against giving FBI his private key for all users. The FBI’s response, which the judge agreed to, was that if he wasn’t allowed to tell customers then they’d never know he lied about their privacy and no damage would happen to his service’s reputation. My jaw dropped when I read that as I never thought I’d see them be so openly devious in a court document. Supports my notion that these US govt TLA’s are fine with subverting a service while protecting the company’s lies about its privacy.

“large companies in the US, such as IBM, have considerable clout with Congress and any President. Threatening them with the cancellation of all government contracts would require a political will and leverage that the NSA doesn’t have. ”

The key Congressional committees and the President support NSA’s programs. The major players in IT that get most contracts do it by kissing the governments butt, along with generous bribes, err, campaign contributions. They would see the coercion as a cost of doing business which had little to no effect on them otherwise, along with promised secrecy as a risk mitigation. My theory plays out well with real world data where we find all these American companies were secretly and knowingly giving over data, sabotaging products, etc. Then, upon the leaks, they feign shock and ignorance while complaining about lost trust and business.

“Third, if any large company in a given year suddenly lost all its government contracts, the event would attract enormous attention, dramatically increasing the probability that reason for the cancellation would be leaked.”

The one strong criticism. This means they’d have to take one of several options:

1. Influence people running company (benefit or coercion) instead of the company’s contracts themselves. eg not use contracts themselves as a threat, but as a justification for decision-maker they control.
2. Make them loose key contracts to competitors and more often. Make up beaurocratic excuses as to why. This has happened plenty of times in defence industry for both big and small companies. Questions can be raised, yet a malicious version of this is deniable & severely impacts bottom line.
3. Use the FBI, IRS, or SEC against them with false or real charges. If the charges are severe, esp involving fraud, then DOD has a decent public explanation for why contracts were suddenly cancelled. This would also hurt a stock price. The mere threat of this happening would be enough to make many give in, especially if the subversion had deniability.

Of these, options 2 and 3 seem most plausible. Remember, though, that the whole thing can be seen as a cost of doing business that has almost no cost and little risk to the business. Many NSA backdoors are designed to be subtle and look like programming flaws, a common thing in IT. Others, such as certain TAO implants, are designed to be invisible by residing in areas no hacker, sysadmin or user are likely to see. So, would a profit-motivated company with a lot of contracts do a little favor for influential DOD entities to maintain a privileged position? The answer is “Yes for any rational company in that position maxing out their bottom line.”

And who knows, they might get paid $30 million or something in the process. cough RSA cough 😉

“As to 6, I’m not sure what you’re referring to, though you say that you linked to something supporting your claim. Are you talking about the Perfect Citizen program?”

Yes. NSA already had technical solutions to the problem that even their pen testers didn’t beat during certification. Advocating weak solutions that merely give them control is devious at worst and foolish (versus protection) at best. Offering strong protections with “optional” free monitoring would be acceptable as at least they spy and protect at same time.

” second, it’s interesting that Gilmore remembered these things only after the Snowden leaks ”

Schneier and others criticized IPsec going way back. NSA’s secrecy on their programs and appearance of aiding security standards meant that people weren’t as concerned about them in certain situations. Then the Snowden leaks showed how actively they were trying to undermine everything. So, everyone takes a fresh look at things and Gilmore notices that NSA-sourced submissions caused glaring security weaknesses. Anyone looking at NSA cryptography knows they normally filter out such nonsense. So, he connects the dots that they might be intentionally introducing weaknesses along the lines of that BULLRUN program that mentions weakening cryptosystems and standards for easing SIGINT collection.

Very sensible concern and the closest one can typically get to solid evidence against a covert op by a professional spy organization. It cannot be overstated how hard it is to catch good, well-funded, high-tech covert operators. That evidence is more circumstantial is natural to the game. It’s not like he can sue them, request their top secret files in discovery process, and cross-examine key witnesses to the programs. The pervasive secrecy makes investigations hard, yet Gilmore’s points are still strong enough to have reasonable suspicion NSA corrupted the standard. And, hence, enough reason to distrust those who made the submissions and reform/replace the standard.

” I’m not sure what’s radical about the idea.”

You’ve never explained it to someone. I speak from experience that this is one of those risks that’s hard to get across. Even now having NSA catalog showing the devices, it’s still so esoteric that it’s hard to sink in the concept or justify the cost of a defense. These attack methods are also used mainly by pro’s who are great at not getting detected. It just all adds up to make it a hard sell. Such things are better off being incentivized by regulation & government investment. That it’s not even permitted is… worse than a hard sell.

“and that foreign companies continued to produce versions with progressively stronger encryption notwithstanding export restrictions they faced in their own countries.”

Yeah, they showed the foolishness of those restrictions. Additionally, high assurance security engineers pointed out restrictions on those systems made little sense as the methods for producing them were public knowledge and Europeans in particular were ahead of us in some aspects of them. Banning would just cause domestic production of equivalent or better. Happened just like you said.

“To sum up on the question of overall policy, it appears to me that the US transitioned during the 1990s from a world in which computational power was weaker and less widely distributed, and in which, consequently, what you would term today to be strong encryption was less widely needed.”

It’s incorrect. There was a transition in computing. The core problem for NSA remained the same: collect everything they can and never be blocked by privacy technology. They fought to limit software level of it from foreign sales, with hardware weakenesses existing domestically as well. Cypherpunks beat them with widespread crypto, while OSS software and security tech also undermined it. U.S. TLA’s struggled to prevent a blackout of information. So, they produced programs to undermine security everywhere in many ways and pushed for legislation to force US companies to secretly provide them information. Post-9/11 both activities got major boosts, including solid legal support, resulting in massive expansion and success of such efforts. The end result is that, today, one can’t be sure if a product in a number of countries is working for the customer or for certain spy agencies.

That’s it in a nutshell. The other points and docs are just about filling in the details of their methods, their policies, effects over time, and current effects. That said, I think we’ve hammered out this topic enough. I’m leaving the discussion but feel free to comment further if you want.

Nick P • April 3, 2014 8:52 PM

@ name.withheld
(continued)

“May give it a go, not for an application platform but a hardware/router device. My plan is to build out a new secure perimeter and proceed with virgin builds of other platforms. ”

Starting small is smart. Yet, I’m telling you that if you have embedded experience you might be going in the wrong direction. Almost all attacks hit code (in various places) and abstraction gaps. The Orange Book, MILS architecture, etc seem to focus on everything but that. Closing these holes is paramount to a clean slate redesign. The SAFE project is doing that with a tagged memory processor, CHERI with segmentation, and I’ve been looking at every architecture going back 50 years. I’m trying to find something good enough to stop most threats, yet with quick implementation potential.

I like taking mental shortcuts. Eliminating unsafe code from the system, first done by Burroughs B5000, is a good one. Ensuring that code & data are treated separately/safely at instruction set level (via whatever mechanism) is also nice. If implemented properly, it lets you prevent code injection just by designing a small TCB and initializing the system right. Updates are easier, too, as a dedicated module can verify it with anything from signatures to human review of text. Point being, whichever architecture should support HLL development easy enough while being immune to memory, IO, and control flow attacks we’ve seen so far.

Tall order. What to do… Well, while I kind of hate the language, the one shortcut that keeps coming back to mind is Java. There are Java processors, from OSS (JOP) to GOTS (Sandia SCORE) to patented (jHISC), that run Java bytecode natively and eliminate abstraction gap that causes 99% of attacks on platform. There is also a capability secure kernel (J-Kernel), a capability secure subset (Joe-E), a distributed obj-cap language (E), a maybe secure OS (JX), a desktop OS (JNode), a certifying compiler (forgot), formally verified equivalents (Jinja), information flow control (eg Thober 2007), and so on. I’m sure that some combination of these methods, starting with an enabling SOC, can be used to make a secure system design easy as hell compared to native code.

Long term, I’d rather it not be Java & there might be alternatives out there. Regardless, there are so many tools out there for Java and a suitable subset (eg Middleweight Java) should be easy to analyse/implement… esp if on a machine natively executing bytecode. The resulting system might involve FPGA’s, COTS components, custom boards, low-level interfaces, etc. This is where you embedded guys have an advantage that might lead you to achieve a solution faster than most others. There will be the central processing unit, the memory subsystem, and IO subsystem. Whether Java or tagged processor, I recommend modifying IO subsystem to do the following:

1. Assign each device one or more specific areas of memory, assignable only by privileged software.
2. Enforce that with IOMMU.
3. Seemlessly add proper tags (general IO or device specific) to data sent to memory and remove tags on data retrieved from memory.
4. Possibly add security checks based on tags or arbitrary policy.

5. Possibly use open cores for each type of IO (eg Ethernet).

Bare minimum for IO has to be safe comms with privileged software on CPU, an IOMMU for device access, and respect to memory tags/types/capabilities. These protections must remain even if 5 is used in case of accident.

Boot Process

First stage is loaded from an actual ROM. You gotta make this one flawless as possible or at least make ROM’s easy to physically swap out. The ROM tests basic instructions, optionally tests security critical functionality, optionally executes entirely in onchip memory, definitely loads software from on-board flash into main memory, hashes it, validates the signature attached to it, and if succeeds passes control. This combo of ROM and flash boot allow you to change firmware as much as possible while still having trusted boot process. Updates would be signed images flashed by privileged software and only with a physical switch enabled. IO would default on not accessing a certain segment of memory and blocking most devices on startup. It might even stay off until the TCB is fully ready.

Kernel

I gave you plenty of options. You can copy a microkernel approach. You can do it like a library that all programs connect to. You can use capabilities. You might just use regular objects, function calls, etc as Java processor can be made to enforce all that. For resources, I’d copy INTEGRITY RTOS’s approach making non-privileged programs donate their own CPU/memory to accomplish kernel calls. You might modify the processor code to speed up or handle certain tasks. I’d add an open core for onboard crypto, for instance. I also remember Intel 432 had onboard support for segmentation of memory via objects and garbage collection. JOP and others added concurrency enhancements to prevent most problems. Others protected control flow. And so on.

Non-kernel

You know the rules here. Modularity, careful interfaces, layering, making each object/module do one thing well, minimizing shared state, and so on. Pay careful attention to the protocols, replacing insecure ones with secure one where possible. Isolate or monitor what you can’t replace.

Compilation

There’s certifying compilers. If you can’t get one, I suggest testing the code with existing compilers and then just hand-rolling the initial implementation. Or retarget a simpler language (eg Oberon, Forth) to Java to make the compiler easier to write. The core routines (eg kernel) you might even hand code in java assembler initially. Regardless of approach, you must ensure you’re compile, link, sign, and deploy cycle is correct. The sign part is easier for target machine to check than a full source validation, saving you time. Plus, if you keep compiling machine safe you get source validation and trusted loading. 🙂

Admin

Admin will be a two step process. The first is for building your system. There will be four computers total: untrusted powerhouse you do all your work on 1; a trusted guard 2; semi-trusted admin box 3; trusted, safe target 4. You use 1, pref with LiveCD, to fetch source copies of all the tools you think you’ll ever need. Check them every way you can. Move them to admin box via guard. The guard will be a simple batch/interactive type system that pulls data in over safe IO to memory, lets you validate it using deprivileged programs, and lets you visually validate anything. You can check as many sigs, hashes and source as you want for each thing you move.

Once it’s all on the admin box, you have a semi-trusted machine to develop prototypes on. The rest of the source you move should be simpler, often aiding your own developments. You will visually check them through the guard, maybe with certain input processing involved. The admin box will do all the rest from SCM to deployment to management. This process lets you use all the needed tools, easily vet new ones at your own pace, and still be isolated from many threats. Over time, the admin box’s functions are replaced by more trusted HLL code that your trusted target supports and eventually admin functions run on your secure architecture with full security.

Services

There’s already a ton of libraries, algorithms, protocols, and entire applications coded in Java. Getting things running initially is just porting a bunch of stuff. That makes your architecture more productive. Porting something like Jython or Clojure later on will make it even more productive.

Interconnection

If secure IO, safe CPU, and POLA software, then running untrustworthy protocols or apps might be safe for system as a whole. My old externalized IO trick still helps if you have doubts as the comms layer on trusted device can be simple while real work of eg HTTP/TCP/IP/Ethernet is handled on untrusted device. There’s also verified parsers (eg INRIA) that, combined with safe code, might make input validation a non-issue. In the past, I just used LISP syntax subset and made the best parser for it I can. From there, each parser just produced and accessed different AST’s that LISP lexer automatically created. You can replace parentheses with less used character if it helps in certain scenarios.

Clustering

Might be load balancing, failover, isolating certain services and so on. The easiest approach is a dedicated management interface that connects to trusted software. (assumes physical security) The single node software can be modified for the other use cases with all the commands and coordination sent in native (or near-native) form over the management line. All potentially hostile stuff is restricted to untrusted network. Requires two lines per node but is so much easier to build-in secure management, coordination, etc.

Trusted Path

Your system needs one. Console will be simple enough: process that reads input and redirects it to whatever has focus; an ability to track and change focus; part of console reserved for trusted path to say what has focus; dedicated key sequence to activate trusted path if it’s a separate thing; all other processing handled by individual apps (which are basically executing java classes); app with focus’s virtual console output copied to real one by TP. GUI is similar just copy Nitpicker or EROS windowing system, optionally using protected IO to dedicate a GPU or other accelerator to a given app.

Backups

A CD/DVD drive in you admin box will be easiest. Alternatively, if you have existing SAN, sending a crypto sealed version of data over guard to it might be alright. Just have offline backups and check them, preferrably with the guard. Have separate backups of your admin server itself and the user data it stores. The former might be an image on trusted media, while the latter are files that might be stored and used wherever.

So, that should about cover it. Start with safe core in hardware, build a TCB software can’t mess with, and put robust software on it. Anything less will be bypassed by attacks below software abstraction in all likelihood. Btw, consider using anti-fuse FPGA’s and open FPGA synthesis tools for final deployment if you’re concerned about subversions at that level. Whether you adopt any or none of this, good luck.

Re your movie plot idea

It’s interesing. Even on a limited scale, such a scheme could be quite beneficial for hedge funds in event-driven and relative-value classifications. Many conspiracy theories focus on event-driven model with a disaster upping someone’s bottom line, either caused by them or with them tipped off. A less tragic version could happen with level of foreknowledge NSA has on businesses in more ways than I can count. The relative value one can be done similarly with stolen information about state of the business.

The bigger picture you’re going for, though, seems to be the other classifications that focus on market trends and big picture bets. Given enough influence, an organization with this amount of information could use it to set trends that do more than profit: straight up power can be had. Quite a few ways to go about it and complex to discuss. However, the working methods of Wall St and Big Data are even more complex.

Of course, if one of the existing cabals (eg Bilderberg types) are as powerful as some believe, they’re almost certainly doing something like this right now. The elites ties to both the surveillance state and 2008 crisis show that they’re not ignorant of such manipulations. If anything, the brilliant people they hired kept them many steps ahead of the majority and made their dominance of markets/govt easier. It’s rational to believe such organizations continued to develop new schemes to leverage every asset they have available, including Big Data or NSA if possible. Their very nature says they’re planning/executing one or more such schemes right now.

I mean, the last one worked so well for them: $1 trillion with criminal immunity and all profits included. Two profitable wars before that. They’re on a winning streak. Why stop now!?

Nick P • April 4, 2014 11:28 PM

@ name.withheld

“what was the register mix as a percentage of the netlist(s)? Some FPGA devices have some strange LUT/CPLD allocation limits/specifications.”

The paper said 8,000 registers and 35,000 gates total. Not a hardware engineer so that’s all I can give you. The FPGA might have been a Spartan 3 as most smaller designs I read about use them. It even seems like a bragging point to many of these designers: “Our design is so compact it can run in the cheapest, mainstream FPGA you can get. Beat that!”

“The sandbox was operational and there weren’t a lot of extensions to the AWT–then it just went to hell and a hand basket as features that others pushed for were included…”

I wasn’t going to push Java anymore, but then I saw that. I have to remind you that what you describe is the popular desktop/server Java, which is an atrocity. The Java processors tend to support a subset of it that’s more low level and might not even do garbage collection. Many don’t even support most of the Java libraries because they use features not supported by processor (and native code). SSP, in particular, is closer to embedded, real-time Java standards than anything else. JOP is for embedded, too. jHISC started that way, got upgraded every year and now claims to be ready for desktop/server. Don’t have hard data on that upgrade, though. Point being, hate mainstream Java or not, the Java processors are targeted for a different type of it that you might not hate so much.

Or maybe you will. Who knows lol. (shrugs)

“You brought a tear to my eye when you mentioned Nickolus Wirth–and Modulus 2 is not a bad choice and ranks between Smalltalk and Prolog.”

The guy was a genius. Modula has sadly died off for the most part. Yet, the Oberon systems and compilers were ported repeatedly. A2 Bluebottle is the latest, although I’d use AOS for a minimal system. There’s even an IDE for a microcontroller now.

I’ll briefly comment on your requirements.

” No legacy architecture support (i.e. drivers) I/O security is issue.”

Yeah screw that stuff that only holds us back.

“3.) MMU and DMA isolation layer (a physical interface, not internal to proc).
4.) ALU and CPU cores also as an isolated physical layer.”

The more protected they are, the better.

“6.) Memory tag and access violation hardware support (dma, bus, possibly spi) via snooping — could use a dedicated/separate hardware core”

SAFE processor includes a tag management unit tied into the processor. So, the main chip works hand-in-hand with unit dedicated to checking tags. Says your idea is feasible. Also, typical approach with tagged processors is to go ahead and do the computation, but don’t write it to memory/whatever unless tag unit says Ok. Boosts performance plenty.

“8.) Robust and simple micro-kernel doesn’t need to be RTOS but, a separation kernel is that supports a virtualization layer with hardware level monitoring of the context data”

If you don’t want to spend $$$, check out Fiasco.OC. It’s the latest version of Dresden’s L4 kernel with an object/capability focus. You could easily modify it to do things like periods processing. Might also negotiate a deal with market also rans like VxWorks MILS, LynxSecure, or PikeOS. GHS is dominating with INTEGRITY-178B, so I’m sure you could scheme a discount out of the others if your project will give them recognition.

“11.) Able to run dedicated applications, can work as a an application processor or a general purpose system. (Used in SOHO/SME routers and switches)”

Similar to one of my approaches so we’re both on same page here. More versatile it is, the better ROI and higher chance of success.

“12.) A coherent IPC architecture, this requires some work as with these types of systems the use of DMA, MMU, and tagging is antithetical to a high performance inter-process communications component (in hardware. I’ve seen it done before.”

I agree. It’s tricky and very dependent on exact type of system so I can’t help directly here. You have more experience in such things than me anyway. Although, the MIT Alewife machine I posted here in past was a DSM machine with integrated message passing. I wasn’t sure if it would be important so I bookmarked it thinking it had tricks that might be useful later. Who knows, might get your creative juices going on this tough problem.

“13. A method to insure post boot is non-reentrant–i.e. the firmware has a mutated relationship to virtual memory (this is a challenge with multiple cores)”

Interesting.

“Not really comfortable with using the same architecture for the distribution layer (i.e. network) and other general purpose applications. Though if the development, fab, production, and API process is robust their may not be a reason to to take advantage of the re-use opportunity.”

Do your architecture right, you can definitely reuse it. What would be different for sure is the programming model. I’d look at existing high-end network processors to see how they’re doing things. Then, I’d see if I could implement a variant of that on a general-purpose machine. Of course, you could always design your general purpose chips to allow accelerator chips to be linked in.

Nick P • April 6, 2014 5:28 PM

@ name.withheld

“Most high end network gear achieve performance by providing an asynchronous hardware architecture where ASIC/FPGA DSP’s perform the I/O labor and GPU’s used for the logical glue and transport functions. ”

Interesting. Check this one out. That was what I discovered when seeing what MIPS tech was up to lately. Those kind of specs and features used to only be in a SGI Origin or Onyx machine. Anyway, my takeaway from Cavium was that multiple MIPS cores with app accelerators and good IO fabric could handle plenty network processing. Several secure architectures also use RISC cores, with CHERI being 64-bit MIPS. So, a future homebrew network processor might use several of those combined with a high throughput IO system, open accelerator cores, and maybe FPGA logic on the side just for swappable accelerators.

” I am interested in a scatter/gather methodology–almost a radar sort of system–where the network transport functions are treated as detection side of the source beacon. There’s some logic behind this and it has to do with heuristic modeling–adding some behavioral intelligence to traffic management. QoS just doesn’t work, hysteresis becomes the limiting factor and is bound by the use of classes of traffic (functional) instead of the “behavioral” aspects of traffic. ”

Interesting. I probably wouldn’t understand the theory too much. Do post prototypes if you ever get them working, esp with comparisons to existing tech.

“After reading my paper he asked if he could have a copy–I said no. At the time I didn’t realize that England had a silicon fein.”

The head of GCHQ wanted your paper and you said No. Most surprising part of the story. Do you regret that?

Nick P • April 7, 2014 8:04 PM

Speaking of backdoors, I got curious about which companies evaluated their product’s security under Common Criteria EAL1. It’s the standard that says “Screw it, let’s just give the attackers a blank check!” First one I found:

http://www.lancope.com/company-overview/press-releases/common-criteria/

Their quotes are quite hilarious when one understands what an EAL1 evaluation means vs others. I hope that they chose it just to get government sales without spending much on evaluation. Might also be a joke mocking CC. I was going to EAL1-evaluate an ultra-secure product for the latter reason, with a private (cost effective) evaluation determining real security. I also thought about getting a EAL1 cert for version 1, then EAL7 for version 2, and then claiming the largest increase in security by any vendor in history.

I don’t know. I just think it’s funny there’s a bunch of vendors compliant with EAL1 talking about how secure they are. Many were data protection systems, too. Haha.