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

211–220 of 265 posts

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

#211

Post by DonHopkins »

pjmlp wrote: post #196
dboreham wrote: post #194

Earlier quoted context omitted.

You forgot the UCSD P-System.

It is included on the .... :)

...That reminds me of a cartoon I saw in an old Apple ][ magazine:

(One kid talking to another, with dad in the background hunched over an Apple ][.)

"Daddy's playing UCSD Pascal. That's the game where you try and see how many dots you can get before it beeps and you say nasty words."

http://bitsavers.trailing-edge.com/pdf/ti/professional/p-sys...

UCSD p-System Program Development (p. 2-4)

While the compiler is running, it displays a report of its progress on the screen in this manner:

    Pascal compiler - release level VERSION
     ...................
    INITIALIZE
     .......................................
    AROUTINE
     .......................................
     .......
    MYPROG
     ......................................

    237 lines compiled
    INITIALI .
    MYPROG ..
During the first pass, the compiler displays the name of each routine. In this example, INITIALIZE, AROUTINE, and MYPROG are the routines. The numbers enclosed within angle brackets, , are the current line numbers and each dot on the screen represents one source line compiled.

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

#212

Post by saagarjha »

kllrnohj wrote: post #168
saagarjha wrote: post #164

Earlier quoted context omitted.

Would it be impossible to implement mmap and sbrk in the runtime?

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

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

#213

Post by saagarjha »

pjmlp wrote: post #190
saagarjha wrote: post #160

Earlier quoted context omitted.

> In fact that is what most modern compilers do by default in debug mode. Assuming that “debug mode” is -g or equivalent, then I have not seen a modern compiler that does this.

Then get to use Visual C++, which does bounds checking on collection types (array, string, vector,...), memory dumps leaks at exit. Or Solaris SPARC and iOS compilers that make use of hardware memory tagging. Clang and GCC do need extra flags to enable FORTIFY mode though. However on Android FORTIFY is now a requirement and future versions will make use of memory tagging on ARM hardware. So ironically something like…

> iOS compilers that make use of hardware memory tagging

No iOS devices ship with ARMv8.5, so while I think compilers are implementing this today I am not sure if Xcode ships with this or if it's functional.

> So ironically something like Android does have a better sandboxing model as WebAssembly.

…you're not understanding what sandboxing means.

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

#214

Post by saagarjha »

pjmlp wrote: post #193
saagarjha wrote: post #162

Earlier quoted context omitted.

If you give a sandbox a capability and then there’s a bug in it, there’s always a chance that it will maliciously access those privileged resources. The only way I can see of protecting against logic bugs like these is better tooling.

Yeah, but then one should acknowledge those issues, and not advocate WebAssembly as if there weren't hundreds of other attempts since the late 50's.

They don't mention them because their focus is on other aspects of safety.

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

#215

Post by tschneidereit »

steven_is_false wrote: post #184
tschneidereit wrote: post #139

Earlier quoted context omitted.

What you're describing will indeed be introduced with the WebAssembly GC proposal: https://github.com/WebAssembly/gc For languages that can express unforgeable pointers as first-class concept, that is indeed a very attractive, fine-grained approach. Unfortunately bringing that to languages like C/C++/Rust is a different matter altogether. Since we want to support those languages as first-class citizens, we can't requ…

>Since we want to support those languages as first-class citizens, we can't require GC support as a base concept I feel like you're overthinking it. Can't you just have a table that holds GCable objects and only hand out indexes to C and co?

That is how we support references in the Rust toolchain right now, via wasm-bindgen, and it's an important part of making unforgable references work for languages that rely on linear memory.

It doesn't help with making capabilities more fine-grained, though: we have to treat all code that has access to that table as having the same level of trust.

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

#216

Post by mantap »

pjmlp wrote: post #203
mantap wrote: post #166

Earlier quoted context omitted.

WebAssembly is still very immature. It unsurprising that it has such a low adoption right now. I think the real problem with webassembly would be if it becomes too popular and starts to become a JS competitor rather than a complement to JS.

WebAssembly is the revenge of Flash/Java/ActiveX, but this time everything will turn out perfect, as per WebAssembly advocacy.

Honestly, given the lack of tooling they have now, it is pretty much perfect from a user's perspective. You are only going to use WASM if you absolutely need the performance. It's just too painful otherwise.

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

#217

Post by pjmlp »

mantap wrote: post #216
pjmlp wrote: post #203

Earlier quoted context omitted.

WebAssembly is the revenge of Flash/Java/ActiveX, but this time everything will turn out perfect, as per WebAssembly advocacy.

Honestly, given the lack of tooling they have now, it is pretty much perfect from a user's perspective. You are only going to use WASM if you absolutely need the performance. It's just too painful otherwise.

Well, better take care which sites you visit.

https://www.infoq.com/news/2019/10/WebAssembly-wasm-maliciou...

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

#218

Post by [deleted] »

pjmlp wrote: post #192
BubRoss wrote: post #183

Earlier quoted context omitted.

Wouldn't that just corrupt your own program? If there is a security flaw you could demonstrate it.

Except that you load code from multiple sources and one could eventually have a piece of JavaScript code that makes use of such behaviour to have access to some feature that by default is not accessible. I rather let WebAssembly turn out to be the next Flash, when black hats start looking at it with the same care they had before, no need to waste cycles myself, as it is a lost battle against WebAssembly advocacy.

[deleted]

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

#219

Post by BubRoss »

pjmlp wrote: post #192
BubRoss wrote: post #183

Earlier quoted context omitted.

Wouldn't that just corrupt your own program? If there is a security flaw you could demonstrate it.

Except that you load code from multiple sources and one could eventually have a piece of JavaScript code that makes use of such behaviour to have access to some feature that by default is not accessible. I rather let WebAssembly turn out to be the next Flash, when black hats start looking at it with the same care they had before, no need to waste cycles myself, as it is a lost battle against WebAssembly advocacy.

I don't understand what you mean by "a piece of JavaScript code that makes use of such behaviour". Webasm is accessed by javascript, not the other way around.

This really sounds like you have an axe to grind with webasm for some reason, the things you saying seems like grasping at straws. It already works in browsers, so if there is something to exploit you could demonstrate it with a few files on github.

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

#220

Post by gatestone »

This is getting complicated. OS process management, threads and lightweight pocesses, green field process control, virtual machines, containers, sandboxing in n browsers with m different technologies, now this WASM stuff..and orchestrating this all across the cloud and the global internet, ending in homes and corporate machine rooms.

Enverywhere you have to think: who can load/run a module/process and from where, how to authenticate and authorize, which API to give to it, etc...

A historical note:

Bell Labs Plan 9 had a universal OS level solution, that Linux has somewhat adopted, but could not make general enough, partly due to the higher lever ecosystem being stuck to old ways:

- per process name spaces with mountable/inheritable/stackable union directories and optionally sharebale memory (Linux light-weight process, LWP, comes close, it was also historically copied from Plan 9)

- Almosty all APIs (even "system calls") as synthetic file systems (Where do you think /proc came from?)

- which you could mount and access (efficiently) locally or through a secure unified network protocol (9P)

On Plan 9 you could just run different parts of the browser (JavaScript engine, WASM or anything) in a tailored limited LWP with limited mounts as synthetic file system APIs...

Note that Docker kind of retro-fits Plan 9 ideas in Linux kernel to embrace and extend the original ideas of Plan 9...

Post reply on HN