Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Yes, actually. Heck, the very limited PDP-1 was a capability machine of sorts. Most microcontrollers run circles around it. The simplest of the new schemes check small tags with hardware that runs in parallel to the processor. Essentially, the processor executes the instruction and the result is not written unless parallel unit says "All good." This should have little performance, latency, and chip area overhead. I'm not saying every microcontroller of every cost and such can be done this way: probably just mid- to high-end microcontrollers will be secure by design.

Also, there's long been chips design to run languages that are type- or memory-safe by design. Sandia Labs recently made a high assurance processor for a Java subset: the Sandia Secure Processor (SSP) or "Score" processor. It doesn't allow new code in production mode, resists all kinds of errors, has assured tool sets, has a converter from legacy Java to its, speaks JVM natively with associated benefits, uses asynchronous interrupts for determinism, and is fabbed in a rad-hard process. They aimed at safety & assurance over throughput so the specs are 25Mhz from 35,000 logic gates (110K with memory). Their ASSET framework and its high assurance design also led to amazing feet of 3 weeks from synthesis to working ASIC with no timing errors. They said similar projects normally take 6 to 18 months (!!!).

In closing, the above is evidence embedded can benefit. Yet, two in embedded just popped into my mind: CodeSEAL and smartcards. CodeSEAL combines custom hardware with a processor to (a) encrypt and hash memory pages to stop leaks or attacks outside SOC; (b) control flow whitelist produced by compiler to block all attempts to hijack it. MicroSEMI sells this commercially. Other one is smartcards: microcontrollers with strongly assured hardware, firmware, VM's, and so on for small prices. I should've thought of them first because they kind of answer the whole question, don't they?

Guess it doesn't hurt to spread more info on high assurance security tech. ;)



Thanks! Very interesting, especially the sandia rapid development tool.Could be really useful in creating low-cost mcu's.

I've looked through a few of the examples, and they are useful, but they require a different toolset from what real-time engineers use(JVM/CodeSEAL), and you probably need to certify your code in order to get eal6+ for your system. All those are big barriers for penetration, which probably creates less incentive for mcu companies to develop eal6+ mcu's with rich peripherials which will appeal to the market.

Do you see a way out of this ? maybe using rust(or some other language), an eal6+ certified RTOS and an eal6+ mcu , would enable people creating secure real-time systems without need of certification?


The toolset differences are a huge barrier to market penetration. It's why technically superior, but architecturally different, products of the past were ignored to our loss. Itanium, with its advanced security, is a recent example. Not all are like that, though. There are a number that just protect pointers, do segments, do address space protection (see INTEGRITY-178B), or vary the granularity of the protection for legacy compatibility. These tend to support a modified UNIX/Linux kernel and/or GCC modifications. Things are otherwise the same. So, there's potential in those.

I found the following looking into embedded use and what works with similar tools. This tagging scheme [1] integrates with RTEMS and C albeit with more complexity than some. The guarded pointers [2] from mid-90's probably would work well with microcontrollers given embedded code is often fairly static, esp safety-critical schemes. The critiques shouldn't apply as much except cost of extra bits. The SAFE architecture's PUMP [3] does arbitrary policies with costs that might put it outside of microcontroller range (high end? mid-range?). One can even use the old Burrough's model where 2 tags bits per word are used to ID pointers and code. Writes to either generate an interrupt for security system to approve based on context. Again, embedded is static enough that there should be no such interrupts in normal operation if pointer-arithmetic is avoided, right?

Feel free to give your thoughts on these in terms of microcontrollers or low-cost microprocessors.

[1] http://www.uidaho.edu/~/media/Files/orgs/ENGR/Research/CSDS/...

[2] https://www.cs.utexas.edu/users/skeckler/pubs/asplos94.pdf

[3] http://www.crash-safe.org/assets/PUMP-ASPLOS-2015.pdf


Thanks.

The guarded pointers look great , and both them and the Burrough model could work well for micro-controllers, and suffer a relatively small penatly. The SAFE-PUMP would probably need a relatively new manufacturing process to make economical sense for medium-end microcontroller or would be fitting for a high-end microcontroller.

>> Again, embedded is static enough that there should be no such interrupts in normal operation if pointer-arithmetic is avoided, right?

I think when calling a function and pushing stuff into the stack ,you'll need such interrupts, and maybe in other situations.I'm no sure though, i'm just an hobbyist in embedded, but pretty interested in the industry - and the tension between the fact that everybody says internet-of-things-security is a big issue with no solution and on the other hand ,the availability highly secure research and working systems.

Anyway, thanks again for your help!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: