Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Bytecode Alliance: Building a secure, composable future for WebAssembly

hacks.mozilla.org

Post reply on HN
Print view View original

231–240 of 265 posts

Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly

#231

Post by pjmlp »

saagarjha wrote: post #226
pjmlp wrote: post #222

Earlier quoted context omitted.

Apple has their own CPUs, https://developer.apple.com/documentation/security/preparing... I do understand what sandboxing means, and how WebAssembly advocates keep overselling its security capabilities, by ignoring issues that other bytecode formats have taken a more serious approach, already in the mid-60's.

Pointer authentication≠memory tagging. The former requires ARMv8.3 and is in the A12 processor, and the latter is not in any hardware that Apple is currently shipping.

Yep, fighting windmills here.

Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly

#232

Post by devwastaken »

dgellow wrote: post #204
devwastaken wrote: post #200

There should not be a 'browser wasm' and a 'non browser' wasm. The wasm committee made many mistakes by treating it as an idea on paper, and not writing the actual implimenting software. This has resulted in significant fragmenting of implimentation, each less trustworthy than the last. If any software is going to advertise safety, it must prove it. That's done through the feedback cycle and careful development. The…

Try searching for C, C++, or even SQL or Javascript. You will quickly see that you don’t have “the official implementation”, because that’s not how things work in practice when considering well standardized and widely used software.

You're mistaking written standard for implimentation standard. You only need a standard in practice.

All of those things you've listed have only a few big players, with enough use and feedback cycle that there can be multiple different implimentations.

Those different implimentations are very similar. There is not a different C to compilers, they have their own quirks, benefits, and target different systems.

JavaScript is the least selective of any language, you will only find runtimes for it's modern versions in browsers Typically V8 or safari. V8 has become the effective standard.

SQL has multiple big implimentations that deviate completely. This has a lot to do with marketing, and the fact data storage/retrieval is a significantly diverse section of computer science.

In each of these known technologies there is a well known, well backed, named software project that people use it's name synonymous with it's supposed standard.

Wasm doesn't have this, and that's because the implimentations took place in browser, which afaik did not impliment a unique engine to it. It just integrates wasm instructions to their js instructions.

Which then led to there being dozens of different self called 'safe' implimentations. None of these have the users, time, and open source community necessary to know this. Which will inevitably lead to exploits.

Given that situation, the only way wasm is going to live up to its goal of safety is backing a well made runtime.

The problem of safety is what makes this very different from other software. Your own code with bugs is an annoyance, and maybe you can't do what you wanted. But code that is meant to be safe that instead allows for damage to you, your company - that deserves a much higher level of scrutiny.

Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly

#233

Post by BubRoss »

pjmlp wrote: post #230
BubRoss wrote: post #225

Earlier quoted context omitted.

Are you saying webasm will crash or that it is insecure? These are two different things and you seem to be conflating them. In your posts you have said that it is insecure but when you talk about specifics it just seems to be about crashing. Then when pressed you avoid any examples.

I keep telling the examples, memory corruption, typical C exploits. Apparently the force is strong with WebAssembly advocacy.

I meant working examples. Saying "it's insecure!" and then calling your own words evidence doesn't count.

If there are actual exploits or security flaws, then demonstrate them with a working implementation. You seem to be trying to turn a technical discussion into an emotional one.

Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly

#234

Post by int_19h »

kasperni wrote: post #205
int_19h wrote: post #172

Earlier quoted context omitted.

JVM bytecode semantics were all about Java - it forces the Java object model on you, for example. It was never designed to allow a diverse ecosystem of languages.

Yet, we still a lot more new languages on the Java platform. Then say .NET which was designed to be polyglot.

If you look at those languages closely, they are usually high-level enough that they can be mapped reasonably well to the JVM object model, or else the language itself is intentionally designed around its limitations (e.g. Scala). But something like C++ doesn't really compile to Java bytecode well.

.NET CIL is much better in that regard precisely because it was designed to be low-level enough to compile C to it - it has stuff like raw pointers and pointer arithmetic, stack-allocated arrays, unions etc. The reason why not many languages bothered is longstanding lack of cross-platform support - Mono was around for a while, sure, but it was not the official implementation, and nobody knew whether it'd still be there next year. Today that's not really an issue anymore, but by now wasm is a better choice.

Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly

#235

Post by rini17 »

AgentME wrote: post #151
pjmlp wrote: post #130

Earlier quoted context omitted.

Actually it fails to properly sandbox C derived languages versus what hardware memory tagging like SPARC ADI and ARM are capable of, because it doesn't do bounds checks inside linear memory blocks.

