Define system bootstrap #130
Comments
|
Another way we could do it would be similar to how we do it in tests: if the length of the procedure table is zero, you can register any procedure which would be set as an entry proc. |
|
They key question then is "by what mechanism do you register a procedure?". The reason I proposed a default entry proc is that it will perform any registration via the syscall mechanism. This means that the kernel only has the one interface, syscalls, which I think is great from a simplicity and security perspective. All complexity to do with bootstrapping is then pushed into this initial entry procedure which can be deleted immediately after bootstrapping (at the user's discretion). There is also some other logic which that bootrap entry proc will need to contain. For example, who can bootstrap the kernel? Presumably only the person/account which deployed it. If we don't have a bootstrap proc but rely on the kernel to do that registration and authentication, then that's more complexity we need to bake in to the kernel which will probably only used once. Here's my proposal: As part of the constructor/deployment code of the kernel you must supply a single Ethereum address. This address will be registered as the first entry procedure (procedure name TBD) with all capabilities. So the procedure will be as follows:
|
|
Ok, let's do that with the constructor in a separate |
This commit gives TestKernel a constructor which takes an initial entry procedure. This required test changes throughout. The implementation will need to be updated to have a better architecture, but this implements the concepts and updates tests for compatibility. The next steps will be to move it to a level lower then TestKernel and abstract some of the initial cap setup. The concept is documented in in issue #130.
|
A proof-of-concept of this was included in #129 and the tests have been updated to match. It's currently just sitting in TestKernel. Next step is to move it to a better location once I get a better handle on the interactions of constructors and inheritance. |
This moves the constructor and bootstrap mechanism to another layer in KernelInstance.sol, as per #130.
|
KernelInstance.sol has been created and the boostrap has been moved to that. |
|
Something to be careful of is now that we have |
* Remove last references to push and delete caps * Update proc table and cap formats (no minting) This updates the procedure list and procedure heap to use the correct formats. It does not attempt to address minting and delegation and simply allows anything to be registered. Minting and delegation will be addressed in a later PR. * Test updates for new formats. * Implement maximal caps * Implement subsets * Test registration of Call caps * Test registration of Write caps * Test registration of Log caps * Various test fixes and redesign * Critical fix for Delete cap * Minor test fixes * Remove Procedure struct from registration path * Add some utility functions for tests May seem a little verbose but it's a first step in reducing the boilerplate of tests. Currently we've avoided that, but the test have grown to large and we need to start abstracting bits. * Test procedure re-registration This required some error code plumbing to be done. I also removed one of the checks that returned an error code if the procedure name already exists. This way we only check that problem once rather than having unreachable code. * Remove erroneous .only * Correct error code * Test zeroing of clists at registration (see #129 for: at deletion). This is a quick patch that sets the clists to zero length before registering. The final choice for how we deal with clist deletion is to be made in #129. * Remove old hack for tests There use to be a special cap class to monkey patch the fact that the capIndex value it not passed through correctly. This is now fixed. * Fix SetEntry tests * Missing changes from last commit * Restructure files and inheritance * Update tests to restructure * Added missing files * Remove deprecated error values * Set the kernel address in preparation for execution guard * Constructor bootstrap proof-of-concept. This commit gives TestKernel a constructor which takes an initial entry procedure. This required test changes throughout. The implementation will need to be updated to have a better architecture, but this implements the concepts and updates tests for compatibility. The next steps will be to move it to a level lower then TestKernel and abstract some of the initial cap setup. The concept is documented in in issue #130. * Add KernelInstance.sol This moves the constructor and bootstrap mechanism to another layer in KernelInstance.sol, as per #130. * Set the kernel address in the constructor. * Address comments * Add missing arrow to architecture diagram
|
Closing this on resolution with #129 |
Now when we register procedures we need to include a "source" capability from which we derive a subset. The problem is, how do we define the first procedure? From where does it source its capabilities?
I believe the best solution is that the kernel comes with a default entry procedure that is locked to the account which is deploying the kernel. This entry procedure will pass syscalls directly from the owner to the kernel. It is then up to the owner to deploy the correct restrictions etc. Different organisations will require different initialisation and handover protocols, but this should handle them all in general.
The text was updated successfully, but these errors were encountered: