Reconfigurable architectures like Field Programmable Gate Arrays (FPGAs) are one of the most adopted solutions for computational intensive applications as they are an affordable technology compared with Application Specific Integrated Circuit. 

In addition, thanks to a growing IP Core market, one can buy third-party components to build his own system in order to meet critical contraints, like time-to-market for business applications or simply to fill the absence of expertise in a team.

One of the main capabilities is Partial Reconfiguration which allows to define an area of the fabric which can be dynamically changed without affect the other parts instantiated into the static partition of programmable logic. This feature can be exploited for a lot of applications like updates in the field and adaptive computing.

New trends

The future trend could be the born of a Third-party IP Core (TPIP) market: like the software market users and developers can buy cores and use them into laptops or smartphones just when they need, even with the presence of an operating system which allows to exploit the TPIP within a software application.

Like a software application a TPIP could potentially use all system resources but, unlike the software, it can't refer to any kind of abstraction and control of an operating system; a TPIP could easily steal or corrupt the user data and attempt to system integrity.

From software side there are no solutions because the OS has no view of the operations performed by TPIP, while from hardware point of view the existing solutions have some limitations: for instance, ARM TrustZone provides mechanisms to forbid access to memory and system peripherals from programmable logic, but memory limitations are related to slices of 64MB; in addition this mechanism works with AXI signals so malicious users can easily adjust them to meet the ARM TrustZone requirements. To avoid security flaws from TPIP we could apply the same techniques used for software applications like sandbox and policy enforcement mechanisms.

The way of the sandbox

Consider a mobile environment scenario (or a desktop one, they are quite similar):

• Each application can perform only the operations declared by the developer through a set of permissions which are requested statically or dynamically;
• The permissions are then added to existing policies and are enforced by OS when the application runs;
• As soon as the application violates one of the policies the OS will stop it.

This mechanism is widely used (i.e. Android, iOS, Linux etc.) and although it works fine it uses CPU cycles and memory resources which could be used for other operations, so it can't perform heavy controls. Like the software scenario is possible to take the same concept in order to control each TPIP, but with more advantages.

The Policy Controller: how it works

The idea is to snoop the addresses to which the TPIP tries to access in order to verify if it violates a policy. The policy enforcement is performed by a custom peripheral (the Policy Controller) instantiated statically into FPGA fabric to completely offload the CPU from the enforcement operations.A Policy is just a pair such as (address, RW permission) or ([inf. Addr., sup Addr.], RW permission) and can be submitted from upper layers (e.g. the OS) in every moment. 

The Policy Controller is composed by many others subsystems which interact together:

• A controller manager which allows to control the component and to add new policies.
• A content addressable memory (CAM) which stores the policies.
• AXI Bridges to control every transactions by searching into the CAM to verify the respect of all policies.
• Search controller which schedules the search requests coming from each bridge.
• Policy checker which returns the permissions granted given an address to verify.

How can it be used?

First we define three roles:

• The USER which is whom will use the TPIP (an application, an application developer or an user which buys the TPIP and makes it available to software applications)
• The SYSTEM MANAGER which is whom need to apply security mechanisms, so it may be the host OS or the system owner which provides the platform
• The THIRD-PARTY IP DEVELOPER (TPIP DEV)

The main feature needed is the Partial Reconfiguration and two partition must be defined:

• The static one will host the static logic such as the Policy Controller which will be placed between the rest of system (processing system, memory etc.) and the reconfigurable partition. The policy controller and the partition will be defined by the system manager
• The reconfigurable partition which will be used by third-party IP developers which must comply to a well-defined interface (a wrapper component customized and provided by the system manager)

This mechanism provides a lot of benefits for all parties involved:

• The TPIP developers can easily use their existing IPs (used in other platforms) without apply changes because they must only be interfaced to a wrapper component
• The system manager can hide the details of static partition
  system and user are sure that each TPIP is isolated in a sandbox

Considerations

The solution proposed has many advantages

• Customization: many parameters can be customized before synthesis likethe depth of policies memory
  • the type of memory ("internal" or "external" like a BRAM/Dual Port BRAM)
  • the type of search (exhaustive or not)
  • the number of the interfaces to monitor
  • the type of transaction to control
  • blacklist or whitelist logic
• Flexibility: with a proper customization it is possible to reach the best trade-off between area consumption and performance.
  • For example, with an internal policies memory each search operation is very fast because it is performed in just few clock period, but the controller uses a bigger amount of area.
• Isolation: if a transaction violates a policy it doesn't reach the rest of system because it is bounded into FPGA. In addition is also possibile to isolate the other cores instantiated into programmable logic
• Accuracy: each policy can be specified with a fine-grained.
• Integration: the policy controller can be integrated within a framework to generalize each IP Core that could be loaded into the system.
• Platform independent: it can be used in either bare-metal applications or not.