WebAssembly strongly sandboxes the module from affecting the world outside of it, not from affecting itself. Isn't that the usual use of the word sandbox? The sandbox imposes a boundary between the inside and outside, but it doesn't directly change how things work on the inside. It might be nice to have features for enforcing memory bounds within a module, but I wouldn't call those sandboxing, or call the lack of tho…

To do anything useful across the boundaries, parsing will be involved. Parsing without bounds checking is insecure and will be exploited, period.

Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly

#236

Post by thekingofh »

vanderZwan wrote: post #207
devwastaken wrote: post #198

Earlier quoted context omitted.

This isn't entirely accurate. Exploitations in whatever code is converted to wasm instructions still work inside the wasm memory space. As in, if you write your program in c, python, whatever, and put it in wasm, then have a wasm extension system of some sort - if that c or python is exploitable, then whatever external access that wasm instance has is now useable. And whatever memory is in the memory space can be mod…

Does WASM let you run memory as code?

No. Marking memory as executable is a native machine level capability (as in x86_64 assembly machine instructions). Wasm is a stack machine interpreter that can read only Wasm binaries. The binary format is essentially just a compressed/minimized form of the bytecode format, which used to essentially be an AST of the original source code, but now I believe they modified it a bit to be more analogous to hypothetical machine code, but still abstracted. The Wasm interpreter does not understand x86 or ARM or whatever machine code it's fed it and rightly so. If that was possible, anyone could just send over a buffer to the browser to execute whatever they want.

Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly

#237

Post by thekingofh »

chii wrote: post #169
syrusakbary wrote: post #33

Earlier quoted context omitted.

> It would also be interesting to have an embedded WebAssembly plugin runtime, much like Lua is used all over now that you mention all those examples. Completely! Here are some examples on how to embed Wasm in different languages: * Python - https://github.com/wasmerio/python-ext-wasm * PHP - https://github.com/wasmerio/php-ext-wasm * Go - https://github.com/wasmerio/go-ext-wasm * .Net - https://github.com/migueldeic…

Darn, they are missing java :(

This whole thing is a shot across the bow of Java. Everyone is finally piling on to kill it once and for all.

Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly

#238

Post by rb808 »

jedisct1 wrote: post #152
rb808 wrote: post #129

Can you use wasm instead of regular js/html? I'm thinking for rich GUIs it would be great, even just for company internal sites. I can't find any good examples though.

Check out Microsoft Blazor.

Actually this looks great.

Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly

#239

Post by wahern »

JoshTriplett wrote: post #80
ctz wrote: post #78

Earlier quoted context omitted.

The post mentions: > tiny IoT device But, I've looked at this in the past and concluded wasm was a pretty poor fit for small devices: 1) it only addresses memory in 64KB pages (perhaps more SRAM than you might have) and 2) requires both single and double float support. (1) might be possible to work-around by backing the memory space with smaller page allocations -- at the cost of indirection for every memory access.…

You don't have to support floats; you can, for instance, support loading and validating WebAssembly modules only if they don't use any floating-point operations.

Much like C, which also requires floating point support. WebAssembly implementations for tiny IoT environments can emulate floating point in reliance on people not using it heavily, just as you'd expect them not to run Node.js. But at least the developer has the option, which can have significant value, such as during exploration and experimentation phases.

Similarly, compilers like GCC will synthesize 64-bit arithmetic inline for i386 and other targets lacking 64-bit support. These days few people think twice about using 64-bit data types even though 32-bit processors are still in heavy use. (Though, AFAIU emulation has largely moved from compiler to the instruction decoder or microcode.)

Re: The Bytecode Alliance: Building a secure, composable future for WebAssembly

#240

Post by wahern »

saagarjha wrote: post #212
kllrnohj wrote: post #168

Earlier quoted context omitted.

mmap is arguably the only thing it should have had in the first place. brk/sbrk is fairly dead.

$ strace /bin/ls 2>&1 | grep brk brk(NULL) = 0x55fb032b3000 brk(NULL) = 0x55fb032b3000 brk(0x55fb032d4000) = 0x55fb032d4000

  $ ktrace /bin/ls >/dev/null
  $ kdump | grep brk | wc -l     
         0
  $ kdump | grep mmap | wc -l
       130
glibc, musl, and jemalloc got the memo, they just couldn't be bothered to stop using brk by default. They're all capable of using mmap exclusively, however, because whether or not brk is actually dead, there's long been consensus that mmap is the better abstraction on balance, particularly given the benefit of ASLR. So there's little reason to support brk instead of mmap for compatibility. Presumably it was chosen for the convenience of WebAssembly implementations--contiguous, flat memory is a great simplifier of VM, JIT, and even traditional AoT architectures.
Post reply on HN