daohub-io / cap9 Goto Github PK
View Code? Open in Web Editor NEWCapability-based security protocol for smart contracts
License: Apache License 2.0
Capability-based security protocol for smart contracts
License: Apache License 2.0
We need to include a test where:
account#call
capability (type 0x09
), that designates it is allowed to make a call to Contract X
.Tests must use #procedure_delete_cap(uint8 capId, string procId, uint8 targetCapId)
in BeakerContract.sol
We need to include a test that:
0xdeadbeef
and a procedure delete_cap capability (type 0x2
) that allows it to share one or more of it's capabilities from cap table to another procedure.0x8
) for key 0xdeadbeef
, this write capability must be the same as Procedure A.Procedure creation should be 2 steps:
We need to define an opcode solidity parser
With the upcoming adoption of the EWASM execution format, we need to come to a decision on which execution format to support in the near future.
Current development of the kernel prototype in EVM1 has been relatively smooth, but solidity has been proving itself difficult for more granular tasks and tests. This has lead to convoluted solutions and issues revolving custom memory alignments and storage addresses, namely #18 and #8.
EWASM on the other hand already has substantial toolchain support. Since it is a strict subset of the Wasm, debugging tools are already available (chrome, firefox) and can be written in rust as a compilation target in the form of pwasm.
In comparison with Solidity as a language, Rust can provide us substantially more granular control with better ergonomics.
Migrate to EWASM as our default target for the kernel, but support procedures targeting EVM1.
What needs to go into the whitepaper? What design detail is needed and what isn't?
We want to have the code and the format for a procedure to write an arbitrary, 32-byte value to address 0x07
. This should be executed via a capability attached to a procedure. This will be the basis from which we extend to other capabilities.
Not necessary until the end, but I'm making an issue so we don't forget.
Following on #43, we need to separate the current Kernel.sol
into a library and Instance.sol
.
We need to figure out which issues are the most important to address.
For Daohub-io/beaker-cli#17, we need to document in detail how we do post-deployment procedure verification.
We can put this either in the Procedure Creation section or OCCV section in the whitepaper.
Currently, how a procedure c-list and process c-list interact is still ambiguous. I would additionally propose we define the lifetime of a capability: from creation to revocation. To elaborate, a capability in a procedure is born with a procedure being created, and is revoked when the procedure is destroyed. A capability in a process however can either live once per process or be stored within a procedure, but can still be hypothetically revoked.
We need to document capability values as a reference. Such as the values of the Procedure#Call
capability type: #64 (comment)
Following #55 and #44, procedure#clist
is a heterogeneous list of capability types, and requires parsing in order to access a capability by index. This makes syscalls more expensive and also doesn't take advantage of a clist that could contain multiple capabilities of the same type and size.
In order for a procedure to contain multiple capabilities of the same type, we need to seperate the procedure#clist
into a list of separate lists of homogenous capability types.
While this would make indexing faster, it brings additional complexity which needs to be addressed. This should be done after #44 in a separate PR.
During exec
, when a caller mints a new capability for a callee, does the capability point to the caller's c-list or the callee's c-list? If the latter, why would this require the caller to pass on a pointer if the callee can simply lookup it's c-space?
We need to include a test that:
0x2
), that designates it is allowed to execute procedure B.0x7
), that designates it is allowed to write to address 0x7
.0x7
.We need go through all the basic resources and actions involved during procedure execution.
To start, we need to validate an procedure for not having:
We need to include a test where:
0x10
), that designates it is allowed to read how much gas it's has received.9000
gas and Procedure A reads how much gas it received using it's gas#received capabilityWe need to decide whether we block GAS
opcodes or include a separate capability #53.
Currently the write capability is hard coded, but we need to change that into a data structure that can handle multiple types of capabilities.
It looks like the current view on capabilities is a simple one where each procedure is assigned a list of capabilities. This precludes the need for minting, delegation, and the like. Currently, some of the design docs include this functionality. We need to update these design docs for this simpler system. Current work towards this is included in the design docs under Proposition B.
Currently, in ProcedureTable#_getProcedureByKey
, the keys are not seperated by procedure size, which means procedure chunks could potentially overlap. To fix this, we need to make sure that procedure pointers are seperated by at least the size of a procedure. (4 keys?).
Tests should use #read(uint8 capId, uint location)
in BeakerContract.sol
We need to include tests for a procedure that:
type 0x7
, that allows it to read an arbitrary, 32-byte value from address 0x07
. This capability must be stored at index 0
.We need to specify how to call a procedure from another procedure. I'm referring to this as a system call, as we need to work out the whole mechanism, not just the capability.
We need to include a test that:
0x9
) that allows it to log event from a memory buffer with 0xdeadbeef
always as the first parameter.Hello World
into memory and invokes it's log capability to log 7HelloWorld
as a result.For procedure message passing, we have the option of making use of the ETH ABI as procedure endpoints, and thus explicit objects in the kernel, or not.
Currently the error codes are hardcoded integers, which should be enums.
Tests should use library function #proc_entry(string id)
in BeakerContract.sol
We need to include a test where:
0x6
) that allows it to designate a new entry procedure from the procedure table given an id.Currently there are many functions of the kernel that are exposed directly to external transactions. Most if not all of these functions should be limited by capabilities. The first stage would be to simply move these functions into an example entry procedure (with the necessary caps). This would allow for the same testing, but also force everything through the capability system.
The following functions are still exposed:
setEntryProcedure
createAnyProcedure
createProcedure
deleteProcedure
executeProcedure
These functions are exposed and should probably be removed, but are not critical for security:
listProcedures
returnRawProcedureTable
returnProcedureTable
getProcedure
For #9, we need to have a table that shows the stored procedures available.
To start develop we need to determine what is missed in current Beaker Os specification.
We need to figure out how storage will be shared and protected between procedures running within the same context. Because storage is available as a Merkle-Patricia Tree, we need to figure out how to separate access of X nodes and their paths between N procedures.
Storage Format: https://github.com/ethereum/wiki/wiki/Patricia-Tree
Create a draft list of all the kernel objects we expect to encounter.
By kernel object we mean something that is held and controlled by the kernel. Examples include procedures and capabilities. It is usually expected that these objects are interacted with via some interface and/or capabilities.
Based on #9, we need to decide how procedures can be owned and destroyed. This can either be done through some sort of code injection, or we simply don't handle ownership at all.
While interoperability will probably be served be having an operating system like Beaker, is that really it's intention? or is it merely one of it's features.
We need a language analysis report that compares the different languages available that are used currently for writing Smart Contracts.
Notably: Serpent, Solidity, etc
Reports should include:
Reading the current draft from docs/Usage.md
, it's not clear to me how the user can clearly know which capability needs to be minted or invoked.
For example, when I see this:
let &cap2 = mint(&cap1, param)
let ret = invoke(&cap2,"data")
It's not clear when cap1 can be used to invoke
or mint
something. What happens if I invoke(&cap1, "data")
?
Test should use #procedure_delete(uint8 capId, string procId)
in BeakerContract.sol
We need to include a test that:
0x3
) that allows it to delete Procedure B based on it's id.We've been defining storage capabilities of procedures based on address ranges, but we don't place the kernel storage (such as the procedure table) in a defined address range, therefore we cannot prevent access.
The kernel storage needs to be allocated in a defined range.
We need to brainstorm what's the best way to protect kernel memory from procedure memory.
Memory: https://github.com/ethereum/wiki/wiki/Subtleties
Yellowpaper: https://ethereum.github.io/yellowpaper/paper.pdf (Page 11?)
When executing a procedure we need to make sure:
STATICCALL
instead of DELEGATECALL
.STATICCALL
to prevent them at runtime.As an example, when accessing SSTORE
, this proposal incurs the additional cost of aSTATICCALL
, it remains to be seen if it is cheaper to simply encapsulate an opcode than to do context switching.
Split up kernel.js
as it is getting too big.
Tests should use #proc_register(uint8 capId, bytes32 procId, address procAddr)
in BeakerContract.sol
We need to include a test that:
0x4
) that allows it to push a new procedure to the procedure table.We need to create a rudimentary procedure table, it should be able to:
As we are doing the whitepaper in the docs/ folder the wiki can be removed for now. All information has been migrated to docs/.
When the Procedure table #9 runs a delegateCall
, it may be vulnerable to jumps into it's kernel stack frame. To prevent this, during contract validation and creation, memory access must be restricted.
To start with we need to create a Factory contract that receives a sample contract instructions as payload and creates it.
Tests must use #procedure_push_cap(uint8 capId, string procId)
in BeakerContract.sol
We need to include a test that:
0x7
) for key 0xdeadbeef
and a procedure push_cap capability (type 0x1
) that allows it to share one or more of it's capabilities from cap table to another procedure.0xdeadbeef
from a memory buffer.We need to address how a kernel instance is deployed, how it is instantiated and how we can test it.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.