https://www.reddit.com/r/linux/comments/3z9t7k/open_source_p...
https://www.reddit.com/r/opensource/comments/3z5ue8/open_sou...
I'm a cofounder of lowRISC, a not-for-profit working to produce a fully open source SoC implementing the RISC-V ISA, in volume silicon. If you have questions then fire away.
See http://danluu.com/integer-overflow/ for a quick and dirty benchmark (which shows a penalty of less than 1% for a randomly selected integer heavy workload, when using proper compiler support -- unfortunately, most people implement this incorrectly), or try it yourself.
People often overestimate the cost of overflow checking by running a microbenchmark that consists of a loop over some additions. You'll see a noticeable slowdown in that case, but it turns out there aren't many real workloads that closely resemble doing nothing but looping over addition, and the workloads with similar characteristics are mostly in code where people don't care about security anyway.
If you click through to the RISC-V mailing list linked to elsewhere in this discussion, you'll see that the C++17 standard library is planning on doing checked integer operations by default. If that's not a "performance focused language", I don't know what is.
Even if the performance penalty was nonexistent in reality, the fact is that people are making decisions which are bad for security because they perceive a problem, and adding integer overflow traps will fix it.
And the answer is that it there's a tradeoff. All of the no-brainer tradeoffs were picked clean decades ago, so all we're left with are the ones that aren't obvious wins. In general, if you look at a field an wonder why almost no one has done this super obvious thing for decades, maybe consider that it might be not so obvious after all. At zurn mentioned, there are actually a lot of places where you could get 5% and it doesn't seem worth it. I've worked at two software companies that are large enough to politely ask Intel for new features and instructions; checked overflow isn't even in the top 10 list of priorities, and possibly not even in the top 100.
In the thread you linked to, the penalty is observed to be between 1% and 5%, and even on integer heavy workloads, the penalty can be less than 1%, as demonstrated by the benchmark linked to above. Somehow, this has resulted in the question "If you could make your processor 5% faster ...". But you're not making your processor 5% faster across the board! That's a completely different question, even if you totally ignore the cost of adding the check, which you are.
To turn the question around, if people aren't willing to pay between 0% and 5% for the extra security provided, why should hardware manufacturers implement the feature? When I look at most code, there's not just a 5% penalty, but a one to two order of magnitude penalty over what could be done in the limit with proper optimization. People pay those penalties all the time because they think it's worth the tradeoff. And here, we're talking about a penalty that might be 1% or 2% on average (keep in mind that many workloads aren't integer heavy) that you don't think is worth paying. What makes you think that people would who don't care enough about security to pay that kind of performance penalty would pay extra for a microprocessor that gives has this fancy feature you want?
This is not true. One problem is that language implementations are imperfect and may have much higher overhead than necessary. An even bigger problem is that defaults matter. Most users of a language don't consider integer overflow at all. They trust the language designers to make the default decision for them. I believe that most people would certainly choose overflow checks if they had a perfect implementation available, and perfect knowledge of the security and reliability implications (i.e. knowledge of all the future bugs that would result from overflow in their code), and carefully considered it and weighed all the options, but they don't even think about it. And they shouldn't have to!
For a language designer, considerations are different. Default integer overflow checks will hurt their benchmark scores (especially early in development when these things are set in stone while the implementation is still unoptimized), and benchmarks influence language adoption. So they choose the fast way. Similarly with hardware designers like you. Everyone is locally making decisions which are good for them, but the overall outcome is bad.
> if people aren't willing to pay between 0% and 5% for
> the extra security provided
The current RFC seems to be https://github.com/rust-lang/rfcs/blob/master/text/0560-inte... which seems to avoid taking a stand on the performance issue.
1. Memory safety is Rust's number one priority, and if this were a memory safety concern then Rust's hands would be tied and it would be forced to use checked arithmetic just as it is forced to use checked indexing. However, due to a combination of all of Rust's other safety mechanisms, integer overflow can't result in memory unsafety (because if it could, then that would mean that there exists some integer value that can be used directly to cause memory unsafety, and that would be considered a bug that needs to be fixed anyway).
2. However, integer overflow is still obviously a significant cause of semantic errors, so checked ops are desirable due to helping assure the correctness of your programs. All else equal, having checked ops by default would be a good idea.
3. However however, performance is Rust's next highest priority after safety, and the results of using checked operations by default are maddeningly inconclusive. For some workloads they are no more than timing noise; for other workloads they can effectively halve performance due to causing cascading optimization failures in the backend. Accusations of faulty methodology are thrown around and the phrase "unrepresentative workload" has its day in the sun.
4. So ultimately a compromise is required, a new knob to fiddle with, as is so often the case with systems programming languages where there's nobody left to pass the buck to (and you at last empathize with how C++ got to be the way it is today). And there's a million different ways to design the knob (check only within this scope, check only when using this operator, check only when using this type, check only when using this compiler flag). In Rust's case, it already had a feature called "debug assertions" which are special assertions that can be toggled on and off with a compiler flag (and typically only enabled while debugging), so in lieu of adding any new features to the language it simply made arithmetic ops use debug assertions to check for overflow.
So in today's Rust, if you compile using Cargo, by default you will build a "debug" binary which enables checked arithmetic. If you pass Cargo the `--release` flag, in addition to turning on optimizations it will disable debug assertions and hence disable checked arithmetic. (Though as I say repeatedly elsewhere, Rust reserves the right to make arithmetic unconditionally checked in the future if someone can convincingly prove that their performance impact is small enough to tolerate.)
The check failures trigger a panic?
Is there any work to enable an ASan-like feature for unsafe blocks BTW?
There isn't as strong a need for ASan in Rust because so little code is unsafe. Most of the time, the only reason you drop down to unsafe code is because you're trying to do something compilers are bad at tracking (or that is a pain in the neck to encode to a compiler). It's usually quite well-contained, as well.
You can work with uninit memory, allocating and freeing memory, and index into arrays in Safe Rust without concern already (with everything but indexing statically validated).
IMHO the kind of stuff `unsafe` is used for is very conducive to aggressive automated testing.
> the C++17 standard library is planning on doing checked
> integer operations by default
Note that the Rust developers want arithmetic to be checked, they're just waiting for hardware to catch up to their liking. The Rust "specification" at the moment reserves the right to dynamically check for overflow in lieu of wrapping (Rust has long since provided types that are guaranteed to wrap for those occasions where you need that behavior).
> someone implemented integer overflow checks and found
> that the performance penalty was low, except for
> microbenchmarks.
TL;DR: There exists a compiler flag that controls whether or not arithmetic operations are dynamically checked, and if this flag is present then overflow will result in a panic. This flag is typically present in "debug mode" binaries and typically absent in "release mode" binaries. In the absence of this flag overflow is defined to wrap (there exist types that are guaranteed to wrap regardless of whether this compiler flag is set), and the language spec reserves the right to make arithmetic operations unconditionally checked in the future if the performance cost can be ameliorated.
Note that there's even pushback in this thread about enabling overflow checks in debug mode due to performance concerns...
One reason for push-back on implicit overflow checking is that it complicates superscalar designs by adding another exception source. The good news is that with an open ISA like RISC-V with high quality reference implementations, we can finally actually perform meaningful experiments to test these assumptions - adding different overflow checking semantics to a realistic implementation, quantifying the difference when putting it through the ASIC flow for a real process and making the matching changes to the compiler. It seems ridiculous that us in the computer architecture community haven't had the ability before.
In particular, they can have weaker ordering semantics and they can be buffered and elided among themselves (obviously with some sort of inter-core snooping).
And possibly support for "tagged" numbers, e.g. add integers if high bit is not set, call function otherwise, same for floats if not NaN, with a predictor for them.
Atomic reference counting is slow and gets even worse the more CPU cores and especially CPU sockets you have. If you can afford to make as expensive operation as an atomic add, you can definitely afford to add overflow checks. Atomic add is 50-1000+ clock cycles depending on contention, core/socket count and "moon phase" -- latency is somewhat unpredictable.
> In particular, they can have weaker ordering semantics and they can be buffered and elided among themselves (obviously with some sort of inter-core snooping).
I'm not sure how weak ordering semantics and fetch-and-add (atomic add) could mix. Aren't atomics about strong ordering by definition? Maybe there's something I don't understand.
> And possibly support for "tagged" numbers, e.g. add integers if high bit is not set, call function otherwise, same for floats if not NaN, with a predictor for them.
You'd still get branch mispredict which I guess you're trying to avoid. There'd be no performance improvement.
Traps (CPU exceptions, such as traditional FPU exceptions like division by zero) usually involve kernel mode context switch. So if you trap on tag, the performance for tagged values will probably be 3-5 orders of magnitude slower. That's a lot.
Could you explain why? I thought that trapping was more like a 'slow branch': slow due to the flush the pipeline but why should the kernel be involved(1)?
1: except if you need to swap in a page, but that's just like any other memory reference.
Runtime/language exceptions have different mechanisms that don't require kernel context switches (but might involve slow steps like stack walk).
All languages would benefit from instructions to more efficiently support tracing of native code. A pair of special purpose registers (trace stack and trace limit registers) to push all indirect and conditional branch and call targets would really speed up tracing of native code a la HP's Project Dynamo. Presumably upon trace stack overflow the processor would trap to the kernel or call to userspace interrupt vector entry.
A small pseudorandom number generator and another pair of special purpose registers (stack and limit register) for probabilistically sampling the PC would make profiling lighter weight, both for purposes of human analysis of code and also for runtime optimization in JITs or HP Dynamo-like native code re-optimization.
Not quite 'no'. Of course there are languages that that dynamically switch to bignums, but I doubt that is what you mean. Swift does detect overflow (by aborting, IIRC). https://developer.apple.com/library/ios/documentation/Swift/...:
"If you try to insert a number into an integer constant or variable that cannot hold that value, by default Swift reports an error rather than allowing an invalid value to be created. This behavior gives extra safety when you work with numbers that are too large or too small."
What's the current status? (I read http://www.lowrisc.org/blog/2015/06/second-risc-v-workshop-d... (June 30, 2015))
Your site mentions a lot of "FPGA", do you have some actual silicon prototypes?
What's the current raw speed in MHz or FLOPS?
I read about OpenRISC, OpenSPARC, RISC-V, Z-Scale, BOOM - which are furthest in testing phase? Can we buy some of them in 2017? Or will it take longer?
Can't really comment, since these aren't our projects. I haven't really seen any developments on these fronts, though.
> RISC-V, Z-Scale, BOOM
RISC-V is the ISA. Rocket, Z-Scale, and BOOM are implementations of the ISA we've produced at Berkeley. Rocket is our reference implementation. It is a 64-bit in-order core. Z-scale is a small 32-bit core with no MMU intended for microcontrollers. BOOM is an out-of-order 64-bit core. They all share some common code, but BOOM is a bit behind the other two.
We have taped out different Rocket and Z-scale chips. But these run as tethered systems and were only meant for our research. As a university research lab, we do not really have any intentions for mass manufacture. ASB can answer better about when lowRISC chips will be commercially available.
We haven't yet produced a silicon prototype, but will be taping one out this year. The Berkelely Rocket implementation has been silicon-proven multiple times as has the ETH Zurich PULP core which we also hope to use. The aim of this test chip is to integrate an LPDDR3 memory controller+PHY, plus USB host controller+PHY.
I don't have the link handy, but the Rocket implementation has clocked at 1.5GHz on a 45nm process.
For the final question, perhaps it's useful to define some of these terms:
* OpenRISC: an older 32-bit open ISA.
* OpenSPARC: The open-sourced design from Oracle. GPL-licensed. I don't know of anyone planning to produce a commercially available ASIC using it.
* Z-scale and BOOM are both RISC-V implementations from Berkeley. Z-Scale is a microcontroller-class RISC-V implementation and BOOM is an out-of-order implementation. Both make use of parts of the Rocket implementation (essentially using the codebase as a library). I believe only the base Rocket design has been produced in silicon so far. With lowRISC, we hope to discuss at the upcoming RISC-V workshop (this Tuesday and Wednesday) the status of BOOM, and whether it will make sense to use it as our application cores.
I hope we'll see commercially available lowRISC chips towards the end of 2017, but we'll be able to make a better judgement about how realistic that is once we reach our first test chip.
That's not bad. How many instructions can this issue per cycle?
Hi Alex, I look forward to chatting with you guys about BOOM. =)
What specific license will you be releasing under? Is that still TBD?
Also, who is putting up the money for dev time and fabrication? Partners?
Exciting stuff. Thanks for sharing!
We have received backing from a private individual which has got us going, and some additional donations from some of our project partners.
The Linux Foundation provides "Foundation as a Service" to several of these. I work for Pivotal, so I'm most familiar with the Cloud Foundry Foundation, which is administered by the Linux Foundation on behalf of members.
From what I can see, it's a smooth way to offload the administrative stuff to specialists while retaining the core openness.