[1.4] Allow for custom shells in bios.lua

As I see it currently BIOS runs a parallel waitforany on both rednet and os.run to fire of the default shell. What I'd like to see is that BIOS has a way maybe via startup scripts that we can set a non standard shell to run.

As it currently stands the best we can do is run our shell in the default shell on startup. It works but has it's problems.

While we're at it being able to replace rednet would be ideal as well. We can load/unload the API but the coroutine is running.

So basically make BIOS no longer determine the startup progams. Load a bootloader instead that has a configuration we can override. This should allow BIOS to by directly run a bootloader in /rom but allow the user to override it in /. Similarly to the way startup works now.

You can change bio's however you want…

I'm well aware of being able to change the BIOS.lua file however I please on my server. And while for the time being I'm doing just that, I'd like to be able to complish a complete os replacement on a per computer basis.
The is my suggestion. To modify the existing BIOS.lua file to allow that. I could whip up a quick overhaul if needed.

Am I right? You suggest yourself to change bios.lua as you want. You are able to do it and it will allow you to do what you want… What's the problem?

I think he means that now there is no way of installing a completely independent shell on a per-computer basis. And what he suggest is basically a BIOS modification that allows you to control what gets loaded at os startup.

He can do it on his server and he know it. Why not just do it for self?

Sorry. I must have mistook the suggestions section as a place to put ideas to improve computercraft.
So should I just assume that anything in lua is not worth the suggestion? Because while I know I can rewrite that entirely from scratch, but if suggestion to improve the default os are met with such criticism then I think that should be stocked in the rules.
Liraal is correct in what i'd like to do. Os installs on a per machine basis.

Sebra, on 19 March 2012 - 01:53 PM said:

He can do it on his server and he know it. Why not just do it for self?

It would be nice out of the box, so that people can write and share scripts without "well you need to hack bios.lua in this very specific way because my software is expecting it to act like the boot loader information is located in ___", I'll probably be hacking my server's OS scripts (simply out of necessity of this sooner rather than later), but it would be much more awesome for players to be able to download full OSes from the site here that aren't just hacked onto the current bios.lua's boot sequence… which leads to a bit of fun securing the OS against dropping the the original shell and a bunch of other nasty behavior with protected variables and "classes" that could be expanded in a larger OS deployment (my current project).

It's like how we have bios in computers now, give us a common entry point for an entire ground up OS, as opposed to "well we can all implement our own firmware so that everyone has a different boot sequence".



Also a lot of complicated software writing is done offline, which requires us shipping custom ROMs to end users, it's an easier request that we have a little tweak in the default BIOS then support for ROM shipping and selection (or basically EEPROM emulation). A huge benefit for minor change (and I'd be willing to make the changes and submit them for review). However it's also tempting to ask for some writable memory for the BIOS so you can fully configure boot devices (so I can't throw a disk at your PC and gain full control), but I can probably actually implement it and the protection for it in BIOS (would be nicer for the ComputerCraft engine to emulate a small chunk of flash memory).

I am not against it. I'm just too dumb to see actual suggestion. (if it was really described)
Is not startup enough to load different os? If I'm not mistake redworks os installs from external disk on each comp.

If I understand StrangeWill right, some kind of bios rewrite access wanted.
Are you want comp/turtle behaive as disk drive when placed on another comp untill first time turn on? This would allow to rewrite rom directory one time for each comp.

Sebra, on 19 March 2012 - 05:29 PM said:

I am not against it. I'm just too dumb to see actual suggestion. (if it was really described)
Is not startup enough to load different os? If I'm not mistake redworks os installs from external disk on each comp.

The problem at least for me is that bios.lua calls shell, which is an entire environment that will wrap whatever you have run, however I'm a bit more paranoid about OS security, any minor tampering can allow you to drop to the base shell and have full OS access around everything. On top of that a lot of my code is spent overriding what was done in the previous scripts.

I currently also just jack into the startup script, but the problems above still plague the software and require basically dirty hacks to (attempt to…) prevent.

On top of that it protects a lot of objects I wish to expand upon (fs and peripherals I've already expanded for additional functionality) are locked down.

If I understand StrangeWill right, some kind of bios rewrite access wanted.
Are you want comp/turtle behaive as disk drive when placed on another comp untill first time turn on? This would allow to rewrite rom directory one time for each comp.

That is correct, I would more shoot for some kind of BIOS rewrite in the sense of how computer BIOSes are like today: ROM/EPPROM firmware (ROM is fine), small flash memory (password/config), small boot menu (disable remote boot, secure BIOS, boot order, boot from device), and the ability to look for a boot sector (look up /boot of the device) and raw peripheral device support, most of the current bios would probably get moved to /rom/boot, and installing custom software to /boot will allow for a custom ground-up OS, and of course /disk/boot for bootable disks.

Well, for my OS I changed bios.lua, so it looks for a file called "boot", if it exists it loads it, otherwise it loads CraftOS (saved in "rom").
I made 2 boot files, one searches any installed OSes (files with .startup extension), and shows a menu to choose the one you want to load. The other one only loads my OS, so you can't use CraftOS or another one to see it's files (secure version).
This way you can have a normal computer with CraftOS, and other one with the OS you like.
Of course, you should have to load every API (since CraftOS is't loaded, wich loads the APIs), but I think that if you want to make an OS you should write your own (like I did, with some basic APIs copied :D/>/>), but it makes it more secure (and terminate safe).
If the writable rom is implemented this could be easier, since you just need to change the rom in the computer you want, but it works for now :)/>/>

MysticT, on 19 March 2012 - 05:59 PM said:

Well, for my OS I changed bios.lua, so it looks for a file called "boot", if it exists it loads it, otherwise it loads CraftOS (saved in "rom").

Yeah, it's an option, but annoying that my users can't load your OS (if you published it on the site here), the benefit for a unified BIOS boot procedure would be much the same it was for PCs.

MysticT, on 19 March 2012 - 05:59 PM said:

This way you can have a normal computer with CraftOS, and other one with the OS you like.
Of course, you should have to load every API (since CraftOS is't loaded, wich loads the APIs), but I think that if you want to make an OS you should write your own (like I did, with some basic APIs copied :D/>/>), but it makes it more secure (and terminate safe).

It allows you to also write bare firmware if you don't want to load all those APIs, so it can be very useful to pick and choose (also allows me to not load APIs that may allow users to circumvent security by writing nasty scripts).

MysticT, on 19 March 2012 - 05:59 PM said:

If the writable rom is implemented this could be easier, since you just need to change the rom in the computer you want, but it works for now :)/>/>

It doesn't even so much need to be writable, and to be honest I'd probably argue that bios.lua does a lot more than it should emulating BIOS.

I think, given my (bad) experience with SMP CC, that writable ROM is a really bad idea (i mean it). However, a slight modification to bios.lua, that allows you to make an 'autorun.ini' (or whatever) file to determine how os loading should take place, is certainly worth taking into consideration.

And why you think one time writable rom is bad?
For now startup change os loading in some way. What you want to change?

Sebra, on 19 March 2012 - 06:16 PM said:

For now startup change os loading in some way. What you want to change?

My preferred method:

Load config from flash (each computer gets it's own flash, only accessible by BIOS).
Wait 5 seconds on BIOS screen (ctrl enters menu, allows for config editing and securing your configs with a password).
Load boot device order
On each device path, look for existence of /boot
If boot exists, execute.
If not, next boot device.
If out of boot devices, load ROM OS (CraftOS).

I'd have no problem writing this and submitting it.

Just a primary idea, but allows you to load whatever you want and secure boot orders.

I like where this is going….

Sebra, on 19 March 2012 - 06:16 PM said:

And why you think one time writable rom is bad?
For now startup change os loading in some way. What you want to change?

writable rom - computers being bricked forever by hackers. There are ways to bypass everything and from which you cannot reasonably protect yourself. Another idea: a bootloader peripheral, that does all the boot loading, but which you don't have to use.

StrangeWill, on 19 March 2012 - 06:26 PM said:

My preferred method:

Load config from flash (each computer gets it's own flash, only accessible by BIOS).
Wait 5 seconds on BIOS screen (ctrl enters menu, allows for config editing and securing your configs with a password).
Load boot device order
On each device path, look for existence of /boot
If boot exists, execute.
If not, next boot device.
If out of boot devices, load ROM OS (CraftOS).

I'd have no problem writing this and submitting it.

Just a primary idea, but allows you to load whatever you want and secure boot orders.

So you need Dan200 to implement bios-accessable memory.

Liraal, on 19 March 2012 - 06:33 PM said:

Sebra, on 19 March 2012 - 06:16 PM said:

And why you think one time writable rom is bad?
For now startup change os loading in some way. What you want to change?

writable rom - computers being bricked forever by hackers. There are ways to bypass everything and from which you cannot reasonably protect yourself. Another idea: a bootloader peripheral, that does all the boot loading, but which you don't have to use.

If rom can be rewrote only one time before first boot, how hacker can intrude?
And how can your bootloader help if hacker can have it?

Sebra, on 19 March 2012 - 06:46 PM said:

StrangeWill, on 19 March 2012 - 06:26 PM said:

My preferred method:

Load config from flash (each computer gets it's own flash, only accessible by BIOS).
Wait 5 seconds on BIOS screen (ctrl enters menu, allows for config editing and securing your configs with a password).
Load boot device order
On each device path, look for existence of /boot
If boot exists, execute.
If not, next boot device.
If out of boot devices, load ROM OS (CraftOS).

I'd have no problem writing this and submitting it.

Just a primary idea, but allows you to load whatever you want and secure boot orders.

So you need Dan200 to implement bios-accessable memory.

In a perfect world, yes. If we wanted just a simple boot sector setup without all the fancy jazz, no… but I'd say "hey, implement the flash memory for BIOS and make the system 1000x better". Mainly: implement BIOS after real world BIOS.

First priority is a better BIOS, everything else is frill.



As for hackable systems:

Hacking eachothers OSes is going to be half the fun. :)/>/> It's why I'm securing mine away from shell… Always keep backups? :D/>/>

Because we all know that the second we notice someone's house is secured by a computer prompting for a password…

We immediately try to circumvent it. :D/>/>
That is the fun… I'm going to try and secure something… and StrangeWill is going to try to break it…
If that wasn't a fact-of-life in minecraft (people trying to get in) then we wouldn't have a reason to lock doors in the first place…

will, hacking is not fun when it's being conducted by the way of client hacks that allow you to make a copy of a terminal and do with it whatever you want and the change will affect the original as well. There is NO protection against it, of which I am sure because my software got hacked, possibly without even physical access. THAT is what I am against, not in-game hacks (which i quite like), but adding a writable ROM is like giving a griefer a ton of TNT. It's not my call to make anyway, but I am just stating my point. And about the bootloader, you an easily ban items from your server, but you cannot ban a part of code of a mod.

Liraal, on 19 March 2012 - 08:27 PM said:

do with it whatever you want and the change will affect the original as well.

Oh yeah, you never should be able to edit any shared resources such as the ROM directory that is automatically shared. If machines were to get EEPROM it would have to be on a per-machine basis.

It's not a far cry from the current setup.

Right now we have os code, term macros and other stuff shoved in BIOS.lua. what I suggest and have done for my setup. Is made BIOS do little more than look for potential boot devices. Disk the hdd them rom. Then boots the first available in that list. After that its the boot loader then to the os itself.

Sure it's 2-3 more files in the boot process but the added seperation means that if I don't like the standard included os I don't have to use any of it. No shell, no os.shutdown override in BIOS… etc…

New os installs just drop an image in /boot, background services are fired from /etc/init.d and then the shell.

It's a lot more steps but they're small and it makes it flexable.

Oh and most importantly everything is properly environmented off and in pcalls… so regardless of any failures in the system ALL coroutines are finished and cleaned up before shutdown.