Jump to content
  • Sky
  • Blueberry
  • Slate
  • Blackcurrant
  • Watermelon
  • Strawberry
  • Orange
  • Banana
  • Apple
  • Emerald
  • Chocolate
  • Charcoal


  • Content Count

  • Joined

  • Last visited

About Varscott11

  • Rank
    Junior Member

Recent Profile Visitors


  1. I did think that was strange. I though it meant that you can and loading it back could be dangerous. For the purpose of a virtual memory manager in a game, It really doesn't need to fully swap code segments. That is a bit overkill. After all most memory usage comes from data (usually) such as tables and what not anyway. I wouldn't really say it is not possible to swap code either. You cannot swap the current state of a coroutine but you can swap static chunks via string.dump and load.
  2. I'm not mad at all and in fact I do actually agree with many of the points you have made. Some things I didn't know for example was the OC collects garbage at 10 instruction intervals. This is HUGE for me to know. Since I don't know a lot about the Minecraft Java environment I didn't know either that debug hooks aren't persisted. The fact that all types can be arbitrarily serialized now that I see that, can pose security problems not just for OC but for a kernel as well. The only thing I am not sure about is the OC killing a long running process for you. Does it kill the coroutine that is long running or just stop the Lua state. I can search for this myself in machine.lua so don't worry about that, but I'm pretty sure it doesn't notify the kernel via a signal so there is no way to know what happened and to do any cleanup if necessary. I will gladly do work arounds if I can to ensure security and stability (My kernel is centered around strong security). I just need to understand how the mod operates to do such work arounds and this gives me an insight. All in all though I respect your opinions and I'm now a bit reinsured that though it is limited in many ways, there are options. I recently started to work in the mod as a way to get away from the super low-level work of developing a kernel irl with C and x86 ASM and it is a quite difficult switch from complete control to less control. Thanks for your review!
  3. This is more of a request of the Open Computers developers and may be a bit far fetched, but hear me out. At the very beginning when a BIOS is run, it is running in a sandboxed environment. This makes perfect sense as the Lua interpreter will blindly execute instructions on a real CPU on a real computer which can lead to major security risks if not protected properly. This is done by 'machine.lua' but this is where a problem starts to arise. Theoretically there is enough to build a fully functioning operating system, but it is actually quite limited and this is kind of strange. In real operating systems, the kernel has complete undisputed control over the entire computer. It stands to reason that this is where the sandbox security should be implemented and would allow for so many possibilities that would make the mod shine. Here are some things to be considered: SEMI-PREEMPTIVE MULTITHREADING: I am aware it is not possible to yield from a Lua hook but you can force a coroutine to terminate. This is demonstrated in machine.lua. This combined with some clever mechanisms can result in an almost hybrid between preemptive and cooperative multithreading system with lightning fast interrupt (event) dispatching. MEMORY MANAGEMENT: A computer can only use a relatively small amount of memory by default. This makes perfect sense. I mean if 30 people on a server all have a mega server farm and each in game computer can allocate 1GB, you will run out of memory on the host computer very fast. The problem is that memory management is very limited without collectgarbage. With it you can implement some sort of memory tracing allowing you to terminate a coroutine (via preempt checks for example) if it exceeds allowed memory. This actually makes the system more secure than it currently is because you can stop a malicious program from infinitely allocating memory until the computer runs out crashing it. VIRTUAL MEMORY SWAP FILE: With the unrestricted use of the debug library it can be possible to serialize upvalues and globals and write them to a disk when they are guaranteed not to be used in order to save precious memory. KERNEL SECURITY: Having complete control is actually more of a benefit to everyone (granted the kernel code is trusted). The kernel can implement security on it's level that is more relevant to it's interests as well as prevent any other code from exploiting the actual mod or Lua interpreter. After all, code has to be chosen to be run by the kernel and can be sanctioned at will. A simple file system protection layer can ensure a program cannot write or read from the kernel on the disk completely user spacing any program. Of course I'm not saying remove all security measures from the mod. That's just crazy. However simply adding an option to the config file to allow something like 'disableSandbox' that would grant the entire Lua Standard Library would be a godsend. If anything it would be completely sufficient to wrap all these functions that prevent the kernel from doing anything that can directly harm the host or going any lower level. Plus it is up to the user to truly decide if something is trusted. If the user wants to install a kernel to their host server with complete access, they would have the freedom to do so if they do so understand the risk. The config file is full of these sorts of trust dependent options already. So long as a person cannot access the save and .minecraft directories from a Lua state, that should be mostly it. For those who are happy with what there is they will have no change as the normal OC sandbox should be enabled by default. To top it all off, I have managed to implement all of the above in an unsandboxed Lua environment, so it would be so amazing if it can be ported. I don't know what goes into developing OC but in my mind it shouldn't take more that skipping the sandbox init if the config says to do so. These are my thoughts and they may just very well be dreams but if there are any OC developers reading this or anyone really, tell me what you think of this idea.
  4. Is this list a part of OpenOS or actually what you have provided by the mod what you start the computer? I'm asking this because the OpenOS Kernel.lua seems to be using debug.sethook
  5. I've looked at the page showing everything that can be used in an init script and well as the Open Computers kernel.lua but I still have some questions: What is available in the debug library (Lua 5.3) aka debug.sethook for example. Can someone please post what functions are and aren't available?
  • Create New...

Important Information
