Schneier on Security

Nick P • May 3, 2014 12:12 PM

@ Clive Robinson

That’s pretty cool. I left a comment on the web site.

Nick P • May 4, 2014 2:33 PM

@ Figureitout

I already told you what you need to do to solve this problem. Just save up money and do a version of it. Will save you plenty of stress.

Just remember to have another person buy it for you. Not one at your school, but maybe at the church. Just say someone has been messing with your mail, you dont trust a package sitting at your door unattended, and even Post Office Box wont allow electronics. Offer to compensate them a bit. Project a semi defeated, yet determined, attitude.

Someone will pity you and help. Also remember to tell them to call yiu in a time range where you can leave instantly. Gives an opponent a tiny window of time too impactical to work with. Also, dont bring your phone on the trips to set this up or have batteries out. Better to use an old car or bicycle to avoid OnStar, etc.

Nick P • May 4, 2014 11:20 PM

Are simple, safe languages the answer to security woes?

Simple is actually dangerous. As an old essay argued, focusing on simplicity over other things led to security disasters such as UNIX & C. This is not to say simplicity is bad: it’s just one of many attributes that concern security. The goal we should seek is “simpler.” High assurance engineering has taught us such systems must be modular, have good interfaces, be thoroughly tested, be thoroughly reviewed by qualified people, and be implemented in a way that facilitates review. Plenty of simplification was often used to accomplish this. Yet, minimal isn’t always better for developers that will end up building on it later.

Specifically, a simple & secure interface that average developers can use (esp with management pressures) might need to be fairly complex underneath. Bernstein et al’s Ethos project gives us an example of this concept at the OS level. Their constructions greatly simplify life for application developer, while internally being quite complex compared to what some would push focusing on simplicity. The complexity is intrinsic to the work to be done. Sacrificing the complexity for simplicity just means that those same developers would create ad hoc versions of this for themselves that were very insecure. Matter of fact, this is the status quo.

The language, tools, hardware, OS, etc all need to present a good baseline to build on. The baseline should be simple enough to understand & use in an effective, safe way. If this complicates its implementation, so be it. Designers should just use the best systems engineering practices they can to break it into manageable pieces. High assurance model suggest keeping each component comprehensible, easily validated, and written in safe way. Each interaction is treated similarly. This concept allows us to securely compose things we understand piece by piece, abstraction by abstraction, into an effective system that’s also easy to use safely/securely. That last point is ultra-important as a failure there will cause the system to be ignored or abused by its own potential users.

My model for developing a better language

I’d start with existing languages used to solve the problems. I’d look at languages such as C#, Java, Python, etc. that have type safety, productivity boosting features, & widespread use. I’d look at how often each feature is used, what effects it has on comprehensibility/safety, and so on. I’d trim out anything that rates negative on this list. I could pick and choose every single feature I like from primitives (eg typesafe function pointers) to syntatic sugar (eg foreach). I’d consider LISP-style macro’s because it’s a new language & why the hell not. 😉 The list would include features from non-mainstream languages that are advantageous. This list becomes the upper limit of what the language can become in terms of features.

The next component is the lowest layer. I’d look at ISA’s, VM’s, etc I’d look for a representation that can effeciently map to existing hardware, possibly be implemented more directly in future, is easy to analyze, enforces optional safety checks on operations, and so on. This layer is the target of any other languages. It might also be callable directly in a high level language for performance or some other justifiable reason. This layer will also be safe by default for that reason. As P-code exemplified, it will likely be easier to port to new architectures and platforms than a full language + compiler.

The next component is a core subset of the language. This is just enough of the language to efficiently implement an arbitrary program, esp itself. This is akin to VLISP’s PreScheme, Stackless’s RPython, or Wirth’s Oberon, with or without garbage collection. This language must be expressive, efficient, and safe enough to write applications, compilers, OS’s, drivers, etc with runtime parameters tweakable for use case. It will have a bulletproof compiler a la CompCert. As such, it will have many uses the more promising of which is a compiler target from other languages, including initially the extended version of itself. It’s a good way to bootstrap it, even easier if macros are included.

The next component is the full language. The full language will have mandatory and optional constructs. Constructing it is the point of this post. I suggest that we construct it gradually. The core language is first level, giving user enough useful functions for anything with easy learning. Level 2 constructs are extra functions that real-world programmers use 80+% of the time to get more done than a Level 1 language user. Level 3 are the rest that are nice-to-have for certain situations, but totally optional. Tools might be developed to downgrade each level into a lower level with comments & functionality intact. Additionally, coding guidelines and build environments might enforce a given level to be used.

So, how big should we make the full language? Size hurts understanding. We can always expand software using libraries. We also know that certain langauge features make writing software so much easier, resulting in software that is itself more understandable. So, what’s the right tradeoff? My wild guess is that Level 1 should be as easy as a Wirth language, Level 2 shouldn’t take more than 50-100 pages of a SAMS Teach Yourself book to explain extra features, and Level 3 shouldn’t take more than 100-250 pages on top of that. If it goes past a certain point, the complexity is too high and the designers must start pushing features into libraries to lower complexity.

As a sidenote, Wirth’s heuristic was how easy was it to compile. This should be factored in to some degree. However, easier to write, read, extend, & validate are much more important. Plus, we can always do a IDE that deals with this problem. For example, many modern IDE’s can compile a module in the background right after you finish changing it. The scripting languages run changes pretty much instantly. LISP has incremental, function-level compilation that took milliseconds on single-core machine. All in all, I think compilation speed should only be a metric as far as “Let’s avoid anything causing compiles to get in way of developer’s flow during their normal develop-run-modify process.” The compilation of production version might take considerably longer as it might employ many extra checks & run on a dedicated machine/cluster.

All of the above components will be developed simultaneously. The L4.Verified experience (and others in high assurance) showed that it’s invaluable to have people working on very different aspects working in parallel with good communication. In short, all kinds of issues are caught & improvements made early on. I’m extending this to say that the language should be developed, implemented, documented, AND used all at the same time. There should be periodic acceptance tests where ordinary developers are trained on a given version & try to use it in various projects to provide feedback on what to expect upon widespread use. Doing all this at once, while maintaining consistency, will knock out so many problems other language teams might wonder why they didn’t do it themselves.

That’s my take on it. One shouldn’t take simplicity too far. I think Wirth might and Moore (i.e. Forth) definitely does. On other end, LISP showed how the basic mechanisms can be fairly simple, safer than average, and extremely powerful at same time. Python is a watered down LISP designed for readibility & practical use (“batteries included”) with incredible results so far in uptake, productivity & defect rate of average programmer. Yet, I wouldn’t call the combo of language & standard library (must exist as whole) simple. So, I’m aiming for something like Python that can be used in areas where C/C++/C#/Java are more typical & done within framework I described above. I think the scheme has potential to improve developer experience & system safety, while removing many risks across the entire lifecycle that exist in mainstream approaches.

Nick P • May 5, 2014 4:13 PM

@ yesme

“No. That is incorrect. C and UNIX were designed with being as close as possible to assembly in mind. In C you could do multiple things in one line of code, incl. pointer arithmethic.”

That’s commonly told, but inaccurate. The designers of UNIX laid out their philosophy in various papers and interviews. Although UNIX philosophy had plenty good points, their putting simplicity & efficiency higher than anything else had a huge, negative impact on resulting architecture. Any problem that undermined simplicity was pushed on developers & users. Best examples in C were array/buffer issues & null-terminated strings. Each was done to simplify implementation on machines with limited resources & no concept of safety.

First example in UNIX that comes to mind is interrupts. Some OS’s saved almost all internal state before dealing with interrupt, preserving a running process’s integrity. UNIX, for simplicity, saved almost none of it & just let app designer handle issue. Imagine that: having to design interrupt handling into every part of your application because OS was too ‘simple’ to do it for you. Others are listed in the classic UNIX Hater’s Handbook.

So, yes, simplicity was both their solution to porting their language/OS to many machines efficiently AND the problem that led to many safety/security/maintenance issues in UNIX architectures. UNIX shows too much simplicity is a bad thing. There’s a limit to how simple an effective system can be. Wirth made better tradeoffs in his systems which were also portable and reasonably efficient. Burroughs B5000 hardware and OS weren’t simple, yet making safe applications was because of this. The lesson, as in Worse is Better essay, is that the interface simplicity is more important than implementation simplicity. Because we write the code once, then use it many times.

“I still firmly believe that a simple language, that is designed with good readability, typesafety, rangechecks, GC, modularity and namespacing (I don’t mention OOP!) is a quite good answer to implement safe software.”

That’s consistent with my above principle. A language like you described provides a safe interface with or abstraction for the underlying hardware.

“For the GUI or other end user stuff, use interpreted languages without types or something like QML.”

Or Visual Basic 6. 😉 That the GUI language can be different than main system language is a good point. I note that the E6-evaluated CA for electronic money wrote the GUI in C++ for target platform & wrote security-critical code in Ada. That they interacted well supported the effort. Likewise, starting with my framework, someone might make langauges for prototyping, GUI’s, etc that interoperate well with main language.

“Simple languages do have their drawbacks. One of them is that sometimes it takes a couple of lines to write what you can do in one line in a more enhanced language. So be it. I write this story of probably 30+ lines without any pain.”

Modern software engineering best practice is to focus on how easy something is to read and maintain than write. Python focuses on former, Perl focuses on the later. Which do you think leads to more robust code? Adding a little complexity to the language can go a long way in reducing complexity of application. Can’t add too much, though. Common mistake in mainstream.

@ Anura

“If something new is going to be designed, I think one goal should be to make portability as easy as possible.”

I’m actually battling with myself on that one. Tight integration with a good architecture is what Wirth, high ass. security, & formal methodists taught me. Making one size fits all usually just leads to something that’s far from safe, secure or efficient. Yet, portability has its own benefits that I know you’re aware of. So, will I make it portable? Or portable in a limited way? Or ignore portability? Decisions, decisions.

“Java has a VM which is good for portability, but there is definitely some overhead. ”

Java has faux portability. The platform is just too heavy. If you’re interested in portability, look at the P-code system. Pascal was hardly used before Wirth wrote that layer. Then, it got ported to over 70 architectures. That’s pretty amazing considering how different architectures were back then. Modern architectures are much more consistent with each other, meaning it would be easier today. I also usually tell people to look at Apache runtime or Mozilla’s portability layer for clues at to how to handle various issues. Both do a good job.

“There should be both a textual and binary representations. ”

I disagree for now. Binary is a circumstance. It should be handled by tools. Prior work showed a low-level textual representation can meet all my requirements. Might use a binary format like XDR for storage or transmission, though. That the programmer doesn’t directly work with binary remains my rule.

“Then instead of distributing binaries targeted at specific ISA/OS, you distribute IL binaries that then get compiled to native code at install times (which is much faster than building from source, while also allow closed-source companies to adopt it). ”

This is a good idea. A superior (imho) form of this was invented in the Juice project. Juice attempted to replace Java applets with Oberon applets. Bandwidth was limited then & there were safety concerns. Solution was to convert Oberon programs to abstract syntax tree, then send that to browser which compiled (and typechecked it) on the spot. Result was the user wouldn’t experience a visible delay, program ran at full speed as native code, AST was more bandwith efficient than full source, & AST could be compressed before transmission. The project failed in the end for same reasons all good designs seem to fail. Yet, there’s a lot of good wisdom in that effort that we shouldn’t forget.

Note: The typed assembler and proof-carrying code fields have maintained some of the benefits you describe with properties I desire while taking code all the way to assembler. So, even AST might be far from optimal & we just can’t see it yet. However, I think an AST for a relatively simple language is a nice tradeoff for size, analyzability (safety), and performance.

@ Clive Robinson

Long story short, you’ve just discovered the joys of functional programming and are promoting it. 😛 Most of what you mention is consistent with my framework. I say this as the functional languages such Haskell compile to more imperative abstract machines, which are typically converted to machine code too. The abstract machines can be implemented by hardware microcode, the low level intermediate language, or the core imperative language. So, if anything, the kind of solution you describe could be compiled onto what I describe and/or co-exist with it.

The SAFE architecture team are doing something like this with SAFE instruction set, TEMPEST language for system programming, and BREEZE language for application programming. ‘Right tool for each job’ tends to be a good philosohy. Hard for me to see functional programming doing it all as well as a combo of it and imperative languages. Of course, they’re inventing each from scratch so it’s hard to say if they’re being wise or not. We’ll have to wait and see.

“Part of thi is you just can not “pick up” functional programing “as you go along” you realy need to go back and almost learn to program again”

That’s entirely true. I’m specifically focusing on imperative languages as it will be easy to teach average programmer. The results with Oberon family are a good example. A language that performs well, is easy to use, and is safer from ground up is best bet. Functional programming isn’t. It’s better for another project targeted at people that will put in the effort. The success of Erlang is encouraging on that subject.

“Pascal alowed it by having a clearly defind API that allowed not just assembler but any other language that conformed to the API to be linked in at run time. The use of P-Code or other bytecode interpreter alows for both methods in a more structured and code level/type sensitive way.”

I agree. My framework mimicks that while being careful to dodge it’s problems. Well, at an abstract level as many of the problems depend on implementation decisions.

“how do you deal with errors, exceptions, signals, interfacing etc.”

All of that should be carefully decided. I’ve seen too many problems arising from language or platform designers pushing that stuff on developers. However, I am in favor of offering several solutions that are decided with a compile time switch, with safest/best general option being default.

” Thus the design of the bytecode interpreter is going to either be “a jack of all trades” to alow for all likely underlying CPU types or it’s going to be taylored to a specific class of CPU with specific issues around memory addressing…”

That’s a good point. Of course, my framework talks about designing hardware, runtime, and core language hand-in-hand for consistency. Another quick point is that there doesn’t have to be one runtime: there can be several for different classes of machines with their own compile and run time strategies. As I’ll focus on best option, I think it’s likely there will be two runtimes’s: one that I make that’s close to ideal; one for the most popular, legacy machine. Knowing this is also why my research deals with safe ground up and safer legacy systems in parallel.

“In fact some types of system such as those with “Real Time” response requirments just cannot be done in anything other than an imperative manner.”

The Lustre and Functional Reactive Programming people would scowl at you for that. 😉 This paper (2001) provides a nice survey of the functional efforts at real-time & different issues. I also just found this gem that focuses on FP in embedded space applications. Like I speculated above, they basically just implemented an abstract machine in an efficient language (Forth) and then targeted Haskell to it.

Random musing:

My research into hardware development languages showed me that the key difference is that they’re inherently concurrent. The typical assumption is that each component in hardware is always running. So, one must avoid concurrency issues at every turn. Software has been mostly sequential. The software designers are now trying to learn concurrency. I find it amusing that hardware people worked so hard to make their concurrent designs pretend to be [mostly] sequential machines for programmers that are now trying to squeeze effective concurrency out of those same sequential machines. “You’re Doing It Wrong” seems like an understatement here. 🙂

@ name.withheld

” the trick is to match the tool to the task.”

Or design the right tools for the right tasks, as in my essay. A very tricky part to get right without spilling over from reason to religion it seems.

” And, writing a web server in ASM is not practical. ”

But it only takes 98 lines. 😛 I’ve also seen one that uses only 30 bytes of RAM to handle a connection. I’ll agree they aren’t practical, though, although first was deployed in a backdoor application. Of course, Menuet and Kolibri OS people wrote their whole system in assembler. I digress though…

” Personnally, to reduce the level of obscurity (and there are arguments against this) writing to the platform at the lowest level is a possible choice I prefer–but don’t expect.”

It’s a good decision. It boosts efficiency & reduces likelihood of problems between abstraction gaps. It’s why I’m including something at that layer in my framework.

