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

> 70% of security bugs are memory safety issues. That's a lot of real problems.

Run your code in a WASM sandbox or on a GPU, problem solved.



"Run your code in a WASM sandbox" and then your C++ is way slower (and speed is the only reason you were using C++ in the first place)


C++ compiled to wasm is just java with extra steps.


I totally agree but there are two differences:

- WASM will be available even more places than the JVM

- way more languages will target WASM than ever did the JVM

Personally, I cannot wait for a WASM future.

Being able to target WASM for the 90% of apps that it is fast enough for and being able to use the same language and libraries to target native when required….is going to be awesome.

I really like the CLR. A more widely adopted version of something similar ( WASM ) is attractive.



Unless you write software that processes input from one user while having data private to another user in memory. So ... quite a lot of software


Which is quite risky even with memory safe languages, if the big exploits in the last decades had anything to show it is that both RAM and CPU can be abused into bypassing any protections in place.


> Run your code in a WASM sandbox

Assuming your WASM sandbox is airtight, that would work. But there are still ways to break out or cause damage because within the sandbox, its like a flat address space with 0 modern protections like ASLR, stack canaries, page protection, etc. (unless you manually compile it in yourself). See [0]

* [0]: https://www.usenix.org/conference/usenixsecurity20/presentat...


There is a lot of code that can't run in a WASM sandbox, like drivers for example.

I do think more things running in WASM or WASM-like VM's could help a lot, but I'm not sure what the GPU part is supposed to mean.




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

Search: