Project Logs

Collapse

• FRUTE and Scheme

  Yann Guidon / YGDES • an hour ago • 0 comments

  https://frute.net/ proposes a LISP machine-like environment.

  There are interesting ideas but

  1. POSEVEN does not mandate a given programming language
  2. Tagged memory is an industrial dead end.

  POSEVEN does not tag the memory, but implicitly the pointers, since the MSB already segregate the functions/access types. The applications are responsible for correctly handling the values and types. It's a reasonable compromise and structures such as #aStrA : Aligned Strings format with attributes  do a reasonable job at embedding information in the pointers.

  Furthermore, the data space can not contain pointer to code and no instruction is allowed to access (read, write or execute) the stack or the code areas. It is not possible to "leak" info in any direction. And since the data stack and control stack are split, the major "type confusion" attack (on the mixed stack) is prevented.

  Tagging each memory location increases memory word widths (or reduces useable space) and requires either a dedicated circuit, or code to check the type. This is not a reasonable requirement and experience with early (non-optimising) Ada compilers is a lesson from 4 decades ago.

  Asianometry has covered (superficially) LISP machines and I'm sure Duane will add more context and depth. But POSEVEN can not rely on word-granularity types. However, pages could be a good place to enforce this.

  LISP machines have a certain appeal, just like Forth machines. But their flexibility is reduced to a certain class of applications, not those that POSEVEN targets.

• POSEVEN on x86

  Yann Guidon / YGDES • an hour ago • 0 comments

  Looking at Linux, one would think that POSEVEN would be hard to adapt to the x86 / x86-64 platform.

  But most of the basic infrastructure is already there ! it just has been mooted by the flat-layout UNIX kernels.

  The trampolines are not there, but can still be emulated with a trampoline trampoline ;-)

  But the 3 main memory spaces (+IO) are already part of the x86 architecture with the segments.

  "Segments are slow!" but they serve important purposes that have been sacrificed on the alter of raw performance. Today, the prefixes make almost no difference when x86 CPUs run at 2, 3 even 4GHz !

  • DS, ES : data segments.
  • CS : code segment.
  • SS : Stack segment
  • IN and OUT instructions already exist

  It's all here and implicit. Linux (and xBSD) just make them point to the same flat memory area.

  FS and GS are extra features that are not even required.

  So a quasi-POSEVEN kernel is possible on x86. Not that I want to get into this horrible mess again but I could at least NASM my way out of it easily.

  Of course, there would be strong limitations:

  • At least for most modules, segment prefixes are not allowed, as they would be the prime method to circumvent protection. The kernel would be allowed, though.
  • Playing with SP would be forbidden. Only PUSH/POP (POPA or PUSHA would be OK)
  • Only immediate calls and jumps/branches are allowed, so no computed jumps.

  These could be enforced by modification of the assembler. But given the hardware's nature, it can only "emulate" POSEVEN (and quite fast, at that) but can't ensure all the safety guaranties. So that would be a good way to prototype and demonstrate the principles and get the first system in working condition without having to write a JVM or something like that.

  It's feasible in a VM, at least, or with a bootstrap from FreeDOS.

  The risk would be to get carried away with all the x86-specific "features" and taint the pure RISC philosophy.

