Hacker News Reader

Comment by felixguendling | Hacker News Reader

Looks interesting. I have some questions:

(1) Where can I find a minimal code example where Stensal SDK finds a bug that could not be found with Valgrind, Sanitizers (i.e. Asan, UBSan) nor with MSVC debug mode?

(2) From the Get Started guide it looks like Stensal SDK is a custom compiler. If this is correct: which versions of C++ does it support? Does it fully support C++17? Is it based on another compiler (GCC/Clang)?

(3) As your pricing seems to be on a 'per user'-basis, does the CI server count as a single user?

(4) What is the observed slowdown in real-world applications? Or benchmarks like these: https://github.com/google/sanitizers/wiki/AddressSanitizerPe...

View on HN

(1) It is not designed to find more memory errors than said X tool. It is designed to find complete runtime memory errors that can cause security concerns, more specifically, like remote code execution and information leakage (like heartbleed) with very high probability. The probability is determined statically by source code pattern instead of the permutation of malicious input. In theory, you can intentionally write code that cause the runtime checking fail to catch a runtime error.

The minimal code example: Try to iterate the CLI argument of this code snippet https://stensal.com/a/demo_reporting, Valgrind and Asan will not report the overrun when the input is larger than certain numbers.

(2) It currently supports C++14. It will be upgraded in the future releases to support C++17. It is based on the great LLVM/Clang compiler framework.

(3) CI server needs a group license with discount. If all individual developer already has license, there is no need for extra license.

(4) Slowdown can be optimized based on user requirements.

I think (1) is the wrong question to ask, because none of these tools are suitable for usage in a production deployment, so you will only find those bugs with them that can be triggered with your test suite, which is necessarily incomplete.

A better question is, is this new tool intended to be used in production deployments, and what, if any, new attack surface does it introduce?

As you have rightly pointed out the intended use case. I want to add more constraints to it. It's intended to be used in production deployments that are security critical, constant applying security patches is not an optimal solution, and slowdown is bearable.

It will introduce denial of service attack. QMS executables can operate in two modes: warning mode and crash mode. Both will reduce the level of service, but neither will allow memory accession violations to happen.

Edit: added more constraints to the suitable production deployments.

Reply on news.ycombinator.com