” For example, I’m a big fan of VHDL or Verilog only designs for applications targeted in hardware. Comes from not trusting the toolchain. ASM is preferred for any realtime application. And HLL are for the “presentation” layer of an application in most cases–though I’ve written user interfaces that were extensible in ASM.”

Seems reasonable. I’m trying to give you better tools to work with using my framework. Yet, if you avoid existing one’s for assembler in embedded apps I could understand. And I’m glad you mentioned VHDL instead of just Verilog. 🙂

“I don’t understand the resistance to macro assemblers–as far as I am concerned it represents the same lexical layer above the object emitter in the classic compliation toolchain. ”

I believe the earliest effort here was Dijkstra (?) writing one for IBM System/360. The nature of the assembler led to people producing unmaintainable garbage. The “high level” assembler made it so much easier to write more maintainable code, yet still efficient, that it took off and became a standard offering for IBM. Btw, looking for the reference to this claim I found this excellent presentation on problems of typical assembler and benefits of high-level/macro assembler. Thought you’d enjoy it, maybe even copying some of it for your use. I’m definitely adding it to what Clive calls my “link farm” lol.

“In summary I am with Nick P on providing guidance across a set of application frameworks (hardware, OS, appliations, etc.). Tying your hands on purposes should have some benefits–that’s what they told me school.”

I appreciate your peer review & positive comment. I particularly hoped people such as you and Clive with experience at all layers would weigh in. Many application programmers might comment based on experience with one layer, while having no idea how badly their decision will affect other layers. Or their own when it interfaces to the others. Robustness in general seems to be a holistic thing. I regret I spent so much time focusing only on the software side as I might have built a safe machine by now had I known to work in & integrate all layers. Foolishness of youth. 😉

Nick P • May 5, 2014 4:58 PM

@ Anura

That makes sense. I see a few possibilities:

ASN.1. It’s made for syntax encoding, has a binary variant, saw plenty use in field, and was implemented using high assurance techniques by Galois.

XDR. It’s binary, supports key data types, efficient, and worked in the field.

Protocol buffers or serialization. Essentially, create a way to produce encoders & decoders for arbitrary data types in the language. The end result can be binary.

With any of these, I’d customize the supported types and encoding stategies to the source language & target platforms.

Nick P • May 5, 2014 9:31 PM

EDIT TO ADD:

Asynchronous Component-Based Programming 2001 Morrison
http://www.jpaulmorrison.com/fbp/2001paper.htm

Flow-based programming continues to interest me. I’d like to see more work at safety and security analysis of FBP approaches. Might be some good outcomes in robustness.

Nick P • May 6, 2014 2:45 PM

@ name.withheld

I looked at SystemC again. It’s definitely interesting for prototyping. In the process, I found this tool while I was looking it up. Btw, if you like Occam, check out this OS written in Occam.

The framework is interesting. The use of VHDL surprises me. I’m guessing this framework is about hardware rather than software design? Hard for me to imagine doing software effectively in VHDL. The Flow-based Programming scheme I linked to above is the closest thing to that. It seems that integrating that software scheme with a hardware language might produce some interesting results. I particularly think it might help in hardware/software codesign like the kind people do with FPGA accelerators in eg Mitrion-C. Making software more easily map to hardware avoids many problems in imperative programming.

Re control theory

Thanks for Adaptive Control Theory reference. I’ll look into that.

@ Wael

“The desertation title is “Software failure avoidance using discrete control theory”, but the main focus was deadlocks (the second problem). Then at the end of the presentation, in the discussion section, a question is asked: To what extent can tools, e.g., testing, static analysis, runtime analysis, and control synthesis, help eliminate software bugs?”

I know paper focuses on deadlock & askes a BS question at the end. Point of me bringing it up was to see what guys with embedded experience think about applying Discrete Control Theory (esp validation & synthesis) into software to more easily make it robust. Any potential for you see in that or is it a waste of time?

re rest of it

LOL. Reminds me of this old joke.

@ Clive Robinson

I knew who it was immediately because the page loaded & the tab had his name in it. So much for the surprise… (rolls eyes)

The first few paragraphs about made me want to reach across the Atlantic, slap him, and say “Get to the point!” The points he makes are a mix of possibly sound & otherwise just looking for ways to bash America. I wish he’d leave out the latter as I’m genuinely interested in comparing and contrasting various nationalities’ approach to software. So, I’ll comment on the points he made:

• the Buxton Index explaining differences & allowing better communication.

Not sure how that works. A person’s goals, personality, social skills, & working style has more influence on this than anything. How far ahead we look is miniscule in comparison. Making some rules about the work environment (or project or whatever) that lets diversity work for rather than against the effort is quite beneficial. The rule about honesty & clarity he had, for example, is a good one.

• NSF funds work with short term focus

I think he’s right about that with the funding, yet wrong about the result. We do know open-ended, long-term, fundamental research into fields will typically produce the biggest breakthroughs. Yet, most useful R&D results are a series of gradual improvements to existing work. Many of the papers I’ve posted here were NSF funded so it shows the organization is producing results. Also, long-term work still happens but it’s broken into several short-term efforts with associate deliverables. Whether that is good or not is debatable. Yet, even Karger said in high assurance work it’s best to ensure it keeps producing intermediate deliverables with value to justify ongoing investment into long-term work. That was a rule for commercial projects, though.

I’d be interested in knowing how European countries and companies handle R&D in comparison. Oh and one more point: NSF isn’t only game around. Lots of governments, nonprofits, and for-profit companies fund research that’s not expected to have an immediate payoff. Dare I say certain Universities’ Comp Sci R&D has more of that than the other kind.

• scientists in America being considered eggheads and getting less respect

That doesn’t happen in European countries? People don’t think of techies as nerds or dispute what they say for political reasons? If so, then this is a true difference. However, the author is a little off in that this effect depends on the area. Different locations in US have different levels of respect for and trust in science. I mean, look how many scientists that are funded in this country. We do tons of science, honest and fraudulent, useful and moronic. We’re flexible. 🙂 Yet, the public is quite detached from it.

Maybe it’s because science is wrong so much & Americans expect them to get answers right. Maybe American’s just don’t identify with it, hence treating it like a separate social class. Who knows. There is an effect like he described in most of the country, though. I suspect our poor educational system combined with incentives of our economic system are the biggest culprits. Little motivation to push reason, science and honesty when it pays of in so many ways to do the other things.

• Europe is Platonic, USA/Canada more pragmatic

We’re definitely pragmatic as a whole, with sprinkles of Platonic. I’m not sure how Europe is or if it varies by country.

• Compsci tied to math departments; soft sciences having little respect

Those are definitely differences. There are empirical ways to handle soft sciences to a degree so they are sciences in that respect. If anything, this difference risks Europeans getting left behind in those fields if prejudice prevents innovations. I’ve seen (and used) plenty of interesting results from soft sciences. I’d love Europeans to put more effort as diverse perspectives are very important to the soft sciences.

• gripe at ‘integralism’

It almost seems like the claim could be leveled directly at me & my security critiques here. 😉 I see the value of the method he pushes. Yet, in our field, context & integration are utterly important to achieving the goals. If anything, they’re where some of the worst problems happen. Not properly anticipating them while focusing on one aspect can lead to trouble. That said, being able to do razor sharp focus on one aspect of a design in isolation is quite useful. There’s a balance here that’s hard for me to articulate. I’d have to think more on it.

• universities focus on preparing for jobs leads to less innovation & reinforces bad habits

In America, Universities are seen as serving three functions: improving oneself; learning job skills to make more money; giving parents of teenagers at least 2-4 years of peace. That companies demand affects what is taught is often, but not always, true. Recall all the articles written in the US griping that you have to unlearn what you learn in college. If the author is correct, then that wouldn’t be as necessary as college would be preparing them for work.

In reality, it depends on the institution & instructor. There are some that directly tie their offerings to in demand job skills. An example is one community college nearby offers COBOL, RPG, etc courses as the biggest employers need those skills & that’s the only reason for it. Author hits nail on the head, here. Yet, at some other schools they teach engineering-style design methodologies, Scheme, etc. Totally opposite of industry. Our institutions also have done plenty of cutting edge work in languages, tools, software engineering, etc. They push the envelope every day whether industry wants a given innovation or not. So, if anything, the author once again tries to misrepresent American institutions as homogenous and inferior.

• American Comp Sci uses same language, publishers, manuals, etc

This seemed right when I first read it. Yet, we have to remember that the field over here is split among academic, hobbyists, and professionals existing in many areas. The different motivations & environments mean there’s all kinds of stuff out there. Look at ACM & IEEE those people are similar at least in how and where they present. The rest, from focus of work to skill to practicality, varies quite a bit. Much of our most successful language work came from hobbyists, not ACM/IEEE. And their documentation approaches aren’t similar. Overall, this claim of his is false.

See a pattern emerge? Have you figured out why he keeps getting it wrong? I’m going to shortcut to the answer: he falsely assumes computer science in US is homogenous. It’s not. Our culture causes plenty of diversity, dare I say more so than in Europe. In a company or organization, conformity is often expected. In hobbies or marketplace, differentiators are preferred. I mean, there are certainly standards and traditions that many might conform to. Otherwise, they try to be different which results in the author’s homogenity-based claims falling apart. He’s intellectually trying to fit a round peg in a square hole because he desires to think of the peg as square.

• difficulty of programming & how it’s like math

He’s got some decent points on that. Yet, I don’t think we have to jump right to it being about math. It’s really about proper abstractions that map what’s in our head to what’s on a machine. The choice of language, tools, and engineering method solve these problems. I think the author has a strong math background and it’s making him see programming as a mathematical thing. I also think certain programming work, esp in tools & scientific computing, can benefit from a mathematical perspective or straight up are mathematical. Yet, the success of COBOL et al shows that lay people without a math background can write useful apps that work reasonably well. So, it being doable with almost no math knowledge would seem reinforce my point that one doesn’t inherently need the other far as coder is concerned.

Btw, his disdain for regular software developers reminds me of all your “code cutter” posts.

• John von Nuemann’s habit to describe systems & parts in anthropomorphic terminology; adopted in USA more than Europe.

I’m not sure what he’s talking about. I’d like some examples. Maybe when people say “this app talks to that one,” “remembers,” etc? OOP & agent-oriented programming might do this too albeit with benefits. Anyway, most developers I know & books I read talk about software like it’s something we produce that acts on data, does work, & interacts with user via an interface. That’s more mechanical than anthropomorphic.

Come to think of it, there is a trend to think of business systems as a sort of organic thing that evolves and adapts to a changing environment over time. It’s an interesting metaphor with some claimed benefits. Far as I know, it wasn’t prevalent in his time.

