Portals Isolate Partitions

By Ralph Moore · February 17, 2026 · SecureSMX

APIs generally require that API functions be accessible to callers. If one partition is trying to access services in another partition, this breaks the isolation between them. Portals solve this problem by providing an indirect API to isolate services in one partition from callers in other partitions.

To do this, API function calls are converted into messages, which are sent to the portals of other partitions. Portals convert messages back to function calls, execute the functions, then return results via the same or different messages. Thus, isolation between the partitions is preserved. Also, this process is transparent to the client, which appears to be directly calling server functions, except that execution times are slower.

Exchange Messages

Exchange messages consist of message control blocks (MCBs) linked to data blocks, as shown in the above diagram. The former contain metadata to manage the messages and the latter contain the actual message data. Messages are sent to message exchanges where tasks wait and they are received from message exchanges where messages wait. (However, only tasks or only messages can wait at an exchange at the same time.)

Messages can have priorities and they can be enqueued on exchanges in priority order. Thus higher priority messages will bypass lower priority messages that are waiting for service. The same applies to tasks waiting for messages. Message queues, at exchanges, serve as work queues for server tasks. Task queues, at exchanges, serve to meter resource access to one task at a time. An exchange often is a better choice for resource metering than a mutex. This is because the same task always accesses the resource and other tasks need not be concerned about the details of accessing that resource. It also permits swapping resources and their server tasks without impacting other tasks. For example, changing storage devices. A pass exchange passes the message priority to the task receiving it.

Protected Messages

Portals use a special kind of exchange message called a protected message, pmsg. This is a message having additional information in its MCB, as shown in the above diagram. In particular, the MPU region information for the data block is contained in the pmsg MCB. When a pmsg is received by a task, its data block region is loaded into an empty slot in the MPU. This allows the receiving task to access the data block. The data block region is also put into the same empty slot in the task’s MPA, in case the task is preempted. A pmsg, like a diplomatic pouch, carries protected information from one location to another.

Portal Types

For a portal, the receiving task is called the server and a sending task is called a client. A server can have many clients. When a portal is created, it is given a list of the clients that are permitted to access it. The portal create process initializes the server control structure and loads the portal exchange handle and portal name into the client control structure of each client in its permitted client list. Only those clients can access the portal, because only they know where to send pmsgs for the portal. This a compile-time limitation that cannot be changed at run time.

Two types of portals are provided by SecureSMX:

Free message portals.
Tunnel portals.

Free Message Portals

Free message portals are intended for transfers of small amounts of data and commands with high security. In the following, SX, denotes a portal exchange.

In this diagram, |’s represent pmsgs. When a client, C, sends a pmsg to a server exchange, SX, the client’s pmsg data region is cleared in the MPU and its MPA. Thereafter, the client cannot access the pmsg data block. When a server, S, receives a pmsg from an exchange, it becomes the pmsg owner and it can access the pmsg data block, as explained previously. When the server is done, it sends the pmsg to a reply or resource exchange, RX. Once sent, the server can no longer access the pmsg data block. Thus, full isolation is maintained between client and server.

The above diagram shows three possible configurations for free messaging:

A. One-way messaging with the data block fetched from and returned to memory. Useful if data blocks vary in size and transfers are infrequent.

B. Two-way messaging, messaging with feedback, or one-way messaging with free messages stored at RX. Useful if data blocks are the same size and faster operation is desired.

C. One-way messaging to a server from multiple clients with free messages stored at a shared resource exchange. Utility is similar to B.

Clearly these configurations can be mixed and others are possible.

Tunnel Portals

The tunnel portal is intended for sending large amounts of multi-block data. In this case, the client retains ownership of the pmsg and access to its data block. The data block becomes a tunnel between the client and the server partitions, thus allowing multiple data blocks to be sent or received per operation. Semaphores are used to coordinate operation between client and server. When transmission is complete, the portal is closed, and the pmsg is released.

Operation

For both types of portals, a header file maps the server function API to shell functions having slightly different names. This header file is included in each client file doing server function calls. Each shell function creates a pmsg with a function ID, its parameters and data, and sends the pmsg to the portal exchange. The server receives the pmsg from the portal exchange and uses a switch statement to translate the ID to a function call, calls the function, then sends the function return value and data back to the shell function, which returns it to the application. All of this is transparent to the application, except that operation is slower than for direct calls.

For a popular server, pmsgs can build up at the portal exchange. Like a mutex, this brings unbounded priority inversion into play. Hence priority promotion has been added to portal exchanges. However, there is no need to propagate this priority promotion, as is the case for mutexes [3]. To simplify protocol operation, server and active client priorities must be the same. Hence, it is necessary to boost the active client priority if the server priority is boosted. Although interaction between mutex and exchange priority promotion is handled, it is not recommended to mix them, due to possible confusion.

Performance

Performance is good because pmsg operation requires no copying of the pmsg data block (unlike the case for message exchanges between MMU regions). In fact, the data block can double as the work buffer in a client in order to further reduce data copying and memory usage. Performance can be greatly improved by increasing the size of the pmsg data block, i.e the tunnel.

The following are measured performances (KB/sec) of a file system (FS) for an SD card on the STM32F746 (Cortex-M7). The first line is for no portal. The second line is for a portal using the pmsg data block as the work buffer. The third line is for a portal with a separate work buffer.

                         read / write
FS+SD                    7969 / 4855
FS+SD+portal no copy     6788 / 4544    85% / 94%
FS+SD+portal copy        6685 / 4419    84% / 91%

The portal has reduced performance by 16% for reads and 9% for writes, with a slight improvement when using the pmsg data block as the work buffer.

Other Benefits

Portals encourage client/server implementations. Servers normally run to completion (RTC), which improves determinism [1]. Also, servers can be implemented with one-shot tasks [2], which reduces the memory needed for task stacks. Hence, dividing firmware into isolated partitions, using portals, tends to improve quality of operation as well as security.

In addition, a portal hides the internal structure of a partition. Even though all microcontroller firmware is linked together into a single executable, partitions cannot see inside of other partitions. This opens some useful possibilities:

Portals are necessary for communication between isolated partitions. There are two kinds of portals: free message and tunnel portals. Code for the first is in fportlc.c and fportls.c, and code for the second is in tportlc.c and tportls.c. Also see portl.h. These can be found at www.github.com/Micro-Digital/SecureSMX.

Partition-only updates, while rest of system runs normally.
Replacing a breached partition with a backup partition to keep a system performing its main functions, while under attack (required by CRA).
Use of frameworks built of mock partitions for development testing while code for other partitions is being written.
Partition swaps to change features.

Conclusion

References

“Can an RTOS be really real-time?”, Miro Samek, LinkedIn, Feb 2026.
“Three Kinds of Tasks”, Ralph Moore, LinkedIn, Nov 2025.
“Can You Trust Your Mutex?”, Ralph Moore, LinkedIn, Nov 2025.