I can't speak to the original intent for severely limiting the language dtrace uses (no loops, user defined functions, etc). However, I can say that web assembly itself is designed to be sandboxed so I wouldn't say that is too dangerous at all. It would be quite nice if Microsoft explored a web assembly kernel engine. You see designs like this with ebpf already, they all are trying to do the same - create a statically verifiable language and isolate it's execution. I'd argue using something like web assembly is much better than designing a new language like dtrace does honestly. It's good enough for browsers to run untrusted code, kernel is not terribly different. My WASM kernel driver is however just a POC to vet the idea.
For dlls in the kernel, yes absolutely insecure. It's intended to be a tool run in an analysis VM not on endpoint user systems. The security model is simply different for the DLL based architecture. One of the big reasons I am ok with this design is because driver signature enforcement already must be manually disabled to load the C driver that uses DLLs like this. With DSE off you can already easily load unsigned kernel code so this doesn't open any additional security holes.
it's a dtrace reimplementation because it's using those kernel interfaces. The architecture of the scripting system on top of that could be anything. The wasm rust system mirrors MS' architecture, the C++ DLL system differs intentionally from it.
This project lets users write plugins that can hook windows system calls. I've open sourced a C++ and also a Rust driver. The rust driver embeds web assembly into the windows kernel for handling hook events, while the C++ version maps dlls to the kernel. Included is also a Rust project PDBReSym which handles downloading, parsing, and symbolicating using PDBs. This tool doesn't rely on the normal Microsoft DIA sdk apis for symbols and is significantly faster.
This work was presented at DEFCON 30 this week. Happy to answer any questions!
'The key wasm person' is nonsense. It's a spec, with multiple implementations of interpreters, jits, and other execution environments. Even outside of browsers there's other runtimes.
your point has a truth behind it for sure, but there's a large difference between serving requests and making requests. Many sites are simple html and css pages, but many others also have complex backends. It's those that often are hard to scale and why the cloud is hugely popular, maintaining and scaling the backend is hard
it could be. With the legit package named with a misspelling on purpose, users may confuse the correct spelling 'request' for the real package. in that case the typosquatting attack would actually not be a typo at all! You can't identify this attack by just looking for correct spelling, which is OPs point
Wasm is a sandbox first off. Any situation where you want to isolate a computation is an application suitable for wasm. Browser is just one instance of that
You are incorrect. I work with malware professionally, defeating a VM obfuscator is often called devirtualizing. There is also the compiler optimization term as you say, but terms can mean more than one thing...
IMHO there are better things to pick on Go for. The choice of using capitalization for public/private is probably the largest imho. When you want to change a field you have to change all references to it too. You could argue an IDE makes that easy, but what about when patching with Git or other external tools, now your simple patch is context specific. The second biggest is then probably the module system. To this day I'm still confused when a local project has an import from a github URL. Is that using my local github.com/user/myfolderlocally or is that legit pulling the old version I have on github, gets more confusing with cross repo modules. Then the whole /internal paths for modules is also annoying, I sometimes want to use an 'internal' thing from another repo, but I can't because Go artificially limits me and the previous author thought 'nope no touchy' and I'm just left with forking for a tiny little import - gah. Finally is probably the ethos of the community itself - never change anything and keep it all dog simple or get chastised for suggesting anything outside of what is currently the norm. The power is often handed to the authors of packages and the language itself, over the users of packages - and there's essentially no escape hatches anywhere - "do it this way or your design is wrong".
please consider raising the priority of no_std wasmer support. This is the biggest barrier for seeing wasm in some really cool areas, kernel, embedded, etc
If you read the how.md it mentions the key insight was to introduce an operation into the language that allowed temporary violation of 'sensical rules' that the author calls superposition. Then computing or applying one of these super imposed clones collapses down to a final result obeying the rules. Being that the lambda calculus is core to computing information, I can't help but think, what if this is actually an insight into something profound about how our universe works?
In my case the right hand preview being generated is literally HTML that is presented as formatted markdown. The solution for me was to detach the generated markdown html tree from the creation of the react elements. You can have the worker return a json tree shape that defines all the elements it wishes to place onto the dom, ships it over to the main react element that React.CreateElement's through the tree.
This way the cached elements can be shown until the new tree elements are created and you can just react setState to the new elements and it's instant
Everything is assembly, that's how your CPU works. If you run C code, rust, go whatever you have to Target an architecture so the compiler can generate the correct assembly instructions. Even python or js interpreters must be recompiled per each architecture you wish to run those languages in. Lambda doesn't change that, as the comment above says its just a container
You issue is likely due to a heavy computation blocking the main js thread (rendering). In this scenario the suspense api will not solve the UI lag. I've had the exact same pattern with a home build markdown editor where the right side preview should render quick, but lag behind if too heavy and give priority to left hand side. I tried the alpha and speak from my own experiences, you'll have better luck by offloading render computations to a background web worker. The preview can do a 1 time synchronous render, cache the result in it's local component react state, then all future state updates are computed async on the background thread. Main thread left unblocked
you want your kernel to do that because it's the source of truth. And what if you want to audit execution that includes binary blobs you don't own the source of?
If it's not clear, here's a summary. FireEye acquired Mandiant a while ago for ~1B. FireEye had all the jazzy physical tech of the time like good, hardened sandboxes, sensors, etc, stuff you physically sell. Mandiant had the incident response and threat Intel expertise to analyze the telemetry from those physical appliances. Pairing made sense.
Now a days, Mandiant's IR and threat Intel offering is strong as ever, but people don't want just 1 companies sensors and telemetry products, they want to use whatever they want. There's also been new strong players into the physical sensor business like Microsoft and Crowdstrike just to name 2. So by splitting Mandiant can gain freedom to do all the things they do best but also integrate with other companies products, while FireEye can still develop leading products sold as standalone items. Mandiant has sold the big parts of what used to be FireEye for ~1.2B. So total Mandiant -> FireEye -> Mandiant
It's a good move that splits both organization segments in a way that makes sense for each. Disclaimer, I work for FireEye.
As a person who works in cyber security, no, no we probably wouldn't share those details. It gives an edge to attackers about how we track them. Those details are only made public when the malicious activity is aggressive or widespread enough, at which point it's for the greater good to go public and bare it all. There is so much that goes into that blurb that you cannot even comprehend unless you work at a security agency/company, and many times on the specific incident in question.