• to forget that program texts can be interpreted as executable code

That’s all we think about them, except for “code as data” people. I think he was just hanging around with some odd people. Or things were different back then.

• his trouble with LISP 1.5

That was HILARIOUS. It’s ironic he had so much trouble with a radical, academic language rooted in mathematics after he’s consistently implied Europeans would more easily learn non-standard or math-focused tech. Open mouth, insert foot.

• his recollection of ACM visit

Entertaining. Welcome to America haha.

• going through motions to please sponsor in America, not in Europe

This is a common thing in America. Sponsors don’t get courtesy/preferential treatment or say over direction of research in any European countries? That would be a major difference.

• Americans having a greater capacity for dishonesty and honesty

I’ll buy that claim just because it’s a logical outcome of of our Constitution, economic model and culture. You put them together, you can get this result.

END OF REVIEW

Overall, beside a seeming prejudice corrupting his analysis, my overall gripe is that he compares America to Europe. I think this is a bad idea. Continents don’t make software. Continents don’t write or review mathematical proofs. Continents don’t do about anything cohesively aside from stuff like NAFTA and EU. In our field, results are driven by individuals and groups. The proper comparison is between them, not countries or continents.

I’ll illustrate that with a few groups in US and UK. Microsoft throws garbage together, ships it, and uses lock-in to keep making money. For a long time, they used monolithic architectures with poor reliability & security traits with little code inspection. On other side, Green Hills developed software and tools with a strong focus on good architecture (eg microkernel), low defects, and so on. In UK, Micro Focus uses regular software practices to construct IDE’s that ensure your beloved code cutters can keep writing more COBOL (!) with predictable quality. On other end, Altran Praxis uses their “Correct by Construction” process to develop very low defect systems in many safety-critical industries.

So, it varies group by group, company by company, agency by agency. It’s really about the group’s goals, work ethic, tools, and attention to quality. These combine to separate the good IT from the bad IT. The country they’re located in? If it has an effect, I’m just guessing it’s minimal compared to the others I listed. That’s just a guess though. I’m sure norms, cultures, and laws can create an environment that directly impacts software quality. I just have little hard data connecting these for European countries. Ours is individualistic, largely profit motivated, and has little to no liability so the quality is quite predictable. 🙁

Nick P • May 7, 2014 12:06 PM

@ Wael

re Discrete Control Theory

That’s exactly the kind of intuitive response I was looking for. Thanks.

re concurrency

I’ve seen both processors and languages (ParaSail) that make the stuff easy while still allowing HLL languages or existing toolsets. So, we might not have to go entirely GPU on it. Plus, far as crypto goes, it’s usually one of the fastest components in a system with others slowing things down. Fast primitives (eg Bernstein) or hardware acceleration of key primitives seems to suffice for it. It’s why I’ve always loved the concept of FPGA logic in chip or FPGA’s on the board. Just push off anything that needs acceleration to them while using the same SOC’s or board gives volume pricing.

@ Clive Robinson

“As you have noted much has changed in that time in Europe. But if you think back to your own comments on how researchers are these days continuously reinventing the wheel over security that has done and dusted by the mid 1970s you might want to think if the authors perspective about the different research types is valid or not, and if not why not…”

It might have been correct back then. I wasn’t in Comp Sci in 70’s so I can’t really speak to it.

“Some years ago a new design of architecture was proposed called Transport Triggered Architecture (TTA) [1] which exposed the internal data transport busses of the CPU to “the programer”. ”

This is interesting in that I was recently looking a high-level microcoding as a solution to one problem. More on that later.

“The TTA CPU design is used but mainly in “Application Processors” but it’s design started me thinking on it’s security issues and how you could expand the design in a more “programmer friendly” way.”

The pages I read on it note that it sucks for interrupts, preemptive threads, context switches and so on. My & DARPA’s designs knock out two of these but others remain. There’s also the issue that the programmer has to worry about timing of everything. Would be great for covert channel analysis, a pain in the ass for… everything else. 😉

So, on to what I’ve been thinking about lately. The problems of the systems, esp causes of code injection, are well-known. I’ve posted many architectures & chips that prevent many by good hardware design. The trick is who wants to screw with several dozen full hardware projects at once? Additionally, for projects leveraging abstract machines (eg M-code, JVM), it’s a new hardware project per language. Yet, I’ve seen two potential shortcuts: microcode & PALcode.

Microcode is the most obvious. Many of these CISC, safe, etc processors are actually typical data throwing machines underneath maybe with a few dedicated components (eg tagging unit). The microcode is used to effectively transform them into the other machine. Many changes to that machine can be done in microcode. So, it might be beneficial to just create a series of functional units that could emulate most of these processors, then make the microcode easier to write (tools or new languages). Then, people trying to improve & experiment with processors could start by microcoding existing hardware instead of learning everything about digital logic, etc. Speaking of myself, I thought the microcodes I’ve read were much more comprehensible than processor specs.

Similar idea with PALcode. Actually, you could say Alpha’s PALcode was an implementation of my idea in limited way. It effectively allowed programmer to define new instructions out of existing instructions. These also executed as atomic instructions, a capability that would have tremendous effects in concurrency. PALcode was instrumental in VAX Security Kernel project to get kernel to run with security & performance. A processor with something like PALcode, albeit with power closer to microcode, could be very useful in these efforts.

