Doesn't pick up prefs

[rustleg]

I installed the 64 bit version on a 80GB hard drive as before, but it won't read the prefs from the extra storage space on this drive. There aren't any sticks plugged in.

Unfortunately the PC's configuration has been modified since I ran the RC (which picked up prefs ok) so maybe something in this configuration changed that would have caused the same problem with the RC. What I did was to add another 2 drives so I could use them to test KNOS versions without messing up the main KNOS installation which I will use for banking. Now it has 6 drives = 4 SATA, including the 80GB drive I have installed KNOS on, plus 2 80GB IDE drives I intend to use as test beds. At present these 2 drives each have just a single FAT32 partition created by Terabyte's Bootit. I tried putting the KNOS prefs file on each of these partitions in case it was looking at them for reading the prefs, then rebooting, but no joy.

I guess I could try installing on one of the other 80GB drives but I'd prefer a suggestion before trying something more as I'm just shooting in the dark here.

[Kevin McAleavey]

It's possible that Bootit is the problem, as mentioned in the other reply in:

knosproject.proboards.com/index.cgi?action=display&board=knos9&thread=192&page=1

KNOS' boot record is special and unyielding in the interest of security. So that's definitely likely to be part of the issue. However if you're able to get KNOS up and running on any of those misbehaving machines, be sure to have the stick and the drives in question plugged in and all that good stuff and send me a copy of the diagnostics on each, letting me know which is which and maybe there will be some info as to what's going on there. Unfortunately, KNOS expects a normal BIOS bootup and no more than four "Windows-like 'partitions'". Anything else is going to be a no-go since we do not honor any boot partition other than the one built into KNOS once BIOS tells us which drive we're on.

KNOS will not accept any boot sector's information other than its own and it expects to find it in that very first sector once it knows where it is. It's the only way we can guarantee that no outside force will compromise our security.

[rustleg]

Ok I'll email the prefs to you on the 64 bit machine as this one does boot from a hard disk installation. Unfortunately just can't get anything other than the DVD to run on the 32 bit machine. But I'd like here to understand if the Terabyte boot manager's gyrations really do interfere or not with KNOS. My feeling is that it doesn't since KNOS runs off a hard disk in the 64 bit machine which isn't the first hard disc specified to run in the BIOS and this worked for the RC.

Just to be clear how I understand the boot process I will explain in detail - perhaps you may find some flaw in this.

