Intermediate commit.

Makefile.in

@@ -11,8 +11,8 @@ iso9660: zambesii.iso
 
 # For my personal use. (~lp).
 imm:
-	cp -f zambesii.zxe /media/hddExtended/zambesii.zxe
-	cp -f zambesii.iso /media/hddExtended/zambesii.iso
+	cp -f zambesii.zxe /media/dv6-e01/zambesii.zxe
+	cp -f zambesii.iso /media/dv6-e01/zambesii.iso
 
 zambesii.iso: exec
 

core/Makefile.in

@@ -16,7 +16,8 @@ EXECOBJS=__kthreads.a __karchThreads.a kernel.a archKernel.a firmwareCore.a \
 	floodplainn.a \
 	platformCore.a chipset.a chipsetCore.a archCore.a firmwareCore.a \
 	__kclasses.a __kstdlib.a __kcxxabi.a libx86mp.a libacpi.a \
-	libzudiIndexParser.o libzbzcore.a udi_index.o
+	libzudiIndexParser.o libzbzcore.a udi_index.o \
+	drivers.a metalanguages.a
 
 GOAL=../core.o
 

core/__kclasses/cachePool.cpp

@@ -6,10 +6,10 @@
 
 cachePoolC::cachePoolC(void)
 :
-poolNodeCache(sizeof(cachePoolNodeS))
+nCaches(0), poolNodeCache(sizeof(cachePoolNodeS))
 {
 	head.rsrc = NULL;
-	nCaches = 0;
+	if (debugCheck() != ERROR_SUCCESS) { *(int*)0 = 0; };
 }
 
 cachePoolC::~cachePoolC(void)
@@ -27,9 +27,17 @@ cachePoolC::~cachePoolC(void)
 	};
 }
 
+error_t cachePoolC::debugCheck(void)
+{
+	return poolNodeCache.debugCheck();
+}
+
 void cachePoolC::dump(void)
 {
-	printf(NOTICE CACHEPOOL"Dumping.\t\tNCaches: %d.\n", nCaches);
+	printf(NOTICE CACHEPOOL"Dumping. nCaches: %d. Dump nodecache:\n",
+		nCaches);
+
+	poolNodeCache.dump();
 
 	head.lock.acquire();
 
@@ -183,6 +191,7 @@ slamCacheC *cachePoolC::getCache(uarch_t objSize)
 	return NULL;
 }
 
+#include <__kclasses/memReservoir.h>
 slamCacheC *cachePoolC::createCache(uarch_t objSize)
 {
 	cachePoolNodeS	*node;
@@ -197,6 +206,7 @@ slamCacheC *cachePoolC::createCache(uarch_t objSize)
 	};
 
 	node->item = new slamCacheC(objSize);