Another component might be high-speed scratchpad memory only microcode or PALcode can access. Reason for this is to emulate aspects that weren’t implemented in hardware yet. For example, the tagging engine might have state related to its job. If RISC core has no tag unit, then microcode or PALcode can emulate one with support of scratchpad memory which might store tags or access rules. Scratchpad is just one idea, as I’m quite open to whatever gives flexibility while maintaining performance.

So, to recap, the design effort must be kept minimal by continuously producing components that can be reused or extended elsewhere. The common functional units of processors will be created in HDL, of course. At least one RISC setup with components used 99+% of the time is integrated in HDL with microcoding and/or PALcode ability. That can, by itself, become any number of CPU’s, IO-CPU’s, or ASIP’s. Hardware existions can initially be implemented by VM’s partly written in microcode or PALcode, later written in HDL’s extending the hardware. There might also be FPGA cells connected to it for this purpose. And all of this is to be written in an HDL that supports open source and/or provably correct synthesis tool use.

@ yesme

Definitely interesting work. Btw, if you want modern, the proper one to look at is A2 Bluebottle. It’s the latest incarnation of the system.

The principles of Hoare & Wirth are certainly sound. One problem with Wirth, though, is that he’s more focused on making the compiler and language simple. That means that he’s more likely to leave off a great security feature & push the concern into application. That application designers can’t be trusted to ensure security is one of the reasons we’re discussing new hardware to begin with. So, certain critical features that support safety/security abstraction of developers must be implemented in hardware & always on. This increases complexity. So, as I said before, we can simplify things wherever possible but adding security will add complexity.

An example is Intel i432. They had plenty great features for making OS and app designer’s more productive, maintainable, and secure. Yet, they put so much stuff into it that it was only 25% as fast as competitors. Utterly failed in the market. So, there’s obviously a cutoff point for extra complexity. With i960MX, they transformed i432 by trimming off what fat they could. End result was a simpler, RISCy architecture that performed well & supported plenty key i432 features. Yet, it was more complex than competing RISC designs as it needed the extra capabilities.

So, in security engineering, we have to make tougher tradeoffs than those merely wanting speed or small compilers. We have to keep the machine easy to implement (HW), easy to manage (OS/runtime), and easy to develop on (apps/compiler). It’s tricky and the solutions aren’t always as simple as many would like. 😉

Nick P • May 8, 2014 11:36 AM

@ Clive Robinson

Thanks for the tips. Yes, all the timing issues are what I kept seeing in articles on the subject. It also appears synthesis tools are horrid for hardware compared to software. Article argued quite well why it was hard in general. I think better tools & hands on development of complex projects in academic are the only way new generations will even begin to catch up. Funny that there’s at least one IT sub-industry still dominated by the old folks. And that doesn’t involve COBOL. 😉

re Harvard

A truly pure-Harvard design seems to avoid certain problems. Yet, I’m not convinced it’s even necessary given what I know of tagged and capability architectures. Many problems in software remained to be solved with a Harvard architecture. The solutions to many of these problems can also be used to protect code on a von Neumann machine. Harvard essentially creates two segments, code & data, with no further granularity. The machines like SAFE & CHERI can do so much more than that. Additionally, we’ve had so many exemplar von Neumann machines to build on & so few Harvard’s dare I guess that we’re more likely to screw up a secure Harvard architecture project.

Note: This is one of those topics that my opinion can change wildly day to day, month to month, and year to year.

re microprogramming & compilers

Good that you brought up compilers as it’s exactly what I was looking into yesterday. I found these gems that show microprogramming can not only be made easy: it can involve almost no microprogramming. 🙂

On the design of a microcode compiler for a machine-independent high-level language
http://www.computer.org/csdl/trans/ts/1981/03/01702839.pdf

A retargetable compiler for a high-level microprogramming language
http://ls12-www.cs.tu-dortmund.de/daes/media/documents/publications/downloads/1984-Sigmicro-15.pdf

High-level microprogramming – An optimising C compiler for a processing element of a CAD accelerator
http://digitalcommons.unl.edu/cgi/viewcontent.cgi?article=1070&context=csearticles

So, higher-level microprogramming certainly can be done. All these papers are old, too, so I’m sure modern tools could push envelope even further. Only question is “Would it be easily done in the kind of chip I described and for abstract machine implementation?” The chips [mostly] use common functional units and the abstract machines can be modeled as state machines. So, I don’t see [yet] what would prevent HLL microprogramming from being used there.

Nick P • May 8, 2014 9:05 PM

Recent attacks on a few anonymizing networks

Trawling for Tor Hidden Services – Detection, Measurement, and Deanonymization (2013) Biryukov et al
http://www.ieee-security.org/TC/SP2013/papers/4977a080.pdf

The Sniper Attack: Anonymously Deanonymizing and Disabling the Tor Network (2014) Jansen et al
http://www.robgjansen.com/publications/sniper-ndss2014.pdf

Practical attacks against the I2P network (2013) Egger et al
http://wwwcip.informatik.uni-erlangen.de/~spjsschl/i2p.pdf

Freenet always interested me more due to it being a distributed data store. However, I bet I’d have a paper on it too if it was getting attention from smart researchers like these. Usable & robust anonymity is just really hard to do.

Nick P • May 11, 2014 1:28 AM

@ Clive Robinson

” Unfortunatly this way of doing things often suffers from the “Apollo problem”, which means that instead of continuous improvment with time you get a burst of activity followed by a long period of inactivity which leaves technology in a culdersac for fourty years or more. ”

That is an interesting way of looking at it. I’m not sure it’s supported by evidence. Yet, there was a similar concept that focused on equilibriums, peaks, or something like that in ideas and adoptions. My memory fails me here. It said there were moments of improvements here and there, but otherwise not. It just wasn’t as extreme an example as Apollo program.

“The main disadvantage with BASIC was also it’s main advantage it was both interpreted and overly simple.”

Not slow due to interpretation. There’s BASIC’s specifically designed to compile to fast native code, even for game engines. That’s just what was common long ago and with more academic projects. Overly simple applies to many, yet there are BASIC’s that address that too. And there are some that address it WAY too much. 😉

“I suspect that the notion of paralellBASIC is not wrong, but it won’t be BASIC it will be a language that has pure functions supported by immutable variables otherwise concurancy and paralellism will be way to difficult to do either efficiently or effectivly, but it will have the “easy play” asspects of BASIC.”

Well, ParellelBASIC is a joke so it’s OK if it doesn’t make it. Yet, the easiness of BASIC is definitely its appeal. That’s why some are talking about Julia as a BASIC for scientific computing due to its combo of easy, performance, and legacy integration. Python is actually dominating that, though, as it’s been integrated with fast scientific libraries and extended with capability to create fast, native codes with Python subsets. Your guess is on the mark so far.

“My guess is concurancy will be above the CPU level of the computing stack for a whole heap of reasons, ”

I’ve seen a few processors that solved the concurrency problem in different ways. One accelerated message passing to make those models extra fast. One included a few changes that made multithreading more efficient and safe. Several essentially supported a form of transactions where a series of statements were executed as a whole without interference from other computations. Then, there was hardware such as i432 that even did scheduling at hardware level below OS. So, it certainly can be done in hardware.

Yet, I think it should be an OS thing with hardware only accelerating the primitives. Arguably, that was the case for the three designs. Goes to show hardware can have about as much effect as software in this.

“which is one of the reasons I was looking at less than microkernals in the C-v-P design with lightweight RISC CPUs with local scratch memory and arbitrated access to main memory being done via a hypervisor.”

And our designs are converging a bit. I’m playing with the hardware level now in my designs more than in the past. Yet, I’m still looking for “this provably can’t happen by good design” and on most critical aspects. So, you look at RISC CPU’s and hypervisors, I look at whatever CPU can track context of operations to prevent obviously bad ones and allow probably good ones. Tags, capabilities, etc can do a lot in that area. Still searching.

@ Wael

“This is the first BASIC computer I used . I bought a humongous 8K memory module with it, forgot for how much…. I still have it, sitting next to my Commodore 128. The Timex Sinclair and the Vic-20 disappeared…”

Your first was a portable. Nice. Mine was portable… after enough gym time and with assistance of a vehicle. 🙂

“We cannot short-cut evolution, I think. ”

I think the very existence of human brain has caused that plenty of times. We’re ahead of it in many ways, yet still behind it (or controlled by it) in critical ways. Whether I can get the human race or market in general to do this in a specific way is another issue. A harder issue.

You said an evolution is overdue. Something is certainly overdue. It’s going to be a revolution, though, as it will be radically different from status quo. I’ve mentioned many architectures that are largely evolutions of older one’s with excellent safety, security, or verification properties. Yet, compared to existing architectures, it’s like throwing out everything people know and do. That’s the kind of change that takes… it’s not easy to make happen in an overall market.

One would hope Snowden disclosures, pervasive malware threats, constant disruptions of availability, maintenance/integration woes in software, etc would do it. They largely haven’t. So, I’m not sure what discussions, tipping points, etc. would lead to such a change. I am quite pessimistic about what majority or even significant market share will take up in this field. Smart card, DO-178B, etc markets give me about the only glimmer of hope as they have real quality or security improvements. Meanwhile, I continue doing what I do on principle hoping one day it might benefit many in practice.

Great poem. Gotta wonder who the two boys were. And I heard “Steeeeeerike 2” in Leslie Neilson’s voice as a certain scene made it funnier that way.

Nick P • May 11, 2014 3:31 PM

@ yesme

What I want to do is help readers understand what properties a secure system will have. I also promote any project, technique, etc that can be used to build secure systems. I’m also exploring new designs that prevent code injection or data leaks from the hardware up, while supporting integration with COTS I/O devices & development in safer languages. I’ve been posting various architectures and shortcuts here to that effect.

I might not be able to build the systems any longer. My goal is to give others what they need to do it. If they want secure & democracy-preserving technology, I’ve told them plenty about how to build it & they just have to put in effort/sacrifices. I’ve done [and still doing] my part. Just waiting for it to take-off or an existing project to get production ready. Then, I’ll put a whole stack on it or [as usual] tell others how to do it right and simply so.

Systems I can trust that force surveillance states to work very hard are what I want. I developed them in the past. My old work isn’t available anymore past what I’ve posted here. I want to see myself or someone else do this again for the modern threat. And it get put into widespread use.

Nick P • May 12, 2014 11:14 AM

@ Wael

“Another possible large scale evolution is a system with millions of tiny processors that behave like a human brain. Not likely to witness either in my lifetime…”

Then, I guess this is a gift of a lifetime. You even have to understand brain function just to program it. 😉