• Ideas to choose from Plan9

  Yann Guidon / YGDES • 10/19/2026 at 17:48 • 0 comments

  After several years of work on one project, when it hits too many roadblocks, I often have this tradition: See everything that worked and what didn't. I keep what worked and do the reverse of what hadn't worked.
  I usually do this for my CPUs but here, let's talk about operating systems. POSEVEN is not an OS nor my second, but we can look at others and see what ultimately failed. I've ranted a LOT about UNIX because it's the main type in circulation (if you ignore MS Windows, but why wouldn't you ?)

  Now let's have a look at Plan 9.

  This post is inspired by a post by Arndt Mueller :

  Plan 9 from Bell Labs is a distributed research operating system created in the mid-1980s by the original creators of Unix (including Ken Thompson, Rob Pike, and Dennis Ritchie) as a planned successor to Unix.

  Key Concepts

  • Everything is a file: Building on Unix, Plan 9 extends the concept so that every resource, service, and device is represented as a file and accessed through a standard file tree.

  • The 9P Protocol (Styx): A lightweight network file protocol that allows local and remote file systems, hardware devices, and processes to be shared seamlessly across a network.

  • Per-process Namespaces: Each program can have its own customized, private view of the file system, a concept that later influenced modern Linux containers.

  • Native UTF-8: Plan 9 was designed and built to handle UTF-8 Unicode text throughout the entire system, shell, and text editors (like sam and acme).

  • Distributed Architecture: It was built to run across a network of specialized machines (separate CPU servers, terminal workstations, and storage servers like Venti) rather than a single monolithic computer.

  I must admit that I have a good amount of respect for Plan9, as I was (remotely) introduced to it around 1999-2000 at uni by my OS/CS prof Jean Méhat (RIP). It was to be the future... But still in raw form. Experimental, barebones and no practical use for it, yet, only distributed in binary blobs with an interface that was... terse.

  • Soon I would use the graphical interface port "9wm" on XWindow, regularly, a lot. It's small. It's simple. I even wrote an article about it. It's not the best but it's no fuss. I love simple things since they let me focus on the real work.
     
    So minimalist GUI : ok.
     
  • But I didn't use Plan9 for real. I could catch a few "party tricks" here and there as they filtered through Linux for example. That was... OK.
    Some applications are nice. Others are cumbersome. Since UNIX/POSIX loves treating/processing text streams, this creates a new problem: when you have complex resources, you must create complex parsers and serialisers. It becomes more work for both the driver and the userland program. And more attack surface.
     
    So I consider a dual track: some resources are "UNIX files" which is great for unstructured streams like regular files as well as /dev/random and such.
     
    But structured resources? They must be properly handled like the "objects" they are. I don't like objects but this paradigm has certain fundamental merits when well used. And the "modules" of POSEVEN are the right interface, even though they are binary. You can still make a binary<->text converter (an idea for another standard module... sounds a bit like regedit???)
     
  • The 9P Protocol (Styx):... A pretty great achievement. I like the idea though I don't know much more about it. And on POSEVEN nothing prevents you from transfering the IPC to a different machine using a buffer/translator/trampoline/surrogate module.
     
  • Per-process Namespaces: This translates to POSEVEN with each running thread having (inheriting and then updating) their own directory of available and "translated" modules. Alteration of the list and mapping to actual modules can be on-demand (for example selecting a particular revision of the module/service) or external (for example for debug, inspection, debugging or the module needing a translation layer,...

  Read more »

• Interrupts

  Yann Guidon / YGDES • 09/12/2026 at 17:16 • 0 comments

  Handling interrupts is very easy : these signals are treated like a IPC instruction.

  Each class of interrupt (such as maskable, non-maskable, system, IO, SW faults...) has a dedicated register with the n° of the thread (and its thread descriptor address) that manages it (plus a "ready" flag). Vectored interrupts in the class are managed through the IPC service n°. Thus there is very little special hardware to add, and no new instruction.

  A handling thread must be spawned ("pre-fork" in other contexts) before the interrupt source can be serviced.

  There is no other requirement (yet), there may be as many classes as necessary and possible.

  The interrupt registers are not specified yet.

• Auxiliary Input and Output space

  Yann Guidon / YGDES • 02/19/2026 at 22:03 • 0 comments

  Input and output (IO) is another critical resource but it's not the central feature of POSEVEN. It still needs to be specified !

  The Code, Data and Instruction spaces are essential but some modules may inherit access to a 4th space : IO registers.

  Access to this space is exclusive : each module (why limit to thread?) can access a range (only one range ?) of IO registers, which are rather fast, but must usually enforce access protocols.

  When a thread generates an input or output request, the IO target/peripheral compares the module ID or thread ID with a valid registered ID (configured by the core module). An ID mismatch will obviously trigger an exception.

  The single-server approach might look like it increases complexity and latency, becoming a bottleneck, but overall, it ensures a coherent multiplexing of the requests as the system scales up, preventing complex semaphores, mutual locks and race conditions.

  A particular IO module may receive simultaneous requests through IPC/IPE from several threads, but this leads to one single code, a single point of decision, simplifying arbitrage. There is no risk that one module mismanages a resource shared with another module using an outdated protocol, for example.

  Furthermore, large data blocks may be transmitted through the "shuttles" and queued during the IPC, and the main thread of the module will handle and serialise all the requests.

• The trampoline

  Yann Guidon / YGDES • 02/08/2026 at 23:42 • 0 comments

  A major feature of the POSEVEN specification is the trampoline zone at the start of the code area.

  One of the aspects is the protocol that preserves speed and security. Hardware protection makes it impossible to access accidentally but the module itself must participate with its own filtering code.

  The trampoline spans the lowest 64Ki-instruction page of the code area. Granularity would be 4 or 8 instructions so only 8Ki to 16Ki entry points (maximum) are possible.

  The trampoline zone is accessed directly from a different module by a special JUMP instruction called IPC, which expects to point to an IPE instruction. This ensure that random jumps or even scanning (spraying) do not work.

  Returning to the calling module goes through the IPR instruction, which must re-execute the calling IPC instruction to ensure the stack's integrity (and restore some registers) (so IPC is a two-mode instruction).

  IPE must be located at the first instruction of a cache line (otherwise: trap), for safety and speed. The rest of the cache line (and the following line(s)) may filter the parameter, and trap or return immediately in case of error, otherwise the code jumps to the actual code, outside of the small (somewhat) zone.

  IPR can be executed anywhere.

  -----------------------------------

  Since IPE can only exist at certain addresses, the OS loader (that configures the program) can simply scan the first 64K instructions of a program, looking for the IPE opcode, and re-create a table of valid entry points. This makes it easy to create new versions of a module that preserves the high-level entry points but implements it differently (as long as the entry points remain in the same order).

  The calling programs are distributed with binaries that IPC to an entry point number, and the loader must "relocate", translate that number to the actual address of the instruction. This lookup at load time removes expensive/slow runtime lookups.

  So this whole system ensures that a dynamic library, the kernel, an application, a device driver.... use the same and only one file format and structures, there is no special case to manage in the processor.

  The trampoline also defines the granularity of the pages for code : 64K instructions per page. This first page is always (or preferably) resident, in order to keep the system fast. And with 64Ki instructions per page, a module has a low maximum number of pages. Depending on the maximum number of bits of the Program Counter:

  • 20 bits : 16 pages
  • 22 bits : 64 pages
  • 24 bits : 256 pages 

  This lets the iTLB hold more simultaneous modules in cache. 

  ----------------------------

  Now what can the trampoline be compared to ?

  • for Unix, that would be _start and all the signal()s. Signals are asynchronous, so is POSEVEN, so there is an expectation of concurrency. Except that absolutely arbitrary signals can be sent to a module, any quantity at any rate with any parameter....
  • The trampoline is also inspired by the interrupt/trap structure of certain DSP/CPUs, so an IRQ can directly trigger a given codepath in a given module. 
  • For an object-oriented programming language, the trampoline correspond to the declaration of all public functions.
  • For Pascal, the trampoline is more or less the declarative part of a "unit". In fact, in POSEVEN, every module is a "unit", and the init system (ID0)  calls all the other units.

  So the trampoline makes all the entry points safely accessible, allowing filtering of the requests. It makes the OOP paradigm more visible at the OS/System level. It maps directly to many common programming paradigms.

  ------------------------------

  Remember :

  By default, any module may call any other module at any entry point. Spraying is not impossible and there is always the risk that "rogue discovery" takes place.

  Each module is responsible for filtering the callee : IPE provides the caller's ID and it must be compared (as well as capabilities) with safe callers. Some HW features...

  Read more »

• Memory model

  Yann Guidon / YGDES • 12/23/2024 at 02:02 • 2 comments

  A big part of the programming model is the memory model : the organisation of data in memory, their roles and restrictions...

  
  POSEVEN follows the CDI (Control/Data/Instructions) model and has three memory spaces (four if the IO ports are counted) that are independent from each other : a pointer for one space has no meaning in another space. All spaces can be paged out and cached, but the independence prevents one space from thrashing another's.

  1) Stack (the "Control" space)

  The first and most simple memory space is the control stack. It is not accessed directly or indirectly by the program, hardware directly manages the addressing and the pointers have tags automatically added to them to prevent any confusion. Each level of stack contains two words : a data word and a pointer+tags word. Each level counts as "one" increment of the stack pointer, there is also a couple of "limit" indices to help catch abnormal conditions. This separate and protected stack is essential for the implementation of fast and efficient calls to other modules. There is no special constraint to the size of the index or the stack area, but it is usually limited by the word size : 32 or 64 bits, though going 1 billion deep (30 bits) would be pointless (see here)

  The stack space is specific to the thread. Nothing else (except thread #0 and its surrogate) can access it, to preserve the integrity of the control flow. AFAIK, the only reasons to access it outside of the running thread is for setup/diagnosis/debugging.

  2) Program

  The second area is the "Instructions" space. All instructions are supposed to have the same size so incrementing the instruction pointer (PC) directly points to the next instruction (sorry : no gadget for your ROP). There is no data and the program can not read its own "data" from this space. This is a "black box" with no "introspection", meaning that no ROP (or other hacking) can occur. The code is immutable and only the source code can know what is where, apart from the IPE in the trampoline (see below).

  The address size for a module is limited to 24 bits, probably even 22 bits (amounting to 16MB). Or 20 maybe (TBD by the ISA). With such a small size, relative addressing is pointless and the module can address itself with direct addresses embedded in the opcodes. Indirect or computed addressing is strictly limited. If you need more, modularise your program, don't let it bloat!

  Each program space is specific to a module. An IPC instruction switches the current thread to a different module with its new program space. Pointers/instruction addresses for one module are irrelevant to a different module.
  

  The program space is mostly homogeneous. The exception is the first 64K instructions which, at certain aligned addresses, can contain IPE instructions to allow jumping from a different module.
  

  3) Data

  Data belong to their own space. It is not homogeneous in its function, but the structure is always the same: a linear space made of 8-bit bytes, with a pointer that is as wide as words (32 or 64 bits).

  The MSB of the address/pointer directs to one of four main areas: The top MSB is the private(0)/Public(1) flag. Other lower MSB divide this space even more, and the address generators can trap when a pointer calculation overflows or underflows, creating a pointer to a different sub-area.

  00 : Data Stack, where parameters and recursive short-term blocs are stored.
  

  01 : Local/Thread-private data (private heap, local/private data, variables)
  

  10 : Module shared data, constants, holding the module's state, semaphores, configuration...
  

  11 : Interchange area, used to allocate buffers that can be sent to other modules (message passing, "shuttles")
  

  A pointer or address has a different meaning and shareability depending on the area/MSB:

  - a private pointer (MSB=0) can't be shared at all and will have a totally different meaning in another thread.

  - a module-shared area pointer (10) can be shared among threads running...

  Read more »

• Basics

  Yann Guidon / YGDES • 07/11/2024 at 00:41 • 1 comment

  POSEVEN is based on a platform (with a proper mix of hardware and software features) that provides/implements the following two fundamental elements :

  1. Threads

  A thread is a stream of execution : a sequence of instructions that are fetched, decoded and operated upon, one after the other, with the eventual and conditional change in the sequence that is controlled by the program and/or external data.

  Nothing new here.

  A POSEVEN system may implement an arbitrary number of threads, which may be limited by hardware constraints.

  A thread can be started, paused, resumed, interrupted, frozen, thawed, swapped in/out or terminated at any time.
  

  A POSEVEN thread has a "global" context that contains

  • hidden, private and public properties
  • capabilities, access rights, tokens...
  • a protected stack space
  • a private as well as a shared data address space.

  A thread executes code from one module at a time.
  

  2. Modules

  A POSEVEN system hosts a number of modules: they contain an area of code to execute, associated with a common data memory area.

  The code is a static collection of instructions to be executed by a thread. The thread can switch from one module to another by "calling" entry points in the desired module's trampoline area, located in the first instructions of the module.

  The common data area is accessed only by the threads that execute the code of the associated module. Since any number of threads can execute a module simultaneously, all the code must be reentrant, and the relevant variables must be protected by semaphores, spinlocks or Mutexes.
  

  .
  

  Threat model

  POSEVEN imposes modularity to promote code reuse and contain/isolate the flaws. The POSEVEN system assumes that any thread or module could be "rogue". It is the implementer's job to ensure that the "kernel" module (#0) and the "kernel" thread (ThId#0) provide the appropriate "root of trust".
  

  Any module can call, or be called by, a module that is potentially altered (accidentally or intentionally) so a strict separation of the modules and threads is further required.
  

  Communication between modules and/or threads uses strict safe interfaces:

  • The trampoline area lets a module filter calls and decide which is legitimate. Each module enforces their own (potentially dynamic) policy, by reading the "capabilities" and other attributes of the calling modules & thread.
  • Data is shared through a common data addressing area, where pointers are valid for pairs of threads. One thread may read and the other may write (but not both).
  • Calling a module is often preceded by "shielding" the thread's data stack from reads & writes, and clearing all irrelevant registers to prevent any leaks. Extra data may be left over on top of the stack by a callee module, but it can't alter the data of the caller module.
  • Each thread has its own protected stack that can only be accessed by itself, in order, through specific instructions, to prevent leaks, alterations, ROP (Return-Oriented Programming). Only the kernel and an authorised debugger can access another thread's stack's contents.
  • Paged memory helps enforce some of the security policies and helps map, or remap, code and data areas. For example : page mapping allows a given thread to access the trampoline area of another module, which enables dynamical module substitution.
  • "Resources" (hardware-controlled) may only be accessed by the "kernel" (thread #0) or one other thread, whose number is set by the kernel. In other words : the kernel manages which thread may access a given hardware resource at each time, and only one thread may handle a peripheral at a time, preventing any contention or race condition.

  POSEVEN can not prevent hardware alteration or physical bypass of access rights/tokens. However it is designed to prevent, detect and isolate "unwanted" behaviour without getting too much in the way of an application, which is free to define its own policy. Adherence to security and safety rules is the responsibility of the system designer and implementation, but the...

  Read more »

• Name change

  Yann Guidon / YGDES • 12/16/2023 at 03:06 • 1 comment

  NPM is no more, welcome the new flashy and witty name :

  POSEVEN.

  Yes it's a deliberate pun, which seems to have been overlooked for decades, and the domain names seem uncluttered (yet). So I got .com as well. You never know.

  NPM was never intended to remain a definitive name for this projects/development/specification. Due to my ADHD, the name collision was a deliberate personal incentive to find a way better one, just like all those "project code names" names either Aurora, Nebula or Eclipse you see in the industry. I wanted to start the design without being hindered by the lack of a definitive umbrella name, and the ideas matter more than the label, just a few letters, put on them. But this lack was becoming a pain recently. Inspiration never warns anyway, and when it arrives, it strikes with its obviousness.

  It's seven characters long and I'd have loved a much shorter one but they are all taken already.

  What's after POSEVEN ? POEIGHT. So a system written using these principles would naturally be a POEM. Sweet, but now it's become totally corny.

  Anyway, I'm still considering this development in the background, while I work on other things like the #YGREC8. Stay tuned.

  .

  Update: #YGREC32 will be the first dedicated platform !
  

• SSS : the Single-Stack Syndrome

  Yann Guidon / YGDES • 09/08/2023 at 17:20 • 0 comments

  I remember as a teen, knowing BASIC and PASCAL, I explored the weird world of the 8086 so I could program it efficiently. And I was, and still am, scratching my head over (among other things) the concept of the stack as it was implemented by this CPU...

  I knew about stacks already, being familiar with the 6809. Stacks are cool and great. But the 8086 implements frames and contrived, uselessly elaborated. And you know what ? Stacks are one of the main weaknesses of x86, particularly when coupled with C's unbound and unchecked array, it's a highway to bugs.

  Stacks are one of the most fundamental structures in computer science and has been studied to death. Having a curiosity of FORTH, I know that a single stack is not a fatality as there are other programming languages with more than one. Indeed FORTH was creating on a computer featuring two stacks. Some languages also implement their own split stack under the hood. And that's very fine. So what happened ?

  Well, C happened more than 50 years ago and started on a PDP-7. Belonging to a certain tradition and having to run on tightly limited resources, having only one stack was a compromise that worked well enough for the time, the constraints, so it spread wildly and even overcame PASCAL.
  

  The single stack has one major problem in C : you can't return composite variables on the stack so function must resort to pointers and other stupid workarounds, which makes C a development hell once you go beyond the basic examples. The standard libs are a freak show. And I won't rant again about the insanity that comes from mixing control and variables data.

  The thing is : C structures (and the SSS) crystalized in many subsequent designs. Worse : it underpins modern compilers and processor architectures ! The syndrome turns into a plague.

  ---

  So...
  

  The NPM defines a strict split structure that separates data from control values.

  • The Control Stack is tightly controlled and only affected by the program's instructions (CALL, RETURN, IPC/IPE/IPR, THROW/CATCH etc.). The data reside in a dedicated memory space to enforce security. Nothing bad should happen as long as the program and the hardware's integrity are ensured.
  • The data stack is user-defined in the user's data space and can be placed anywhere there, in fact there could be any number of data stacks. It's up to the programmer's tastes and needs, who could shoot himself in the foot but this will not break everything. Anyway, one main data stack seems indispensable at least to support "frames" that common languages expect.

  This is expanded in the sub-project #A stack.
  

  This is a way to get both safety (the control stack can't be tampered with by data injection, only by modifying the read-only program) and performance (since separate access increases the ILP and there are fewer indirections due to programming kludges). The user can optimise the data stack(s) at will and even not use one when unneeded. The user stacks can grow up or down, be allocated dynamically...

  OTOH the control stack enforces security by using tagged values that define the type of the stack's contents. This is discussed at https://hackaday.io/project/8774-f-cpu/log/222000-tagged-control-stack and will certainly expand. This tagged control stack (TCS ?) can mix critical information of the program's flow state, including error handling, inter- and intra- modules calls, or even outer loops. However registers and other states must be saved through the normal datapath : apart from the Instruction Pointer, there is no provision to save the other states on the TCS, whose name implies it's only for control.

  Saving the state of the other data can be performed explicitly by code sequences and/or specific instructions. NPM/POSEVEN does not specify context switches.
  

View all 17 project logs