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

Search the Community

Showing results for tags 'kernel'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • OpenComputers
    • Announcements
    • Feedback
    • IRC
  • Code Central
    • Support
    • Showcase
    • Tutorials
  • Addons & More
    • Addons Mods
    • Architectures
    • OpenEngineering Task Force
  • General
    • Lounge
    • Forum Games
    • Showcase
    • Servers
  • Archives
    • Public Archives

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start





Website URL










Found 1 result

  1. 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.
  • Create New...

Important Information

By using this site, you agree to our Terms of Use and Privacy Policy.