As I understand it what happens at boot time is that BIOS looks for the device first in its list of bootable devices (which can be set by the user modifying the BIOS options which are retained across reboots and power cycles). Assuming there are no floppies or CD's present if they are ahead of a hard disc in the list, that BIOS specified hard disk's MBR is used to boot the system. The MBR might contain GRUB or other boot loader (in my case Terabyte's own boot code) and also a partition table and (maybe after user chooses which system to boot) it then transfers control to some boot code in the boot sector of the relevant partition.

So when I run KNOS which has its own dedicated disk but which is not the disk specified to boot in the BIOS, control starts in the MBR of the Terabyte controlled hard disk. At this point what it does with each hard disc depends on whether you have given it permission to fiddle with the MBR of the disk. If so you can actually create up to 250 or so primary partitions and when you choose which system to boot it puts the relevant 4 in the partitions table so that the rest are merely "free space" as far as any OS is concerned. It then transfers control to the boot sector the relevant partition. Or you can tell the boot manager not to fiddle with the MBR and just use a fixed standard 4 partition MBR.

In my case 2 of my first 3 disks have 5 partitions defined but KNOS is on a different disk (HD4) which initially had one FAT32 partition covering the whole drive before I installed KNOS. After KNOS was installed Terabyte sees that the partition type has changed to xBSD but doesn't mess with it. In running KNOS I specified that the partition tables of the first 3 drives pointed to: HD1 and HD2 nothing, HD3 - two FAT32 partitions (130GB, 120GB for testing large FAT partitions), HD4 - KNOS, HD5/6 one 80GB FAT32 (last 3 drives all 80GB) - these last 2 are destined for extra KNOS installations for testing, but not yet installed.

When running the RC I didn't have 2 of the 80GB drives in, just ran KNOS on one 80GB IDE drive. This time KNOS is on an 80GB SATA drive. Maybe I should try installing KNOS on one of the 80GB IDE drives instead and see if that helps. I intend to do that anyway but wanted to see if I could get the prefs sorted first.

I'm not quite sure how I could have got KNOS RC to work in this situation before if as you say "Once KNOS queries BIOS for the location of that drive ... then KNOS takes it from there, ... From the BIOS pointing to which device is the KNOS drive, it then seeks its own boot sector which is hard-coded." When I ran the RC, KNOS wasn't the BIOS's boot drive but it ran fine and the release does also for the 64 bit version. KNOS seems to know which drive it is on and also sees the FAT32 partitions on HD3 - from this I assume it does use the disk's partition table. So the fact that Terabyte's boot manager has preloaded this table with certain partition locations is irrelevant assuming those entries are correct. Apart from that the only thing that the boot manager does is get KNOS started in the first place - which it does ok for the 64 bit version. Provided the boot manager hasn't done anything to the KNOS disc post installation (which I don't believe it has) it's activity is all pre KNOS startup so it shouldn't be a problem.

[Kevin McAleavey]

Your understanding of the "normal" boot0 methods are largely correct. If you were to install the normal distribution of BSD and allow it to format for a typical server build, it too would behave as expected. However, because of the risk of boot sector infectors, we've designed KNOS differently in order to ensure that nothing can "hitch a ride" in there in KNOS and somehow get underneath our operating system. Indeed, we have the normal "boot0" in the MBR, but ours is different.

Out "boot0" is exactly 446 bytes in length, and unlike traditional MBR's, does not point to a volume identifier. In other words, it is not possible to relocate KNOS to another drive location once installed because the identification for the rest of the boot sequence (boot1, boot2 and loader) are fixed in location. In other words, you can't move the drive around or boot0 won't find boot1 or the rest. This is done to prevent any other code from finding its way in to load earlier than the rest of our system, and the various pieces of the KNOS boot cycle are SHA256'd and mtime'd in order to ensure that they haven't been modified in any way. From there, install installs an image of the DVD with repoints to the location that it was installed into. So if you installed it into a "drive 5" then you're OK although that will introduce a few oddities since it's absolutely not expected in a realm where normally you can only have a maximum of 4 devices total (including a CD/DVD as one of those) in the classic BIOS setup.

In your case, you're actually on "drive 6" since we count from 0 on the ada interface, so I'm already surprised that your boot manager even worked with us that well ...

Filesystem Size Used Avail Capacity Mounted on
/dev/ada5s1a 3.3G 2.9G 104M 97% /
/dev/msdosfs/COMMON 117G 6.4G 110G 5% /media/Common
/dev/msdosfs/KTEST 74G 17M 74G 0% /media/Ktest
/dev/ada5s1d 68G 84M 62G 0% /media/disk
/dev/msdosfs/KBANK 74G 17M 74G 0% /media/Kbank

However, your "s1d" (which is your personal area) is never going to work because the allowances in the boot sector won't allow devices above ada2 to "exist" since ada3 is reserved for being a "CD/DVD" in the normal scheme of things. And a boot manager is not going to follow the standards we go by because that's past the boot area and won't be probed by KNOS. Therefore, the problem is that you've moved KNOS out to a non-standard area whereas we designed things to expect the boot drive to turn up as the first drive, maybe the second, even went over the wall and are looking for a possible third drive to be booting from, and that's assuming only that KNOS would be on the first drive and perhaps there might be two others in addition to our boot drive that data might be saved to.

During the bootup, when KNOS looks for saved preferences, there is a cost of five seconds of additional boot time for each "test" to see if there's KNOS data on there. When we find data, we don't have to look any further and thus bail out and continue the bootup. And so, as it is, we search for 3 hard drives and 3 USB drives which totals just shy of 30 seconds of wasted bootup time. It's really not practical to double that delay "just in case" we're in some exotic location such as "drive 6" unfortunately. And we're not coded to go past that third in the boot sequence as it is.

What I would suggest then is to move that KNOS drive down lower in the food chain. If you don't want to put it in the first drive boot location, you'll need to make it either the second or the third drive in your chain. And unfortunately, since it's already formatted in that sixth location, you'll also need to reinstall KNOS once it's been moved to a more "suitable" location because we hard code the drive location into our boot cycle for security. Once it's in a more fitting location, then your personal will show up as well once your drive is either ada0, ada1 or ada2 ... apologies for the confusion, we never expected to see any configuration like this.

But that'll be the reason ... keeping bad things from happening by tightening down the likely unexpected. Our design paranoia in locking down the boot sequence is "what would happen if the boot sector was made to point elsewhere before calling the proper sequence in order to insert a bootkit/rootkit?" That's why we designed things this way.

[rustleg]

OK thanks for the detailed reply. I'll try shifting the drives around and maybe remove one of the 3 KNOS drives so I can get the FAT32 partitions in the 3rd drive. Will let you know how it goes.

[Kevin McAleavey]

May 22, 2012 7:22:26 GMT -5 rustleg said:

OK thanks for the detailed reply. I'll try shifting the drives around and maybe remove one of the 3 KNOS drives so I can get the FAT32 partitions in the 3rd drive. Will let you know how it goes.

Knowing how things work tends to make the decisions easier and better.

[rustleg]

May 23, 2012 0:21:19 GMT -5 Kevin McAleavey said:

May 22, 2012 7:22:26 GMT -5 rustleg said:

OK thanks for the detailed reply. I'll try shifting the drives around and maybe remove one of the 3 KNOS drives so I can get the FAT32 partitions in the 3rd drive. Will let you know how it goes.

Knowing how things work tends to make the decisions easier and better.

I fiddled around with different combinations of drive positions and in the end had to revert to a more standard PC setup with 4 drives - actually 4 hard drives plus DVD. I have the KNOS drive in slot 2 (since I need my main drive in slot 1 to startup with the boot manager).

Pleased to say it works now - prefs are picked up from the extra space on the KNOS drive. It seems that your insistence on the system checking for itself what hardware is in there does not allow the distortion that my boot manager makes to the standard PC setup.

Although this is less flexible than I had hoped for, it does give comfort that KNOS's security isn't going to be messed about with, which is precisely why I bought KNOS. So many thanks for designing a secure system.

[Kevin McAleavey]

Yeah, unfortunately all those years of chasing down malware to eradicate it only to find out WHY it was able to sneak into Windows, then Linux and then Macs kinda caused me to take a different approach to the norm with KNOS. BSD, unlike other OS', has some interesting and unique capabilities which we put to use in what we built here.

We've strived to do a reasonable balance between security and "usability" but decided that security was the more important specification in each decision. Sorry for that inflexibility there, but allowing any path to compromise was something we really couldn't do. More than four drives in a BIOS-based machine was a surprise. Thanks for the kudos ... avoiding plagues was the entire reason for KNOS.