fwsgonzo

A trend? People never capitalized anything on IRC in the early 90s. The only time I saw it was on forums and other longer forms of text. And then eventually everyone else joined the Internet and more formal writing became the norm. Not wanting to pointlessly capitalize letters is neither here nor there. It doesn't mean anything.

Not really, no

I have a bit of experience in this, and adding monitoring, logging and observability doesn't really affect it compared to the non-sandboxing path: All of those things should already be happening. There should already be logging and statistics gathering as part of the larger service.

libriscv in interpreter mode is fast compared to other interpreters, but not near native performance. As I wrote earlier in the thread using something backed by KVM is what I would do if I were architecting a solution for someone. Eg. my TinyKVM KVM-based userspace emulator would fit the bill.

That's what libriscv excels at. It's the ideal solution for exactly that

https://libriscv.no/docs/intro/

Absolutely not! It's better to use something backed by KVM, so that you can use all the features of the CPU. This is just a proof-of-concept that was fun to make.

FireCracker has a jailer: https://github.com/firecracker-microvm/firecracker/blob/main...

The VM could only make requests if you add a system call specifically for that purpose. Eg. if you add something like sys_request that takes a URL as argument and some input and output arguments. It's not that the VM couldn't open a socket and handle connections by itself, but it's all closed down.

I think when it comes to being integrated into a web server, you ideally want to use the web servers pipeline to make requests, so that you can benefit from the same logging and observability that Drogon (or other solutions) already have.

If you allow the VM to make requests on its own, you just have the IP and an open socket. Not much to debug with if (let's say) you have a customer asking about something.

Well, the boundary between the host and the guest, the system call API, is always going to be the biggest vector of attacks no matter what the solution used is. But, if you find a problem and fix it, you're back to being safe again, unlike if you don't have any sandboxing at all. You can also put the whole solution in a jail, which is very common nowadays.

Funny you mention that because mini-moonbitlang seems to be using libriscv!

https://github.com/moonbitlang/minimoonbit-public

So, maybe not the official compiler but something else is already using it?

Yes, we have spoken to a lawyer and it is indeed the case. It still costs money, and we are not sure how to proceed yet, outside of removing links to the domain.

You're completely right. It's a squatter and he wants money. The project is not dead, however. It's currently used for research at University of Oslo, and I think we can expect much more activity in the coming years, such as ARM support.

I might add RISC-V support myself, as I am the author of libriscv. We'll see.

We are indeed Norwegian! The domain is owned by a squatter now. He wants EUR 3000 to release it back to us. It's simply too much right now. So, I wish that this HN post could change from the squatter URL to GitHub instead.

Maybe you already considered this, but contracts are full of unenforceable and illegal clauses. At the end of the day you did work for them that they agreed to and then they stiffed you on it in a very visible way. Generally, if the work is already done, they are liable for the entire amount.

I would be talking to a lawyer. You might even consider it part of your job to have a working relationship with a lawyer.

I have to strongly agree here. Video games are not free from the social media problems that we are trying to free ourselves from. We also have parents and close family that have been caught in outrage nets, and who knows when, if they will ever be free? We know the pipeline for right-wing grifters.

Who doesn't have any taters in the family these days? A literal human trafficker and pimp who has been in prison is giving advice to our youth in droves. More than you will ever know. My family members stopped talking about it, and started complaining about how we can't talk about things anymore once they discovered that outside of their bubble people know what these monsters/grifters actually do.

It's the same here. Just how it is, I guess. It's all me, either I research, implement AND write or nothing happens. Just be aware that a PhD isn't worth much to begin with, so if you're unhappy, consider your options. I'm relatively free to do what I like, so I stay.. for now.

> While we work hard to minimize risks, there is always an inherent risk in downloading a mod that changes the contents of a program, no matter what platform is used for distribution.

What happened to good old sandboxing and modding APIs?

> Fully preventing such incidents would require prohibiting and removing code mods altogether

"We didn't sandbox mods from the start"

I can't publish/open-source it, sadly. But the paper I can share: https://www.dropbox.com/scl/fi/38e0la5m6zkc04tlm03w8/Introdu...

Yes, if you don't need sandboxing then containers are just way easier to deal with. Although I wish they didn't use so much space.

I wrote the IncludeOS kernel bits

Looks like my TinyKVM project, except it runs specialized programs instead of regular ELFs? TinyKVM also runs functions, with a fast execution timeout. I proved that without I/O you can essentially run KVM programs with native performance, and sometimes more due to automatic hugepages. I measured LLMs to run at 99.7% native speed using eg. Mistral 7B. For example, the STREAM memory benchmark doesn't use hugepages by default, and so the terminal version runs slower than the TinyKVM version due to hugepage-tables, but of course runs at the same speed once you modify the benchmark to use the same advantage. However, it does require modifying the program.

See: https://ieeexplore.ieee.org/document/10475832

I also implemented VM resets using page-table rewrites and CoW memory sharing, so that no memory is shared across different requests. This can be implemented as tail-latency in a cache.

I ended up adding support for most languages. All the systems languages, Go, v8, LuaJit etc. Go was by far the most annoying to support as it uses signals.

Same here in Norway.

I can at least confirm playing mega-modded Oblivion on Linux.

I have to say that yes, it's a PITA. Ever tried to enable exceptions in one part, and disabled in the other? It simply won't load.

Or any other option. Really. So many investigations, so much time wasted.

That's been my way of browsing for a while now and I agree it works for the most part. I have no intention of going back.

It's especially nice to have JavaScript disabled by default, so I can enable one script at a time until it becomes readable. But not so many scripts that it becomes unreadable again.

I think I agree. It's maybe 2x for me after the project has been solidly established. However, it's very useful to have the AI during the beginning, when you're writing a lot of boilerplate or integrating with APIs that you don't know super well. The AI can surprise you and connect some dots.

I'm currently trying to implement an in-editor sandboxing/modding solution for the Godot game engine. It's hard work trying to make everything work the way people are used to having it, and even competing with GDScript.

https://github.com/libriscv/godot-sandbox

I originally started on it just to get into Godot.

  function fib(n, acc, prev)
    if (n < 1) then
      return acc
    else
      return fib(n - 1, prev + acc, acc)
    end
  end
  print(fib(50, 0, 1))

  $ ./rvlinux -P ~/github/LuaRiscvJIT/src/luajit -- test.lua
  12586269025
  >>> Program exited, exit code = 0 (0x0)
  Runtime: 0.281ms   (Use --accurate for instruction counting)
  Pages in use: 429 (1716 kB virtual memory, total 2674 kB)

It's definitely working!

Wow, that's an impressive PR with very well written and succinct code. Macro-fusion too! B-extension support!? I see some RORIWs in there.

Alright, time to run some LuaJIT in my RISC-V emulator.

Fun fact: It's also the only linker that enables --execute-only as a feature that Just Works with a single argument. Getting XO to work on regular linkers is a real pain.