Viewing profile — daniellehmann
daniellehmann
HN member- Joined
- Tue, Sep 04, 2018, 11:18 AM UTC
- HN karma
- 55
- Public activity
- 19 items
- HN profile
- View on Hacker News ↗
About daniellehmann
No profile information was provided.
Recent public activity
-
comment
Comment #29377938
This is not correct, it is not necessary to specify a maximum memory size. See the WebAssembly specification https://webassembly.github.io/spec/core/syntax/modules.html#... . Due t…
-
comment
Comment #29057501
Very cool, thanks a lot for the example!
-
comment
Comment #29057297
My reading of the article is not that it promotes "anti-intellectualism" or that it argues to remove all implicit precedence or associativity rules. I think it actually gives a nua…
-
comment
Comment #29057205
I don't know Swift, but does this mean there are expressions in Swift where the compiler returns an error, because the expression is ambiguous without additional parentheses? (My u…
-
comment
Comment #28752532
See e.g. https://www.digwebinterface.com/?hostnames=facebook.com&ns=a... for responses from different nameservers.
-
comment
Comment #27005251
Thanks. You are referring to the example exploit in section 5.3, right? Please note that this example is for a standalone VM, not inside the browser (where JavaScript programs -- a…
-
comment
Comment #26998611
I don't think that's a fair assessment, and it is also not fair to the designers of WebAssembly. They certainly have spent a lot of thoughts on protecting the host (e.g., browser, …
-
comment
Comment #26998527
Thanks a lot for the additional background, and also for all the work on WebAssembly. It is a very cool language and having it available with linear memory now is much better than …
-
comment
Comment #26997242
Good summary and clarification. Yes, we do not aim to break out of the (browser) sandbox, and yes the example exploits only use functions that are already imported into the vulnera…
-
comment
Comment #26997060
Daniel here, one of the authors. You are right, some of the issues highlighted in the paper could be solved by compilers targeting WebAssembly. One such mitigation that is (current…
-
comment
Comment #26996877
Daniel [1], one of the authors here. Feel free to ask also technical questions, I'll try my best to answer them. If you don't feel like reading the whole paper, there is also a sho…
-
comment
Comment #24225674
> This doesn't really seem to offer anything useful, or even contain new information. You are right in that we do not try to attack a concrete host implementation or aim to break o…
-
comment
Comment #24225485
Excellent explanations. > C++ compiled to WebAssembly generally manages its own parallel "shadow stack" in linear memory In the paper, we call the compiler-organized stack in linea…
-
comment
Comment #24225465
> Do some of the safety measures you consider translate well in this model? Yes, I think several mitigations could be deployed without requiring a change to the language, only by c…
-
comment
Comment #24224004
> some C library you have compiled to WASM: wrap that functionality up with an interface, compile that to WASM, and only pass it the image data you're happy for it to see That is g…
-
comment
Comment #24223979
I am not sure I understand the sentence "limiting the WA spec to only try to sandbox the WA binary from outside memory". I would not say that we (as in: the authors of the paper) a…
-
comment
Comment #24223915
Hi everyone, Daniel here (one of the authors, I am the PhD student in the video). Great to see the paper submitted and discussed :-) Sorry for being a bit late to the discussion, I…
-
comment
Comment #17909578
Thanks for the warm words, happy to hear that others are interested in this project and WebAssembly in general! Regarding your question: No, I have not yet contacted the WebAssembl…
-
comment
Comment #17908190
Daniel here, PhD student working on this. Ask away if you have any questions :) For now, this is in an early stage, so probably mostly interesting to researchers or as inspiration.…