+
 	if (node->item == NULL)
 	{
 		ret = NULL;

core/__kclasses/slamCache.cpp

@@ -1,4 +1,5 @@
 
+#include <debug.h>
 #include <arch/paging.h>
 #include <__kstdlib/__kflagManipulation.h>
 #include <__kstdlib/__kcxxlib/new>
@@ -11,27 +12,35 @@
 
 slamCacheC	*asyncContextCache;
 
-slamCacheC::slamCacheC(uarch_t objectSize, allocatorE allocator)
+slamCacheC::slamCacheC(uarch_t _objectSize, allocatorE allocator)
 :
 allocator(allocator)
 {
-	heapCacheC::objectSize = (objectSize < sizeof(objectS))
+	objectSize = (_objectSize < sizeof(objectS))
 		? sizeof(objectS)
-		: objectSize;
+		: _objectSize;
 
 	// Calculate the excess on each page allocated.
 	perPageExcess = PAGING_BASE_SIZE % objectSize;
 	perPageBlocks = PAGING_BASE_SIZE / objectSize;
 
 	partialList.rsrc = NULL;
 	freeList.rsrc = NULL;
+
+	if (this == (void*)0xC0061394) { rr = 3; };
 }
 
 slamCacheC::~slamCacheC(void)
 {
 	//FIXME: Find a way to destroy these things...
 }
 
+error_t slamCacheC::debugCheck(void)
+{
+	if (perPageBlocks == 0) { return ERROR_UNKNOWN; };
+	return ERROR_SUCCESS;
+}
+
 void *slamCacheC::getNewPage(sarch_t localFlush)
 {
 	switch (allocator)
@@ -85,12 +94,12 @@ void slamCacheC::dump(void)
 	objectS		*obj;
 	uarch_t		count;
 
-	printf(NOTICE SLAMCACHE"Dumping; locks @ F: 0x%p/P: 0x%p.\n",
-		&freeList.lock, &partialList.lock);
+	printf(NOTICE SLAMCACHE"@0x%p: Dumping; locks @ F: 0x%p/P: 0x%p.\n",
+		this, &freeList.lock, &partialList.lock);
 
-	printf(NOTICE SLAMCACHE"Object size: %X, ppb %d, ppexcess %d, "
+	printf(NOTICE SLAMCACHE"@0x%p: Object size: %X, ppb %d, ppexcess %d, "
 		"FreeList: Pages:\n\t",
-		objectSize, perPageBlocks, perPageExcess);
+		this, objectSize, perPageBlocks, perPageExcess);
 
 	count = 0;
 
@@ -189,6 +198,7 @@ void *slamCacheC::allocate(uarch_t flags, ubit8 *requiredNewPage)
 		partialList.rsrc = tmp;
 
 		// Break up the new block from the free list.
+printf(NOTICE"New block @0x%p, will be broken into %d blocks, %dB each\n", tmp, perPageBlocks, objectSize);
 		for (uarch_t i=perPageBlocks-1; i>0; i--)
 		{
 			tmp->next = reinterpret_cast<objectS *>(

core/__kstdlib/icxxabi/callConstructors.cpp

@@ -1,18 +1,35 @@
 
+#include <debug.h>
 #include <__ksymbols.h>
 #include <__kstdlib/compiler/cxxrtl.h>
+#include <__kclasses/cachePool.h>
 
 status_t cxxrtl::callGlobalConstructors(void)
 {
 	void (**ctorPtr)();
 
-	ctorPtr = reinterpret_cast<void (**)()>( &__kctorStart );	
-	for (;
+	ctorPtr = reinterpret_cast<void (**)()>( &__kctorStart );
+	for (uarch_t i=0;
 		ctorPtr < reinterpret_cast<void (**)()>( &__kctorEnd );
 		ctorPtr = reinterpret_cast<void (**)()>(
 			(uarch_t)ctorPtr + sizeof(void *) ))
 	{
 		(*ctorPtr[0])();
+		i++;
+
+		if (rr == 3 && cachePool.debugCheck() != ERROR_SUCCESS)
+		{
+			asm volatile(
+				"movl	%0, %%eax\n\t"
+				"movl	%1, %%ebx\n\t"
+				"movl	$0x2b201234, %%ecx\n\t"
+				:
+				: "r" (ctorPtr[0]), "r" (i)
+				: "ebx", "eax");
+
+			// c0007b8c
+			for (;;);
+		};
 	};
 
 	return ERROR_SUCCESS;

core/__kthreads/x8632/__korientationMain.cpp

@@ -146,7 +146,6 @@ static void dumpSrat(void)
  *
  * We then pass control to __korientationMain().
  **/
-void do_stuff(char);
 extern "C" void __korientationInit(ubit32, multibootDataS *)
 {
 	error_t		ret;
@@ -207,7 +206,6 @@ extern "C" void __korientationInit(ubit32, multibootDataS *)
 	 **/
 	DO_OR_DIE(memReservoir, initialize(), ret);
 	DO_OR_DIE(cachePool, initialize(), ret);
-	DO_OR_DIE(__kprocess.zasyncStream, initialize(), ret);
 	asyncContextCache = cachePool.createCache(sizeof(syscallbackC));
 	if (asyncContextCache == NULL)
 	{
@@ -221,6 +219,7 @@ extern "C" void __korientationInit(ubit32, multibootDataS *)
 	 * BSP CPU's scheduler to co-op level scheduling capability, and
 	 * spawn the __korientationMain thread, ending __korientationInit.
 	 **/
+	DO_OR_DIE(__kprocess.zasyncStream, initialize(), ret);
 	DO_OR_DIE(cpuTrib, initialize(), ret);
 	DO_OR_DIE(zkcmCore.cpuDetection, initialize(), ret);
 	DO_OR_DIE(cpuTrib, initializeBspCpuStream(), ret);

core/include/__kclasses/cachePool.h

@@ -42,10 +42,11 @@ public allocClassC
 
 public:
 	cachePoolC(void);
-	error_t initialize(void) { return ERROR_SUCCESS; };
+	error_t initialize(void) { return poolNodeCache.initialize(); };
 	~cachePoolC(void);
 
 	void dump(void);
+	error_t debugCheck(void);
 
 public:
 	slamCacheC *getCache(uarch_t objSize);

core/include/__kclasses/slamCache.h

@@ -61,6 +61,7 @@ friend class memReservoirC;
 	status_t flush(void);
 
 	void dump(void);
+	error_t debugCheck(void);
 
 private:
 	struct objectS

core/include/kernel/common/distributaryTrib/dvfs.h

@@ -7,6 +7,7 @@
 	#include <kernel/common/vfsTrib/vfsTypes.h>
 
 #define DVFS_TAG_NAME_MAXLEN			(48)
+#define DVFS_PATH_MAXLEN			(128)
 
 #define DVFS_DINODE_VENDOR_MAXLEN		(64)
 #define DVFS_DINODE_VENDORCONTACT_MAXLEN	(128)

core/include/kernel/common/vfsTrib/hierarchicalStorage.h

@@ -5,7 +5,8 @@
 	#include <__kstdlib/__kclib/string8.h>
 	#include <kernel/common/vfsTrib/vfsTypes.h>
 
-#define HVFS_TAG_NAME_MAXLEN	(256)
+#define HVFS_TAG_NAME_MAXLEN		(256)
+#define HVFS_PATH_MAXLEN		(256)
 
 namespace hvfs
 {
@@ -190,7 +191,7 @@ namespace hvfs
 		:
 		vfs::currenttC(static_cast<utf8Char>( 'h' )),
 		rootTag(
-			CC"Zambesii Hierarchical VFS Currentt", vfs::DIR, 
+			CC"Zambesii Hierarchical VFS Currentt", vfs::DIR,
 			&rootTag, &rootInode),
 
 		rootInode(
@@ -245,7 +246,7 @@ namespace hvfs
 
 		class slamCacheC	*tagCache;
 		tagC			rootTag;
-		dirInodeC		rootInode;			
+		dirInodeC		rootInode;
 		sharedResourceGroupC<multipleReaderLockC, defaultTreeInfoS>
 			defaultTree;
 	};

docs/security-basic-thoughts.txt

@@ -0,0 +1,89 @@
+Security is achieved in Zambesii through a combination of components.
+	* Levee perms API:
+		Controls the actions a process may perform at a fine level of
+		granularity. This is a configurable bitmask of actions that a
+		program may or may not perform.
+
+		Levee API determines what /actions/ can be performed by a
+		process, while clearance determines what /data/ can be read
+		by a process.
+
+		Each account has a set of "operating" perms, and "potential"
+		perms. The potential perms are represented by the bitmask value
+		that describes the most permissive state that can be achieved
+		by a process running under that user's session.
+
+		The operating perms are the subset of the user's *potential*
+		perms which s/he has decided that the kernel should allow
+		applications to exercise without ASKING first.
+
+		This enables a highly privileged user to put up safeguards on
+		their usage of the system, while having the expressiveness and
+		power of a high-privilege account at their fingertips.
+
+	* User accounts:
+		User accounts identify a user, enabling user-based policy to be
+		implemented and enforced.
+		The kernel only cares about accounts, and it does not care about
+		credentials. The kernel does not know about any credential
+		scheme, and accounts do not imply a username+password credential
+		scheme.
+
+		Each user accounts has a clearance level and a set of levee
+		perms for which privileged actions it can take on resources.
+
+		A higher-privileged user may choose to "Vouch" a lower
+		privileged user for a particular operation. In this scenario,
+		the vouched user gains temporary access of a certain level
+		for a certain amount of time. The voucher is required to
+		authenticate their credentials in order to vouch.
+
+	* Authentication credentials:
+		Credentials and the authentication of the same, are not handled
+		by the kernel, but by separate processes. These processes are
+		configured within the kernel's initrd configuration.
+		The credentials processes are servers for a particular
+		type of credentials and their authentication.
+
+		For example, username+password challenge-response login is one
+		type of authentication criterion, and a password credential
+		authenticator would be assigned to listen for attempts to log-in
+		via the username-password method.
+
+		Fingerprint scanning is another, eye-scans, etc, etc all are
+		different authentication methods.
+
+		An interesting side-effect of this way of thinking is that
+		PROGRAMS can be authenticated based on credentials as well. E.g,
+		an important program such as a web server will usually need to
+		"log in" as a particular user, usually with some level of
+		elevated privilege to perform its functions.
+
+		If such programs are required to log-in via an MD5 hash check of
+		their binary, the security of the system is greatly increased.
+
+	* Confidentiality levels:
+		These are applied to files. Every file has a confidentiality
+		level attached to it, and only users who have clearance
+		privileges greater than or equal to the clearance level of the
+		file can access it.
+
+		A file may also have a policy that allows users of a certain
+		clearance to *read* their data, but not to *modify* it.
+		Files have READ, WRITE and EXECUTE confidentiality levels.
+
+		A system-critical program for example, may have a low EXECUTE
+		confidentiality, but high READ and WRITE confidentiality.
+
+	* Clearance levels:
+		Each user has both potential and operating clearance levels.
+		The potential clearance level is the highest level of
+		clearance the user has. The operating clearance level is the
+		maximum level of confidential access that should be allowed
+		without ASKING the user first. This enables the user to set
+		a low operating clearance level, while having a high *potential*
+		clearance level.
+
+		User clearance levels are three-fold: READ clearance, WRITE
+		clearance and EXECUTE clearance. That is, a user may have a
+		high EXEC clearance, but a low READ and WRITE clearance.