Hardware Enforcement of Boundaries on the Control, Space, Time, Modularity, Reference, Initialization, and Mutability Aspects of Software

This application is a continuation of U.S. application Ser. No. 17/461,563, filed, Aug. 30, 2021 entitled, “HARDWARE ENFORCEMENT OF BOUNDARIES ON THE CONTROL, SPACE, TIME, MODULARITY. REFERENCE, INITIALIZATION, AND MUTABILITY ASPECTS OF SOFTWARE”, which claims priority to and was a continuation-in-part of International Application No. PCT/US2020/029406, entitled “HARDWARE ENFORCEMENT OF BOUNDARIES ON THE CONTROL, SPACE, TIME, MODULARITY, REFERENCE, INITIALIZATION, AND MUTABILITY ASPECTS OF SOFTWARE”, which was filed on Apr. 22, 2020, which claims the benefit of Provisional Application No. 62/837,145, filed Apr. 22, 2019, entitled “HARD OBJECT: HARDWARE ENFORCEMENT OF BOUNDARIES ON THE CONTROL, SPACE, TIME, MODULARITY, REFERENCE, AND MUTABILITY ASPECTS OF SOFTWARE”. The aforementioned applications are hereby incorporated herein by reference.

U.S. application Ser. No. 17/461,563 also claims one or more inventions which were disclosed in Provisional Application No. 63/071,934 filed Aug. 28, 2020, entitled “HARDWARE ENFORCEMENT OF BOUNDARIES ON THE CONTROL, SPACE, TIME, MODULARITY, REFERENCE, INITIALIZATION, AND MUTABILITY ASPECTS OF SOFTWARE”. The benefit under 35 USC § 119 (e) of the United States provisional application is hereby claimed, and the aforementioned application is hereby incorporated herein by reference.

The invention pertains to the field of microprocessor systems, more particularly, the invention is directed to hardware enforcement of boundaries on the control, space, time, modularity, reference, initialization, and mutability aspects of software implemented within the microprocessor.

This application is related to the following patents filed by one of more of the present inventors, which are hereby incorporated herein by reference: U.S. Pat. Nos. 8,364,910, 9,934,166, 9,569,612, and 9,935,975.

Software correctness and security are critical to modern computing infrastructure: people now use mobile phones for banking and computers now drive cars. Further, in a networked world, software by different authors often intimately cooperates on the same machine: plug-ins, mash-ups, and mobile code are increasingly common examples.

It is currently beyond the state of the art to construct software such that abstraction violations, whether errant or malicious, never occur. Today all attempts to achieve partial solutions to this problem exhibit one of three pathologies: the extreme isolation of separate address spaces, the clumsy bluntness of a type-safe runtime, or the nightmarish tedium of formal verification.

As a result, the domain of software is buggy and unsafe. Engineers who build machines made of atoms (rather than of bits) rely on locality of causality to make machines behave correctly in the presence of failure or attack: cars have a firewall between the engine and the driver; houses have walls and a lock-able door between the inside and the outside.

However, hardware engineers have worked diligently to eliminate all locality of causality within software: that is, on a modern computer, within a given memory space, any instruction can access any data. Hardware engineers did this because giving software engineers such freedom makes it easy for them to write programs that do what you want; however, having this much freedom also makes it easy to write programs that do what you really do not want.

The problem of correctness is intractable at scale. Therefore, a strategy is needed that gives software engineers the power to enforce sufficient locality of causality upon software such that the problem of correctness becomes tractable.

According to one embodiment of the present invention, a method for regulating an execution of a program on a computer by a microprocessor is disclosed, wherein the microprocessor has instruction pointers, the pointers including a page-index. The method comprises: providing at least some of said pointers with an object-id; providing a metadata map from at least one of the pointers to at least one object metadatum; and implementing the metadata map using a data structure mapping from the page-index and the object-id of the at least one pointer to the at least one object metadatum.

According to another embodiment of the present invention, a method for regulating an execution of a program on a computer is disclosed. The method comprising: providing said computer with data addresses, some of said data addresses comprising data, providing said computer with a read instruction which reads data from a target data address and with a write instruction which writes data to a target data address, annotating at least one of said data addresses with a written-flag, and providing said computer with an unwritten-indicator-datum. When a write instruction writes to a target data address, performing the following steps: setting said written-flag annotated onto said target data address to true, when a read instruction reads from a target data address, performing the following steps: checking if said written-flag annotated onto said target data address is set to true, if not, making said read instruction read said unwritten-indicator-datum instead of said data at said target data address.

According to another embodiment of the present invention, a method for regulating an execution of a program on a computer is disclosed. The method comprising: providing said computer with instruction addresses, some of said instruction addresses comprising instructions, providing said computer with a call instruction which calls to a target instruction address, annotating at least one of said instruction addresses with a mod-owner-id, and annotating some of said instruction addresses with a may-call-suff-len. When a call instruction at an instruction address attempts to call to a target instruction address, performing the following steps: checking if said mod-owner-id annotated onto said instruction address matches said mod-owner-id annotated onto said target instruction address, except for the rightmost bits of length of said may-call-suff-len annotated onto said target instruction address, if not, raising a fault.

According to another embodiment of the present invention, a method for regulating an execution of a program on a computer is disclosed. The method comprising: providing said computer with instruction addresses, some of said instruction addresses comprising instructions, providing said computer with a bit array mapping at least one instruction address to an instruction address meta-datum, providing at least one instruction address meta-datum with a intra-func-dyn-target-flag, and providing said computer with a dynamic jump instruction, said dynamic jump instruction comprising a target instruction address. When a dynamic jump instruction attempts to transfer control to a target instruction address, performing the following steps: using said bit array to map said target instruction address to instruction address meta-data, finding said intra-func-dyn-target-flag of that instruction address meta-data, checking if said intra-func-dyn-target-flag annotated onto said target-address is set to true, if not, raising a fault.

The invention disclosed herein is called “Hard Object” (“HO”) and a specific implementation embodiment of it referred to as “Dewdrop”.

Hard Object is:

Hard Object allows a program author to enforce various kinds of locality of causality in software, comprising the following properties:

Some perhaps non-obvious consequences of those properties:

Some platforms speak only in the familiar: in a C program running on Unix®, any data can be touched by any code in the process. Other platforms speak only in the formal: in a Java® program, a programmer cannot implement an xor bidirectional list, as pointers may not be xor-ed in Java®. In contrast, Hard Object speaks both the familiar and the formal, allowing the program authors to decide where the boundaries are. Consider, for example, an xor-bidirectional-list module which exports pointers to list objects and also maintains internal node objects.

Hard Object is a software platform that can speak in both the formal and the informal in this way, just as human natural languages do. As the external pointers may not be forged, they may act as object-granularity capabilities. Further, although the informal pointers may be forged, the modularity aspect of Hard Object prevents the client from using these informal pointers to access the module-internal objects. The point is that, if desired, Hard Object provides a way to be creative by turning off the formal constraints locally. While the resulting module would need to use another method to ensure correctness locally, such as a theorem prover, the theorem it would need to prove would be local.

Hard Object protects you from others; Hard Object does not necessarily protect you from yourself (though sometimes it does anyway). Hard Object assumes that module authors will act in their own self-interest and therefore if given the tools to protect themselves will do so. This assumption vastly simplifies the problem and allows the programmer to control the transition between the familiar and formal modes above. That said, memory-safety is guaranteed by default, and if a module turns off any aspects of memory-safety, such as is required for the internal nodes of an xor-bidirectional-list, doing this cannot compromise the safety of another module.

This familiar-and-formal feature of Hard Object removes the brittleness which defeats all other competing prior art systems. All systems guaranteeing properties of the execution of a program both (a) provide constraints that the user wants and (b) require further constraints so that those provided can be made to work; the tension between these two kinds of constraints is the heart of the problem. Competing prior art systems attempting to provide similar guarantees to those of Hard Object are either (1) weak: provide to few constraints and therefore do not solve the problem (e.g. Crash-safe/Dover Microsystems®, Mondriaan Memory Protection) or (2) brittle: require too many constraints and therefore become unusable for certain necessary tasks (e.g. Java®), and then, recognizing this, provide an escape hatch (e.g. Java® Native Interface calls) which when used causes all guarantees to be lost all at once. Hard Object does not exhibit this brittleness. Do note that in computing this simultaneous combination of both soundness of guarantee and flexibility of expression (that is, strength without brittleness) is a property more difficulty to achieve than one may at first imagine, and yet is critical to any infrastructure that is going to be entrusted with our whole lives, as we have done with computing.

This familiar-and-formal feature alone makes the difference between Hard Object and all other competing prior art systems. All systems guaranteeing properties of the execution of a program both (a) provide constraints that the user wants and (b) require further constraints so that those provided can be made to work; the tension between these two kinds of constraints is the heart of the problem. Competing prior art systems attempting to provide similar guarantees to those of Hard Object are either (1) weak: provide to few constraints and therefore do not solve the problem (e.g. Crash-safe/Dover Microsystems®, Mondriaan Memory Protection) or (2) brittle: require too many constraints and therefore become unusable for certain necessary tasks (e.g. Java®), and then, recognizing this, provide an escape hatch (e.g. Java® Native Interface calls) which when used causes all guarantees to be lost all at once.

Hard Object is a very lightweight intervention to the hardware and software of existing system design. The current Dewdrop design and software embodiment/implementation of Hard Object is a modification of the 64-bit version of the prior art RISC-V® instruction set architecture (“RV64”), riscv-gnu-toolchain, the RISC-V® support libraries, and the musl libc [musl-libc] C library. Throughout, this detailed description speaks of an embodiment of Hard Object implemented as an augmentation/modification of the prior art RISC-V® system; this detailed description does not explicitly repeat the phrase “in one embodiment” in each such case, and therefore it is made explicit here that the fact that the RISC-V@ embodiment is only one embodiment of Hard Object is to be understood every time RISC-V″ is mentioned.

The modifications Hard Object makes to a standard prior art system amount to the following:

In one embodiment, toolchain modifications are implemented entirely as source-to-source transforms. Hard Object is so lightweight that it does not alter the base compiler toolchain at all (there is not even a Hard-Object-specific compiler: the Hard Object system just uses the standard riscv-gcc compiler, albeit the build process augmented by being interleaved with Hard Object source-to-source transforms). Though the standard compiler toolchain is not altered, the whole build-load-run process is altered by adding further stages, most of them using source-to-source transforms; note that, while doing so, Hard Object supports nearly all of theoptimization flags turned on by gcc-O2:

Minor changes to standard system software and libraries:

Observer design: The observer design allows the original chip design to remain almost unchanged and therefore allows Hard Object to be merely attached to any CPU, such as a prior-art RISC-V® machine. This factoring is realized as a software hard-object-observer simulator that observers/intercepts the risev-spike simulator.

Low to zero programmer annotation burden: Porting C code to Hard Object to the point of having memory safety amounts to changing a single line in the Makefile to replace gcc with the Hard Object compiler-driver script. The only C idioms that Hard Object currently does not support automatically, and that would therefore require a manual porting process, are if the program has written its own memory allocator, did non-pointer like things with pointers (xor-ing them), or did some other very rare things that even real-world highly-optimized C does not seem to ever do that would trigger Hard Object corner cases. If the programmer gets more clever the changes required to the user program are proportional to the desired cleverness.

Hard Object is absolute: when Hard Object guarantees a property, that guarantee is absolute, not best-effort: the enforcement of the Hard Object properties do not depend on an assumption that a hash function will never collide or that a counter will never roll over. Further, correctness does not rely on the toolchain modifications; if the user does not use the modifications to the Hard Object software toolchain but runs the Hard object hardware, the Hard Object properties will be enforced, but the program will not run as it will very likely violate a Hard Object check. Further, one module need not trust the compiler of another module: multiple mutually-untrusting C modules may run and interact within the same address space and yet be protected from each other.

Hard Object is hardware-naive: All of Hard Object is “naive” in the sense that Hard Object assumes that the abstraction layers below Hard Object do not fail. While Hard Object does not introduce Spectre/Meltdown-style vulnerabilities, Hard Object does not attempt to enforce/maintain the instruction/data abstraction, so Hard Object does not protect against, say, hardware side-channel attacks that leak crypto keys through process timing or the heat signature of the processor. Hard Object also does not attempt to maintain the transistor/electronics abstraction, so Hard Object does not protect against attacks that abuse the hardware itself, such as row-hammer, or attacks that use the effects of external radiation, such as a hair-dryer or cosmic rays.

Hard Object not only improves the correctness and security of existing software, just as virtual memory before it, but enables software to be architected in a new way.

Hard Object makes sandboxing untrusted code straightforward. The module is the granularity of trust: the correctness of a module depends on everyone who is an author of the module and all the tools used to build the module; further the correctness of a module does not depend on the authors or tools used to build other modules, other than the trusted system modules.

Factoring a program into even just two modules can make a dramatic difference in reliability. Consider factoring a complex editor into two modules: (1) a pretty graphical user interface (GUI) having only ephemeral state and (2) a database holding the important document state. The GUI module can export a restart( ) function that forgets all its state and re-queries it from the database module. Now, when the GUI module faults, the kernel sees its restart function and so just reboots the GUI module, leaving the database running, and thereby preserving the important document state. By putting the screen and cursor positions into the database as well and using video double-buffering to hide the screen flash, one can envision an editor getting multiple null-pointer exceptions per second while the user does not even notice and simply keeps working. Editors could be designed this way now, but doing this is so heavyweight due to the coding and performance impact of factoring the program across processes, that programmers mostly just do not go to the trouble.

The Hard Object design separates the problem of use-after-free from the problem of garbage, thereby removing garbage collection as a necessary mechanism for providing memory safety. Garbage collectors can never be made to work well: Hertz and Berger [hertz-berger-2005] estimate that the Java® garbage collection means three to five times as much memory is required to obtain performance equivalent to a program without garbage collection. Hertz and Berger states:

The resulting version collector is a better than garbage collector in several algorithmically fundamental ways: unlike, garbage collection, version collection is easily made parallel, concurrent, memory-hierarchy-friendly, and if done often enough, never leaves dead memory in the client program (whereas garbage collection requires dead memory before it can even do something useful). That is, by separating the use-after-free problem from the garbage problem, Hard Object has fundamentally improved the situation.

Providing capabilities: Hard Object makes it straightforward to turn normal objects into capabilities. Using capabilities, Hard Object eliminates ambient authority: code may not access any object to which it has not been explicitly given a reference (formal pointer); doing this alone is a dramatic improvement in computer security. Hard Object allows building software using the prior art Capabilities design at the object granularity, however Hard Object does not require software to use Capabilities.

Deconstructing the kernel: Hard Object system, or “dangerous”, code is much safer than prior art kernel mode. Hard Object dangerous code can alter metadata on any code, but its loads and stores are still subject to the constraints on said metadata. Therefore, a static analysis of a Hard Object kernel can use the fact that the Hard Object boundaries are still enforced. While dangerous system code is trusted, it is much less likely to accidentally change any metadata than it is to accidentally make a wild write.

Hard Object makes it dramatically easier to build a micro-kernel:

Hard Object also makes it straightforward to build an exo-kernel: software running on a Hard Object system has no need for the narrow user-kernel boundary, allowing the user code direct access to kernel data-structures in a safe way, as, again, the kernel is just another module. Large buffers of data coming off of disk or network no longer need be copied from kernel space to user space: instead the kernel can just transfer the ownership of the object to the user program. Further, note that there is no need to throw an existing monolithic kernel out and write a new one as an existing kernel can simply be factored gradually into a micro-exo-kernel.

One may envision a “micro operating system” comprising a micro-kernel, drivers, a scheduler, a file system, a network stack, and a portable user interface (UI) library (web browser widgets), and not much else. When the kernel is tiny and, say, also formally (machine-checked) proven correct, why not simply burn it into the firmware? When web apps are native apps, why have installed apps? When all the refactoring is done, a Hard Object system ends up resulting in something much closer to the dream of an information appliance.

Here are some of the design aesthetics or meta-idioms that were used while making choices in the construction of Hard Object:

Simple is not minimal, simple is well-factored: Hard Object restores locality of causality to software. Viewed from a correctness perspective, by providing these primitives Hard Object factors the proof of correctness of a program so that

Hard Object refactors the responsibilities between software and hardware in a way that removes far more complexity from the software than it adds to the hardware. This complexity removed is quite significant, complexity for which the undecidability of the halting problem means there is no answer. A premise of Hard Object is that the resulting whole is much simpler than the current organization of software and hardware, that is, that simple is not minimal, simple is well-factored. Hard Object provides properties very similar to what Java® attempted to provide, only in a lightweight/deconstructed manner that also works in the kernel and admits of a smooth path to adoption for C and C++ programmers. Hard Object is what Java® should have been.

Semantics of software locality provided by Hard Object: Here are the semantic properties provided by Hard Object in terms familiar to a C programmer. All memory pages are marked as data or text (code). Some operations are “dangerous” (dangerous operation) in that they are powerful enough to destroy the guarantees provided by Hard Object altering metadata and saving ephemeral data to heap/global memory; these dangerous operations are intended to be used only by trusted system code. Some functions are labeled as “dangerous”, meaning Hard Object allows them to perform dangerous operations.

Constraints of Hard Object are conjunctive: each aspect of Hard Object puts constraints on an action by a program and for an action to be allowed all of the relevant constraints must be satisfied (a more flexible system could be easily built by simply being less strict about this requirement, but such a system might be annoying for the user). Throughout this detailed description, the phrases “check that P(x)” or “x must be P” (where P(x) is some predicate) mean “if not P(x) then the Hard Object system faults to a trusted system handler and this handler gets all the details of the fault”.

Each flow-chart figure demonstrates only one aspect of Hard Object being operated/enforced, but a given instruction or operation by the computer is operated/enforced by many aspects of Hard Object. If one were to attempt to make figures which showed for a given instruction or operation all of the Hard Object aspects which are checked when that instruction or operation is performed then the figures would be unreadably complex and would not fit on a page and no benefit would come from looking at them.

Therefore, instead the figures depict how the checking of one part of one aspect of Hard Object is done. This means, however, that since a single instruction or operation has multiple aspect of Hard Object checking it and that these multiple aspects are depicted in multiple figures, that there must be some way to combine the results from the multiple checking illustrated for a single instruction or operation.

When describing Hard Object, this detailed description often refers to “pages” of memory, by which this detailed description means the standard prior art partitioning of memory into pages (such as in a system using prior art virtual memory). However, in this detailed description pages are used only for annotating metadata onto ranges of memory, and any other system allowing for the annotation of metadata onto ranges of memory could possibly do the same job and thus be usable in conjunction with Hard Object. So by “pages” this detailed description means any mechanism of annotating metadata onto ranges of memory addresses.

When describing Hard Object, this detailed description often refers to “registers”, by which this detailed description means the standard prior art practice of collecting bits of state in a CPU and naming them so they at times may be thought of or operated on as a single noun/object. This detailed description refers to two kinds of registers: those that are part of the CPU that Hard Object observers/intercepts (“CPU registers”), and those that are added by Hard Object (“HO registers”). Some CPU designs have instructions that are register-oriented, using registers for the input and output of most operations (“register machines”), such as the prior art RISC-V® 64 system, whereas other CPU designs may organize computation differently, not necessarily using registers as the organizing paradigm for moving data around, such as pushing and popping data to/from the stack (“stack machines”) or flowing the output of one operation directly into another. or possibly some other paradigm.

Hard Object annotates metadata onto user text and data, and it is these annotations and the properties that are used to enforce the heart of the Hard Object system. This detailed description refers to an embodiment that is natural for a register machine, such as the prior art RISC-V® 64 machine, and therefore uses register-machine (and in particular RISC-V® 64) terminology. That said, any other system that allows annotations of Hard Object metadata onto the relevant data and text could possibly be made to work with Hard Object. So by “register” this detailed description means any method of collecting data and treating it as a unit of data, text, or metadata, independent of whether that collection of data is manifested literally as a prior art register mechanism, as long as it serves at function of providing semantics as a unit when its value is needed by the operation that needs it.