
Show HN: Stensal SDK: Retrofitting C/C++ code with quasi-memory-safety - cubidudu
https://stensal.com
======
felixguendling
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...](https://github.com/google/sanitizers/wiki/AddressSanitizerPerformanceNumbers)

~~~
the_why_of_y
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?

~~~
stensal
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.

------
jerrysievert
Using memory and address sanitization goes very far, without the need for
special libraries.

gcc/g++ and clang/clang++ both have full support at this point.

~~~
stensal
I'm the founder and built the SDK.

Agreed, ASAN and Valgrind cover the most memory errors and are readily
available for almost all platforms.

The SDK is designed for a different purpose -- to catch all runtime memory
issues with a very high probability. The generated executables can be deployed
and used by the end users who don't want to upgrade just for the fixes of
memory errors. There are many cases the memory errors are never exploited. By
using the pre-built QMS executables, you know when you are exploited, and the
exploit will be stopped by the runtime checking.

Edit: Even though I have been reading HN for a quite long time. This is my
first post, I just registered recently. I could not figure out how to post
Show HN and had to ask a friend to post it for me.

Added more details.

~~~
cryptonector
I couldn't figure out much from the site as to how this works. Can you go into
some detail?

~~~
stensal
I guess you ask how this dynamic type system works. It basically gives each
valid pointer a type, which includes the size information and liveness
information of memory pointed by the pointer. When a pointer is dereferenced,
the runtime checking will verify whether the dereference is valid. Null (and
uninitialized) pointer does not have a type.

It uses a completely different mechanism from the one used by ASAN and
Valgrind.

Edit: delete a wrong answer.

~~~
jerrysievert
Interestingly, SillyMUD and its descendant Phoenix at one point had similar
memory checks that occurred at runtime, as well as shared memory with
reference counting and a paging virtual memory system.

Unfortunately, even with that and it having been run with purify (a commercial
predecessor to valgrind), i was still able to find some severe memory issues
that didn’t manifest by compiling with address and memory sanitization about
25 years later.

~~~
stensal
I didn't know SillyMUD. But I did read the paper about an interpretation based
memory checking tool many years ago. Unfortunately, I forgot the name. I
believe the interpretation based memory checking tool assigns each pointer a
type. So the idea is not new.

ASAN is great because of its compatibility with existing libraries, as you
have pointed out, is available in both gcc/clang. Valgrind is in the same
league. Both are fantastic tools even though they might miss some errors.

------
fulafel
Could you compare your approach to SoftBound
([https://www.cs.rutgers.edu/~santosh.nagarakatte/softbound/](https://www.cs.rutgers.edu/~santosh.nagarakatte/softbound/))
?

~~~
stensal
I want to avoid to do comparison with the said X tool without fully
understanding their constraints because different approaches have made
different design trade off and each has its own strength. That having been
said, the academia often publish some survey papers about the state of art of
memory error detection tools. There is a recent paper "SoK: Sanitizing for
Security"([https://arxiv.org/abs/1806.04355](https://arxiv.org/abs/1806.04355))
that has categorized most of the known dynamic memory error finding tools very
well. They analyzed the different detection mechanisms and collected empirical
data with their best efforts in their categorization. It's highly recommended
for anyone who wants to understand the difference among these detection tools.

IMHO, If you want to increase your detection coverage. You might need multiple
tools to fulfill your code quality requirements. If you cannot use multiple
tools, pick the one that is readily available.

