Digital Security by Design Software Ecosystem Competition

ISCF Digital Security by Design (DSbD):
Software Ecosystem Development
Joint Innovate UK and EPSRC Competition
Applicant briefing – Virtual event
5th October 2021

Prof. John Goodacre
Challenge Director DSbD
▪ Programme update, availability of Morello board
▪ Importance and relevance of the competition
▪ Thank you to Innovate UK and EPSRC

Competition briefing - introductions
▪ Georgios Papadakis, Senior Innovation Lead - DSbD
▪ Izzie Finley-Day, Portfolio Manager - Competitions

Part 1
Competition scope, eligibility criteria
Part 2
The Innovation Funding Service, application finances, academic partners
Part 3
Submitting your application, assessment, project setup for successful applicants
Agenda

The aim of this competition is to fund a range of projects, including:
• both single applicant & collaborative
• both business-led & research organisation-led
that work to enrich and expand the Digital Security by Design (DSbD) software
ecosystem prior to the availability of commercial hardware
Projects will leverage the DSbD Technology Hardware Prototype (aka ‘Morello
Board’) to work on a focused area within a selected and specified software
stack or Operating System (OS) or developer toolchain used by a digital system
Competition Way-in
up to £8 million for R&D projects to work on the development of the DSbD software
ecosystem. Project funding from £200k to £1.4M with duration between 12-30 months

Proposals MUST focus on either of the following:
• enriching the evolving Morello Stacks
• expanding overall support and make available additional DSbD enabled software stacks,
toolchains and components
All projects are required to evaluate the performance impact of using DSbD technologies based on
specified performance requirements and objectives:
• To take into account the expected maturity of the specified software stack or Operating
System or developer toolchain
• To take a flexible approach in their workplans as appropriate
Proposals MUST:
• specify the use and need for the Morello boards within the project
• include scenario analysis between the requirement for availability of on-premise boards in a
limited number and cloud-based virtualised access to potentially a larger number of boards
• Quantities and virtual access considerations for each respective scenario must be specified
Competition Scope (1/2)

Proposals MUST:
• show how the project will deliver value and benefit to application developers and the
growth of the DSbD software ecosystem
• describe the availability of project outputs, along with how and whether you will be
making them available to others using a Morello board
• describe your route to impact on how project results can be exploited on the availability
of commercial hardware
We are looking to fund projects that will realise the benefits of DSbD technologies for
software development within:
• OS and developer toolchains, for example, compilers, linkers, debuggers, verifiers
• shared libraries and dependent packages
• language runtimes
• developer frameworks or middleware
• other platform services across Linux-based or other open-source operating systems
Competition Scope (2/2)

We are NOT funding projects that are:
• developments which do not deliver benefit to a software developer
• not making use of, enable software targeting or benefitting from capability enabled
hardware as made available by the Morello board
• requiring enhancement of additional hardware capabilities, for example,
accelerators
• developments that do not clearly require a platform level processor, for example, it
supports a memory management unit
• dependent on export performance, for example giving a subsidy to a baker on the
condition that it exports a certain quantity of bread to another country
• dependent on domestic inputs usage, for example giving a subsidy to a baker on
the condition that it uses 50% UK flour in their product
Mind the scope! (and Subsidy Control)

Application Questions (scored)
To know how wewillscore, see:
https://www.dsbd.tech/how-your-project-will-be-scored

Why does the ecosystem need what you are proposing?
Describe or explain:
• a clear description of what you are proposing and its security challenge
• the motivation for playing your part in the DSbD software ecosystem’s enablement
• the benefits of addressing the security challenge within a clearly specified software stack
• how your proposal innovates beyond how it is being addressed today and the limitations of
the current approach
Question 2: Why and what?
Max 800 words

What approach will you take and where will the focus of the innovation in the context
of the DSbD software ecosystem be?
Describe or explain what your contribution is in terms of enriching the Morello Stacks or
expanding overall support including:
• how you plan to manage the dependencies of your approach with respect to the Morello Stacks
existing and evolving functionality
• why and how the targeted software stack and components will benefit the DSbD software
ecosystem, if you aim to expand overall support
• how the proposed work will align with the identified need and challenge
• the project objectives and how you will evaluate those, including performance requirements
Max 800 words
Appendix optional (e.g., diagram to the proposed technical approach)
Question 3: Technical approach &
innovation

Who is the project team, what are their roles and responsibilities?
• the role and responsibility of all members of the project team (both named and to be hired)
and how they contribute to delivery of the project
• justify the use of any external parties, including sub-contractors
• justification for the requested quantity of Morello prototype hardware boards both on premise
or remotely accessed
Max 400 words
Appendix optional / mandatory for non-grant claiming partners
Question 4: Team and resources

What are your routes to impact of your contribution?
• your project’s research and development outputs; how and where will your outputs be made
available both prior to and on the availability of commercial hardware
• how will these outputs impact the growth of the DSbD software ecosystem
• how will you manage any dependencies, including any intellectual property (IP) constraints,
related to achieving the impact of your outputs
• how the consortium expects to interact with relevant groups developing DSbD technologies
and engage with the DSbD networking workshops organised by the ‘Discribe’ Social Science
Hub+ project
Question 5: Impact
Max 800 words

How will you manage and execute the project effectively?
• an outline of each work package of the project, indicating the lead partner assigned to each
and allocation of budget and resources
• your management structure and reporting
Appendix:
• a project plan and risk register
• must include a Gantt chart with measurable milestones and technical deliverables, in enough
detail to identify any links or dependencies between work packages and track associated tasks
Question 6: Project & risk management
Max 400 words
Appendix mandatory

How much will the project cost and how does it represent value for money for the team
and the taxpayer?
(in terms of the project goals) Describe or explain:
• the total eligible project costs and why they are required to meet the objectives of the proposal
• the total grant you are requesting and how each partner will finance their contributions to the
project
• the balance of costs and grant across the project partners
• how this project represents value for money for you and the taxpayer
• how it compares to what you would spend your money on otherwise
• any sub-contractor grant costs and why they are critical to the project. A strong justification is
required if the sub-contractor is non-UK based
Question 7: Justification of resources
Max 600 words

Previously submitted application Not a previously submitted application
A previously submitted application is:
an application UKRI judges as not materially
different from one you've submitted before (but it
can be updated based on the assessors'
feedback)
A brand-new application/project/idea that you have not
previously submitted into an Innovate UK competition
OR
A previously submitted or ineligible application which:
✓ has been updated based on assessor feedback
✓ and is materially different from the application
submitted before
✓ and fits with the scope of this competition
Previously submitted applications
You cannot use any application previously submitted to UKRI to apply for this competition.

Project eligibility
✓ Lead must be a UK registered business OR a UK research organisation
✓ Single or collaborative
✓ Start on or after 01 April 2022
✓ End by 31 December 2024
✓ Exploit the results from / in the UK
Project grant From £200,000 to £1,400,000
Project duration between 12 to 30 months
Eligibility criteria

• Business – Small/Micro, Medium or Large registered in the UK
• Research Organisation (RO):
• Universities (HEIs)
• Non profit distributing Research & Technology Organisation (RTO) including Catapults
• Public Sector Research Establishments (PSRE)
• Research Council Institutes (RCI)
• Public sector organisations and charities doing research activity
• If you are 100% owned by a large parent company as a small subsidiary this means you are classed as a
large company and will only be entitled to the relevant grant. For more information on company sizes, please
refer to the Company accounts guidance.
Types of organisations we fund

To help you understand whether you are eligible to apply we have created an eligibility tree.
Am I eligible to apply

Compliance with the UK Subsidy Control Regime
On 1 January 2021, the UK left the EU and is no longer subject to EU laws on State aid. We draw your attention to the guidance issued by
BEIS: Complying with the UK’s international obligations on subsidy control: guidance for public authorities. Please be aware this is a living
document and may be updated by BEIS as time progresses.
The set rules (typically GBER) which we previously relied on for the limits of what we could award, have now been replaced by internal
decisions based on the new BEIS Subsidy Control Regime, and on policy, which will in turn set out bespoke eligibility requirements for each
funding opportunity.
Innovate UK is offering funding for this competition in line with the UK's obligations and commitments to Subsidy Control. To ensure that
Innovate UK remains compliant with the UK’s international Subsidy Control duties in respect of:
• The EU-UK Trade and Cooperation Agreement;
• Article 10 of the Northern Ireland Protocol: (successful applicants which are affected by the Northern Ireland Protocol will
be funded in line with EU State aid regulations)
• Article 138 of the Withdrawal Agreement (some Union law applicable after 31 December 2020 in relation to the UK’s
participation in Union programmes and activities)
• The Subsidies and Countervailing measures within the WTO (ASCM);
• Any other Free Trade Agreements active at the time of award.
All awards will be conditional on compliance at all times with the UK Subsidy Control Regime
– this will be reflected in the terms and conditions of any award

Due diligence for UK Subsidy Control Regime
Under the Subsidy Control Regime, we will carry out financial health checks and going concern assurances on your
organisation.
Certify you are eligible
When submitting an application, you must certify that you are eligible for funding. If you are unsure, please take independent legal advice
before applying. Should you be successful, we will complete these financial checks and assurances before confirming the grant offer.
For more information on company sizes, please refer to the Company accounts guidance.
Further information is available on our website in the general guidance

Eligibility Criteria - EU State Aid Regulations – Northern
Ireland Protocol
If you are an applicant who is conducting activities that will affect trade of goods and/or electricity between Northern Ireland and the EU as
envisaged by Article 10 of the Northern Ireland protocol, then you must apply under European Commission State aid rules.
Undertaking in Difficulty
For applicants subject to the European Commission State aid rules, you will be required to prove that they were not an “Undertaking in Difficulty”
(UiD) on the date of 31 December 2019 but became a UID between 1 January 2020 and 30 June 2021. We will ask for evidence of this.
This test applies to:
• companies that are more than 3 years old
• companies where more than half of its subscribed share capital has disappeared as a result of accumulated losses.
• your parent or holding company
Certify you are eligible
When submitting an application, you must certify that you are eligible for State aid. If you are unsure, please take legal advice before applying.
Should you be successful, we will apply this test as part of our viability checks before confirming the grant offer.
Further information is available on our website in the general guidance under state aid
If you are applying for an award funded under State aid Regulations, the definitions are set out in the European Commission Recommendation of
6 May 2003.

Eligibility Criteria: Funding Opportunities
Industry Led Projects
For industry led projects, you could get funding for your eligible project costs of:
• up to 80% if you are a micro or small organisation
• up to 80% if you are a medium-sized organisation
• up to 50% if you are a large organisation
The research organisations undertaking non-economic activity as part of the project can share up to 50% of the total eligible
project costs. If your consortium contains more than one research organisation undertaking non-economic activity, this
maximum is shared between them.
Of that 50% you could get funding for your eligible project costs of up to:
• 80% of full economic costs (FEC) if you are a Je-s registered institution such as an academic
• 100% of your eligible project costs if you are a Research Technology Organisation, charity, non-profit organisation, public
sector organisation or research organisation
Research Organisation Led Projects
For Academic led projects, 100% of project costs can be claimed at 80% FEC.
For general guidance on what our research categories are please visit:
https://www.gov.uk/guidance/innovation-apply-for-a-funding-award#categories-of-research-and-development

Making more than one application
• Any eligible business can lead on one application but may be a collaborator in any number of
applications
• For Research Organisations this applies to the level of a named individual Principal Investigator (PI)
leading the application. Research organisations are able to submit multiple applications as lead,
provided they are led by different named individuals.
• An eligible organisation taking part as a collaborator in multiple applications must show and specify that
they are working on different topics and ecosystem areas.
• Research organisations can be a partner in any number of applications

Other UKRI projects
We will not award you funding if you have:
• have an outstanding final claim and/or Independent Accountant Report (IAR) on a live Innovate
UK project, you will not be eligible to apply for grant funding in this competition, as a lead or a
partner organisation
• applied to a previous competition as the lead or sole company and were awarded funding by
Innovate UK, but did not make a substantial effort to exploit that award, we will award no more
funding to you
• applied to a previous competition as the lead or sole company and failed to comply with grant
terms and conditions
• an open, outstanding ResearchFish sanction

Timeline Dates
Competition Opens 04 October 2021
Briefing Event 05 October 2021
Submission Deadline 08 December 2021
Applicants informed 04 February 2022
Projects to start on or after 01 April 2022
Projects to end by 31 December 2024
Key Dates

Innovation Funding Service
(IFS)

Search for a funding competition and review criteria

Lead Applicant: create an
account
The Lead applicant must create an account:
UK registered businesses - Use Companies House
lookup as it speeds up our checks by providing your
company number. You are unable to enter this at a
later date
Research organisations, academics &
Universities - Enter your information manually so
you’re not listed as a business on IFS and ensure you
receive the correct funding

Project Details
Application Team – Collaborators can invite organisations who you are working with on the project. Contributors can invite
colleagues from your own organisation to help you complete your application
Application Details - Title, Timescales, Research Category, Innovation Area & previously submitted application (y/n)
Subsidy basis – Will the project, including any related activities, you want Innovate UK to fund, affect trade between Northern Ireland
and the EU? All participants must complete this section.
Equality, Diversity and Inclusion - external survey to complete
Project Summary - Short summary and objectives of the project including what is innovative about it
Public Description - Description of your project which will be published if you are successful
Scope - How does your project align with the scope of this competition? - If your project is not in scope, it will be ineligible for
funding

Application Questions
Detailed guidance available on IFS
Application form Appendix?
Question 1 Applicant location (not scored) No
Question 2
Why and what
No
Question 3 Technical approach and innovation Yes - optional
Question 4 Team and resources Yes – optional / mandatory for non-grant claiming partners
Question 5 Impact No
Question 6 Project and risk management Yes - mandatory
Question 7 Justification of resources No

To claim funding:
Your business does not have to be UK registered with Companies House when you apply but it must be
registered before you can receive funding.
You are unable to claim funding if:
• You are an overseas organisation, so your company number begins with FC
• Your organisation is setup as a branch, so your company number begins with BR
• Your company is based in Jersey, so your company number begins with JE

Eligible:
• Staff working directly on
project
• Paid by PAYE
• NI, pension, non-discretionary
costs
Ineligible:
• Dividends
• Bonuses
• Non productive time
• Overtime
Labour

Overheads
Innovate UK’s definition: additional costs and
operational expenses incurred directly as a result of
the project. These could include additional costs for
administrative staff, general IT, rent and utilities
Indirect (administration) overheads
• please ensure they are additional and
directly attributable to the delivery of the
project
Direct overheads
• E.g. office utilities, IT infrastructure, laptop
provision not covered by capital usage
• must be directly attributable to the project
• Provide detailed breakdown together with
methodology/basis of apportionment

Material costs
Please be clear on what the
materials are, just putting
consumables doesn’t provide
enough detail.
If insufficient information is
provided, we will request more
information should you be
successful which may delay your
project start date.

Capital equipment usage
Eligible:
Used in the project or shared with day-
to-day production.
Calculations will need to be in line with
your accounting practices.
Even if the equipment is depreciated
fully over the life of the project this must
be added under capital equipment.

Subcontractors
Eligible:
Justified and quantified.
If non-UK sub-contractors are being
used, you will need to provide
strong justification on why an UK-
based sub-contractor is not being
used.
If you’re sub-contracting to a parent
or sister company, please ensure
you list at cost and do not include
profit.

Travel & subsistence
Eligible:
Costs must be directly linked to the
project
Please breakdown your costs as
follows:
• Travel
• Accommodation
• Subsistence
If you have an annual trip to visit
the parent company this is not an
eligible cost

Other costs
Eligible:
• Costs that could not be added under
previous headings
• Do not double count
• Patent filing costs for new IP – SMEs
up to £7,500

Funding
Funding rules
• The level of funding awarded will depend upon the type of organisation and the type of
research being undertaken in the project
• Funding is calculated by project participant
IFS will advise the maximum grant % you can request based upon your answers to:
• Type (and size) of organisation
• Research category defined by the lead applicant in the Application Details section of the
application

Why Je-S?
• We use the Research Councils’ Joint Electronic Submission System (Je-S) to collect academic
finances
• The Je-S system automates the collection of Full Economic Costs (FEC) based costs from academic
partners and tells them exactly what numbers should be used in the application form for their costs
• Also to collect project finance details from non-HEIs (e.g. RTOs) that are claiming they are carrying
out academic quality work and want to be funded on an FEC basis
• Using Je-S means that Innovate UK follows standard Research Council guidelines on funding
universities and enables Research Councils to easily co-fund Innovate UK projects
• The Je-S system is completely separate from Innovate UK and we cannot advise on its usage

• Enter the TSB reference number here
• Enter the TSB Contribution column figures
from your J-eS output document into the
project costs section of the application
• Upload the Je-S with council status form
as a PDF at the bottom of the screen
Queries about Je-S:
Contact Je-S Helpdesk (not Innovate UK)
• jeshelp@je-s.ukri.org
• 01793 444164
Project costs – academic partners

Project cost summary
All organisations can see a
summary of project costs
Ensure the highlighted costs
fits the criteria for this
competition

Checking your finances are complete
IFS checks
• all organisations have marked
their finances as complete
• research organisation participation
is no greater than 50% of the total
project costs
• IFS DOES NOT VALIDATE TOTAL
PROJECT COSTS

Editing a submitted application
Reopen by
clicking here
Remember to
press SUBMIT

Submit your application early!
Be aware of the
potential for last
minute technical
issues!

Application assessment
All applications are assessed by independent assessors drawn from industry and academia
What do they look for?
• Clear and concise answers
• The right amount of information
• not too much detail
• no assumptions
• Quantification and justification
• A proposal that presents a viable opportunity for growth, a level of innovation that
necessitates public sector investment and has the right team and approach to be successful
Keep your assessors engaged
and interested in your proposal.
You want them to be fascinated
and excited by your idea!

Scoring
• We review scores and feedback to check assessors are adhering to our guidelines and scoring
fairly
• In some cases, where we feel a score is unjust and not supported by feedback, we may remove
that score as an outlier and update the total score for the application
• Please be aware that both low and high outliers may be removed and as a result scores may
increase or decrease
If outliers are removed we are unable to reflect this change in the scores you receive as part of
your feedback due to this decision being reached outside the IFS system

Note on feedback
• The feedback is compiled using the written comments of the independent assessors who review
and assess the applications
• It is intended to be constructive in nature and to highlight both the strong as well as the weak
areas of your application
• Please bear in mind that because applications are assessed by a number of assessors, you may
receive information which appears to be conflicting. This may reflect their different interpretations
of the proposal that you submitted
• It must also be noted that some proposals may appear to have been favourably assessed based
on their comments, in such instances it could be that your proposal simply fell below the funding
threshold, with others achieving a higher merit score overall

Application assessment
• The score spread shows the difference between the
top and bottom scores
• If score spread is 30 or more we will look to see if an
outlier is apparent
• If there is a 3 or more appear in either the two
columns Count of No Scope or Count of No Recc’d
we review the applications feedback and if justified,
the application will not be eligible for funding

• The green box = particular assessor scores on an application
• The purple box = set of scores for a particular question
• The red box = at first glance this looks like an outlier
Identifying outliers

Project setup for successful
applicants

Notification
If you are unsuccessful in this competition:
- you can use the feedback from the assessors to develop your idea and apply into another
competition that allows previously submitted applications
For industry led projects, if you are successful in this competition:
- you will be assigned a Delivery Executive who will guide you through the Project Set Up process
- you will have 30 days to complete the project team, project details and bank details you will then
have 90 days to complete project set up – funding may be withdrawn if this is not completed
within this timeframe
For academic led projects, if you are successful in this competition, contracting and project
start up will be managed by EPSRC.
Please ensure all your contact details in the IFS portal are correct
and up to date and that you regularly monitor it

Industry Led Project Set Up
• All communication will be through IFS
• Lead applicant must provide collaboration agreements and exploitation
plans if applicable
Industry Led Project Delivery
• All grants are paid quarterly in arrears, and are only paid following
quarterly reporting and necessary audits
• Claims can only be made for costs incurred and paid between the
project start and end dates
• Monitoring of the project includes a visit from the appointed Monitoring
Officer

Academic Led Project Set Up
• EPSRC will contact successful academic led projects to arrange funding.
• Successful proposals through the IFS will be uploaded to the JeS system, through which the grant
will be awarded and administered.
• A single JeS form must be submitted for the whole project with finances input in line with those
confirmed through the IFS
• Payments will be made quarterly in common with other JeS administered grants
• Additional monitoring requirements will be in place to ensure compliance with the terms of the
competition and provide financial monitoring.
• Full terms and conditions are available when registering for the competition on IFS.

Customer Support Services:
0300 321 4357 (Monday - Friday 9:00am - 11:30am & 2:00pm - 4:30pm)
support@innovateuk.ukri.org
Knowledge Transfer Network:
www.ktn-uk.co.uk
Innovate UK:
https://www.gov.uk/government/organisations/innovate-uk
Contact

@InnovateUK Innovate UK
Innovate UK

© 2021 Arm Limited (or its affiliates)
Mark Inskip, Program Director
Arm Central Engineering
5 October 2021
Morello Program
Overview

2 © 2021 Arm Limited (or its affiliates)
Morello Board: Capability Hardware Prototype Platform
• Silicon implementation of a Capability Hardware CPU Instruction Set Architecture
• Implements Morello Profile for A-class
Prototype Architecture
• Two clusters each of two Rainier CPUs
• Interconnect and Memory Controller
support for tagged memory
• Two channel DDR4 DRAM interface
• PCIe Gen3 and Gen4 x16 interface
• CCIX (Cache Coherent Interconnect
for Accelerators) interface
• Mid-range GPU, display processor
and HDMI output
• On standard uATX form factor board
CoreSight
SoC-600
CMN-Skeena (CoreLink CMN-600 based)
CoreLink GIC-600
CoreLink NIC-400
IOFPGA
SCP
Cortex-M7
MCP
Cortex-M7
DDR4-2667
DMC-Bing
(DMC-620 based)
CCIX
PCIe
MMU-600
Rainier
ELA-500
Rainier
ELA-500
DMC-Bing
(DMC-620 based)
HDMI
Mali-D35
Mali-G76
UEFI boot, SCP/MCP Firmware
Trusted Firmware-A
Linux Kernel
Supporting Arm system IP: GIC-600 (Generic Interrupt Controller), MMU-600 (IO MMU), Dynamic
Memory Controller derived from DMC-620, SoC-600 (SoC Debug and Trace), Coherent Mesh Network
derived from CMN-600, NIC-400 (Non-coherent interconnect)
Supporting 3rd party system IP/hardware: PCIe/CCIX Root Complex (PHY and controller), DDR4/3 PHY,
DDR4 memory, IO FPGA
Open-source software stack

Overview of the Morello Board 1x CCIX compatible PCIe
Gen4 x16 slot
3 x Standard PCIe Gen3 x16
slot routed as x16, x8, x1
PCIe Gen3 Switch
2 x SATA II
Rear I/O connections
HDMI1.4a output
1Gb Ethernet RJ45
4 x USB3.0
PCC Ethernet
Config USB (inc UARTs)
32 bit TRACE (MIPI 60)
Morello SoC
2 x 72 bit DDR4 RDIMMS,
one per channel
(16GByte standard config)
Motherboard
controller (MCC)
Morello SoC
IOFPGA

Overview – Morello Program Timeline
Platforms and
milestones
General
platform
Enablement
Morello
Architecture
Enablement
Linaro and
ecosystem
access
AArch64 platform software stacks
Platform ports for firmware.
Operating System support.
Hardware bring up
FPGA, SoC, development board.
SBSA compliance testing.
Morello architecture support
Toolchain, libraries, Kernel development.
Prototype userspace examples
Platform model Development board
Ecosystem software access
Infrastructure provision, future engineering support and maintenance
October 2020 January 2022
evolving functionality
Volume shipping
March 2022

mark.nicholson@arm.com
Technology Manager
Arm Central Engineering: Open Source Software
Morello Technology
Demonstrator
September 2021 update

Morello software ecosystem enablement
Software workstreams
Development environments
Toolchains & Libs (LLVM** & GCC)
Linux Kernel
Platform firmware & bring up
Platforms
https://www.morello-project.org/
Initial FVP
release
Incremental releases
Hardware
availability
Program
close
Infrastructure & hosting
Apr 22
Oct 20 2024
** Primary toolchain
Morello SoC

Software stack foundations to support ecosystem research
Collaboration on foundational enablement & feedback is welcome
• Some research activities may be dependent on future work
• Arm’s contributions will continue throughout lifetime of Program and functionality will evolve in stages
Stacks intended to bootstrap research
activities across a wide range of possible areas:
• Pure capability kernel extensions
• RTOS & embedded stacks
• Workloads (webservers, databases)
• Managed languages & runtimes (Python, Java,
Javascript, WebAsm
• Browsers
• Graphics stacks
• Tooling (optimization, porting, debug,
performance & security analysis)

Morello hardware development platform – initial support
• Developments boards (Q1 2022 onwards) will be supported by the same software stacks as existing FVP
• Software releases for initial boards may not include mature support, examples:
• Support for DDR & PCIe may not initially be performant
• Satellite peripherals (such as audio and video IPs) may not have driver support
• Secondary features such as power management and network boot may not be available
• Firmware pre-installed on boards should be updated to the latest versions immediately after first validation of boot

Firmware stack supports exit at two points
• Post SCP execution: System IP initialized.
Develop from lead processor reset
• Post TF-A execution: Lead Application
processor initialized. Runtime services
available.
Arm Development Studio Morello Edition
• Eclipse based integrated environment for
bare-metal configurations
• Supports debug on FVP and (in 2022)
development board
Baremetal Enablement
Current (nano) headless profile for FVP
• Support for purecap applications & example
ports (libjpeg-turbo, logd, BoringSSL, etc)
integrated into minimal 64bit AOSP
• Purecap Bionic C library variant (CHERI
LLVM/Clang + libshim)
Future work (2022 onwards)
• Full Android boot on development board
• Staged Morello Kernel PCuABI features (Q1 on)
• Bionic evolution
• Investigation: Android Runtime + zygote
• Purecap graphics frameworks
Initial Proof of Concept (end 2021 for FVP)
• Purecap “Hello world” integrated into standard
(64bit) rootfs
• Purecap musl libC (CHERI LLVM/Clang +
libshim). Early prototype/limited features.
Future work (2022 onwards) **
• Development board support (Q1 22)
• Evolution of CHERI LLVM musl lib C
environment: Native compilation on dev
board, purecap userspace application ports
(Q1 22)
• Morello Kernel PCuABI support (end Q1 on)
• Initial Morello GCC/GlibC environment (Q2 on)
• Proof of concept work to demonstrate a
Morello aware Distro framework (Q3 on)
• Purecap graphics frameworks (Q3 on)
** uncommitted estimates
Android Enablement
Evolving releases since Oct 2020
Linux Enablement
Under development
CheriBSD
• Details presented by University of Cambridge
• Provides a BSD based memory-safe kernel
and userspace
• Above common Morello firmware stack

Morello Kernel, C libraries & libshim
Morello Linux kernel (Development through 2022)
• Focus on new kernel-user ABI to support purecap userspace software
• Work in associated C libraries (Bionic, Musl, GlibC) – both developed against a PCuABI (Pure Capability userspace ABI) specification
• Enabling Linux environments supporting mix of purecap and “COMPAT” 64 bit userspace components
Linux and Android built C libraries and libshim
• C libraries initially implemented using concept of a libshim translation layer
• Allows functional development and porting in userspace ahead of mature kernel ABI support
• Does not provide a secure implementation, but allows support for a full set of system calls
Aim 1: PCuABI functional support
• Aim: Native support for user-space
applications built against the purecap ABI
• Limited set of syscalls, expanded over time.
Allows incremental reduction of reliance on
libshim
Aim 2: PCuABI memory safety & security
• Use of capabilities to improve memory
safety at the kernel-user boundary
Initial (lightly modified) ACK – reliant on libshim Releases in 2021
Initial Kernel Infrastructure, core purecap functionality Dev underway
Base 64bit COMPAT (hybrid 64bit & purecap userspace)
Initial PCuABI spec implementation in Kernel End Q1 2022
Enforcement of capability metadata (security model) Q2 2022 on
Full PCuABI specification implementation Q3 2022 on
Full PCuABI support for Bionic (Android) & musl (Linux)
Full PCuABI support for Glibc (Linux)
uncommitted estimates
Kernel PCuABI support

Media Enablement
• Media support for Morello Mali-D35 (Display Processor) and Mali-G76 (GPU) based around Open Source Software
• Mali-D35 supported by existing upstream Kernel driver.
• GPU support will be based on the Open Source Panfrost driver framework for Mali Bifrost GPU architectures
• Timelines
• Initial UI support for the Morello development board will be based on software rendering.
• Panfrost GPU driver platform port (64bit) starts Q1 2022
• purecap ports of graphics libraries will be an ongoing activity through 2022 & beyond

Thank You
Danke
Merci
谢谢
ありがとう
Gracias
Kiitos
감사합니다
धन्यवाद
‫ا‬ً‫شكر‬
ধন্যবাদ
‫תודה‬

Morello LLVM & GNU Toolchain timelines
LLVM (Primary toolchain)
• Ongoing: Regular re-bases to CHERI LLVM.
• CY21Q1 (Done):
• C++ exceptions (static linking).
• CY21Q2 (Done):
• Performance optimisations.
• Descriptor ABI (spec, codegen, LLD, LLDB).
• CY21Q3 (in review):
• C++ exceptions (dynamic linking).
• CY22Q1:
• More extensive public test.
• CY22Q2:
• Code generation for DDC offsetting mode.
GNU Tools
• CY21Q3 (Done):
• GDB (BET)
• CY21Q3:
• GDB (REL)
• CY21Q4:
• GCC C Lang Support (BET)
• CY22Q1:
• GCC intrinsics
• Glibc (DEV)
• CY22Q2 onward:
• GCC Hybrid cap support
• GCC C++ Language Support

Approved for public release; distribution is unlimited. This research is sponsored by the Defense Advanced Research Projects Agency (DARPA) and the Air Force
Research Laboratory (AFRL), under contract FA8750-10-C-0237. The views, opinions, and/or findings contained in this article/presentation are those of the
author(s)/presenter(s) and should not be interpreted as representing the official views or policies of the Department of Defense or the U.S. Government.
CHERI
Capability Hardware Enhanced RISC Instructions
Robert N. M.Watson, Simon W. Moore, Peter Sewell, Peter G. Neumann
Hesham Almatary, Jonathan Anderson,Alasdair Armstrong, Peter Blandford-Baker, John Baldwin, Hadrien Barrel,Thomas Bauereiss,
Ruslan Bukin, David Chisnall, Jessica Clarke, Nirav Dave, Brooks Davis, Lawrence Esswood, Nathaniel W. Filardo, Franz Fuchs,
Khilan Gudka, Brett Gutstein,Alexandre Joannou, Robert Kovacsics, Ben Laurie,A.Theo Markettos, J. Edward Maste,Alfredo Mazzinghi,
Alan Mujumdar, Prashanth Mundkur, Steven J. Murdoch, Edward Napierala, Robert Norton-Wright, Philip Paeps, Lucian Paul-Trifu,
Ivan Ribeiro,Alex Richardson, Michael Roe, Colin Rothwell, Peter Rugg, Hassen Saidi, Peter Sewell,Thomas Sewell, Stacey Son,
Domagoj Stolfa,Andrew Turner, MunrajVadera, Jonathan Woodruff, Hongyan Xia, and Bjoern A. Zeeb
University of Cambridge and SRI International
DSbD Software Ecosystem Workshop – 5 October 2021

Approved for public release; distribution is unlimited.
This work was supported by the Defense Advanced Research Projects Agency (DARPA) and the Air Force Research
Laboratory (AFRL), under contract FA8750-10-C-0237 (“CTSRD”), with additional support from FA8750-11-C-0249
(“MRC2”), HR0011-18-C-0016 (“ECATS”), and FA8650-18-C-7809 (“CIFV”) as part of the DARPA CRASH, MRC, and
SSITH research programs.The views, opinions, and/or findings contained in this report are those of the authors and should
not be interpreted as representing the official views or policies of the Department of Defense or the U.S. Government.
This work was supported in part by the Innovate UK project Digital Security by Design (DSbD) Technology Platform
Prototype, 105694.
We also acknowledge the EPSRC REMS Programme Grant (EP/K008528/1), the ERC ELVER Advanced Grant (789108), the
Isaac Newton Trust, the UK Higher Education Innovation Fund (HEIF),Thales E-Security, Microsoft Research Cambridge,
Arm Limited, Google, Google DeepMind, HP Enterprise, and the Gates Cambridge Trust.
2

Introduction
• An introduction to the CHERI architecture and software stack
• To learn more about the CHERI architecture and prototypes:
http://www.cheri-cpu.org/
• Watson, et al. An Introduction to CHERI, UCAM-CL-TR-941,
September 2019.
• Watson, et al. CHERI C/C++ Programming Guide, UCAM-CL-
TR-947, June 2020.
3

Capability systems
• The capability system is a design pattern for how CPUs, languages,
OSes, … can control access to resources
• Capabilities are communicable, unforgeable tokens of authority
• In capability-based systems, resources are reachable only via capabilities
• Capability systems limit the scope and spread of damage from
accidental or intentional software misbehavior
• They do this by making it natural and efficient to implement, in
software, two security design principles:
• The principle of least privilege dictates that software should run with the
minimum privileges to perform its tasks
• The principle of intentional use dictates that when software holds multiple
privileges, it must explicitly select which to exercise
4
The CAP computer project ran from
1970-1977 at the University of
Cambridge, led by R. Needham, M.
Wilkes, and D.Wheeler.

What is CHERI? (2010-current)
• CHERI is an architectural protection model
• Composes a capability-system model with hardware and software
• Adds new security primitives to Instruction-Set Architectures (ISAs)
• Implemented by microarchitectural extensions to the CPU/SoC
• Enables new security behavior in software
• CHERI mitigates vulnerabilities in C/C++Trusted Computing Bases
• Hypervisors, operating systems, language runtimes, browsers, ….
• Fine-grained memory protection deterministically closes many arbitrary
code execution attacks, and directly impedes common exploit-chain tools
• Scalable compartmentalization mitigates many vulnerability classes ..
even unknown future classes .. by extending the idea of software sandboxing
• CHERI-RISC-V research architecture and prototype FPGA implementations
• Arm Morello: Industrial scale + quality demonstrator CPU, SoC, board
5
An early experimental FPGA-based
CHERI tablet prototype running the
CheriBSD operating system and
applications, Cambridge, 2013

CHERI PROTECTION MODEL
AND ARCHITECTURE
6

Architectural primitives for software security
7
Microarchitecture
Compilers and toolchain
Systems software
Applications
Instruction-Set Architecture
(ISA)
CHERI capabilities are an architectural primitive that
compilers, systems software, and applications use to constrain
their own future execution
Software configures and uses capabilities to continuously
enforce safety properties such as referential, spatial, and
temporal memory safety, as well as higher-level security
constructs such as compartment isolation
The microarchitecture implements the capability data type
and tagged memory, enforcing invariants on their
manipulation and use such as capability bounds,
monotonicity, and provenance validity

CHERI design goals and approach
• De-conflate memory virtualization and protection
• Memory Management Units (MMUs) protect by location (address)
• CHERI protects existing references (pointers) to code, data, objects
• Reusing existing pointer indirection avoids adding new architectural
table lookups
• Architectural mechanism that enforces software policies
• Language-based properties – e.g., referential, spatial, and temporal
integrity (C/C++ compiler, linkers, OS model, runtime, …)
• New software abstractions – e.g., software compartmentalization
(confined objects for in-address-space isolation, …)
8

CHERI enforces protection semantics for pointers
• Integrity and provenance validity ensure that valid pointers are derived from other valid pointers via valid
transformations; invalid pointers cannot be used
• Valid pointers, once removed, cannot be reintroduced solely unless rederived from other valid pointers
• E.g., Received network data cannot be interpreted as a code/data pointer – even previously leaked pointers
• Bounds prevent pointers from being manipulated to access the wrong object
• Bounds can be minimized by software – e.g., stack allocator, heap allocator, linker
• Monotonicity prevents pointer privilege escalation – e.g., broadening bounds
• Permissions limit unintended use of pointers; e.g.,W^X for pointers
• These primitives not only allow us to implement strong spatial and temporal memory protection, but
also higher-level policies such as scalable software compartmentalization
9
Globals
Data
Heap Stack
Code
Control flow
Monotonicity Permissions
Integrity and
provenance validity Bounds

Two key use cases for CHERI
1. Efficient, fine-grained memory protection for C/C++
• Good source-level compatibility, but ABI disruptive to binaries
• Supports referential, spatial, and temporal memory safety (with limitations)
• Generally modest overhead (0%-5%, some workloads 10%)
2. Scalable software compartmentalization
• Multiple software operational models from objects to processes
• Orders-of-magnitude performance improvement over MMU-based
techniques (<90% reduction in overhead in early benchmarks)
Other potential – but under-explored – use cases include within managed
language runtimes, and as a substrate for safer inter-language interoperation
10

CHERI C/C++ MEMORY PROTECTION
11

Memory-safe CHERI C/C++
• Capabilities used to implement all pointers
Implied – Control-flow pointers, stack pointers, GOTs, PLTs, …
Explicit – All C/C++-level pointers and references
• Strong referential, spatial, and heap temporal safety
• Minor changes to C/C++ semantics; e.g.,
• All pointers must have well defined single provenance
• Increased pointer size and alignment
• Care required with integer-pointer casts and types
• Memory-copy implementations may need to preserve tags
• Watson, et al. CHERI C/C++ Programming Guide,
UCAM-CL-TR-947, June 2020
12

CHERI-based pure-capability process memory
13
• Capabilities are substituted for integer addresses throughout the address space
• Bounds and permissions are minimized by software including the kernel, run-time
linker, memory allocator, and compiler-generated code
• Hardware permits fetch, load, and store only through granted capabilities
• Tags ensure integrity and provenance validity of all pointers
Memory
Stack
Code
Heap
Implied
pointer
Explicit
pointer
…
Thread
register
file
PLTs
Globals
captable
DDC
PCC
GPRs
NULL
NULL
NULL

CHERI SOFTWARE
COMPARTMENTALISATION
14

What is software compartmentalization?
• Fine-grained decomposition of a larger
software system into isolated
modules to constrain the impact of
faults or attacks
• Goals is to minimize privileges
yielded by a successful attack, and
to limit further attack surfaces
• Usefully thought about as a graph of
interconnected components,
where the attacker’s goal is to
compromise nodes of the graph
providing a route from a point of entry
to a specific target
15
CheriFreeRTOS components and the application execute
in compartments. CHERI contains an attack within
TCP/IP compartment, which access neither flash nor the
internals of the software update (OTA) compartment.

Shared virtual address space
Register
file
Protection
domain
A
Protection
domain
B
Shared
heap
Domain-specific
captables + PLTs
Domain-specific
stacks
Domain-specific
globals
Heap
allocations
Register
file Domain B
heap
Domain A
heap
Cross-
domain
resources
Shared
code
Implied
pointer
Explicit
pointer
CHERI-based compartmentalization
• Isolated compartments can be created using closed graphs of capabilities,
combined with a constrained non-monotonic domain-transition mechanism
16
Protection
domain A
Protection
Domain B
Flexible set of
shared resources

Opportunities and challenges
• CHERI dramatically improves compartmentalization scalability
• More compartments
• More frequent domain transitions
• Faster shared memory between compartments
• Many potential use cases – e.g., sandbox processing of each image
in a web browser, processing each message in a mail application
• Unlike memory protection, software compartmentalization also
requires careful software refactoring to support strong
encapsulation, and affects the software operational model
17

Proposed operational models:
Isolated libraries and UNIX co-processes
Isolated dynamically linked libraries
• New API loads libraries into in-process sandboxes.
• Calling functions in isolated libraries performs a domain transition, with
overheads comparable to function calls.
• Simple model eschews asynchrony, independent debugging, etc.
UNIX co-processes
• Multiple processes share a single virtual address space, separated using
independent CHERI capability graphs.
• CHERI capabilities enable efficient sharing, domain transition.
• Rich model associates UNIX process with each compartment.
• Active area of research; early prototype available for co-processes
18

CHERI REFERENCE SOFTWARE STACK
19

Porting the CHERI software stack to Morello
• Validate the Morello architecture (functional, sufficient)
• Evaluate the Morello implementation (performance, energy use, …)
• Provide reference software semantics (spatial and temporal safety,
compartmentalization, POSIX integration, OS kernel use, …)
• Act as a template and prototyping platform for industrial
demonstration (e.g., for Morello Consortium partners)
• Provide a platform for future research (e.g., 11 EPSRC projects at
UK universities starting August-October 2020)
20

CHERI prototype software stack on Morello
• Complete open-source CHERI-enabled software stack from bare metal up: compilers,
toolchain, debuggers, operating systems, applications – all demonstrating CHERI ideas
• Rich CHERI feature use, but fundamentally incremental/hybridized deployment
• Aim: Mature and highly useful research and development platform for Morello
21
CHERI-extended Google Hafnium hypervisor (Morello only)
CHERI Clang/LLVM compiler suite, LLD, LLDB, GDB
CheriBSD/Morello (funded by DARPA and UKRI)
• FreeBSD kernel + userspace, application stack
• Kernel spatial and referential memory protection
• Userspace spatial, referential, and temporal memory protection
• Co-process compartmentalization
• Intra-process compartmentalization
• Morello-enabled bhyve Type-2 hypervisor
• ARMv8-A 64-bit binary compatibility for legacy binaries
Open-source application suite (KDE, X11,WebKit, Python, OpenSSH, nginx, PostgresQL …)
Android (Arm)
(Morello only)
Linux (Arm)
(Morello only)
Baseline CHERI
Clang/LLVM from
SRI/Cambridge;
Morello
adaptation by
Arm + Linaro

CHERI Reference Software Stack development plan (prospective)
22
2021 2022
2021Q3 CHERI
software release
(8 September 2021)
Morello support
merged to
development trunk
Spatially safe
(pure-capability)
kernel merged to
development trunk
Morello bhyve
hypervisor support
merged to
development trunk
Temporally safe
userspace heap
merged to
development trunk
(lower certainty)
2022Q1 CHERI software release
(Roughly March/April 2022?)
Co-process userspace
compartmentalization
merged to development
trunk
(lower certainty)
Panfrost Morello
GPU support
merged to
development trunk

How to obtain and install the CHERI software stack
• One build tool to rule them all: cheribuild
https://github.com/CTSRD-CHERI/cheribuild
• Builds, installs, and/or runs:
• QEMU CHERI-RISC-V and Morello, Morello FVP
• CheriBSD/CHERI-RISC-V and Morello disk images
• Small suite of adapted third-party applications
• Up and running with one command (CHERI-RISC-V):
./cheribuild.py --include-dependencies run-riscv64-purecap
23

Getting support
• CHERI discussion mailing list (currently pretty quiet)
• cl-cheri-discuss mailing list
• cl-cheri-announce to be announced soon J
• Slack: cheri-cpu.slack.com
• Arm Morello support forum and mailing list on Morello-specific
topics
24

3-month CHERI Desktop pilot study
Assess the viability of a CHERI/Morello-enabled open-source desktop
software stack:
• Select sample open-source stack slice (window server, widget, window
manager, application suite): X11, Qt, KDE, applications
• Implement CHERI C/C++ referential and spatial memory protection
• Whiteboard possible software compartmentalizations
• Evaluate software change as %LoC changed
• Evaluate security via retrospective vulnerability analysis (5 year sample)
• Improve CHERI compiler toolchain as needed
Detailed technical report published in mid-September 2021
25

Results summary
• Adapted XVNC, X11 libraries, supporting libraries (e.g., libpng, …), Qt, KDE, selected KDE
applications
• Roughly 6 million lines of C/C++ code compiled for memory safety, with light dynamic
testing
• Three compartmentalization case studies in Qt/KDE
• Mitigation rates for selected software:
• 91% of X11 security advisories
• 100% of supporting library vulnerabilities (e.g., libpng, libxml2, …)
• 82% of Qt security advisories
• 43% of KDE security advisories
• Plenty of limitations discussed in detail in the report (e.g., language runtimes omitted)
• Lots of details in the technical report on CapLtd website - http://www.capabilitieslimited.co.uk/
26

Some potential software research areas
• Clean-slate OSes and languages
Current research has focused on incremental CHERI adoption
within current software and languages. How would we design new
OSes, languages, etc., assuming CHERI as an ISA baseline?
• Compilers, language runtimes, and JITs
How can we mitigate the performance overheads of more
pointer-dense executions, such as with language runtimes? Are
vulnerabilities in code generated by compilers and JIT susceptible
to mitigation using CHERI? How does CHERI break or potentially
improve current compiler analyses and optimization?
• Further C/C++ protections with CHERI
We have focused on spatial, referential, and temporal memory
safety for C/C++. But the CHERI primitives could assist with
data-oriented protections, garbage collection, type checking, etc.
Could these improve security, and at what performance cost?
• Safe and managed languages
Languages such as Java, Rust, C#, OCaml, etc., offer strong safety
properties, but frequently depend on C/C++ runtimes and FFI-
linked native code. Can CHERI provide stronger foundations for
higher-level language stacks?
• Virtualization
Can memory protection usefully harden hypervisors? Can we
compartmentalize hypervisors? Can CHERI offer a better
mechanism for virtualizing code than an MMU?
• Debuggers and tracing
Debugging/tracing tools rely on high levels of privilege to
operate. How can we reduce their privilege to mitigate
vulnerabilities in these tools? With stronger architectural
semantics, is new dynamic analysis possible?
• Software compartmentalization tools
Granular software compartmentalization offers vulnerability
mitigation through privilege reduction and strong encapsulation.
How should current applications be refactored, and new
applications be designed, to accomplish maintainable and more
secure software?
• Security evaluation and adversarial research
What is the impact of CHERI on known vulnerabilities and
attack techniques? How does a CHERI-aware attacker change
their behavior? Could formal models and proofs support
stronger security arguments for CHERI?
28

Conclusion
• New architectural primitives require rich HW and SW evaluation:
• Primitives support many potential usage patterns, use cases
• Applicable uses depend on compatibility, performance,
effectiveness
• Best validation approach: full hardware-software prototype
http://www.cheri-cpu.org/
• Watson, et al. An Introduction to CHERI,Technical Report
UCAM-CL-TR-941, Computer Laboratory, September 2019.
• Watson, et al. CHERI C/C++ Programming Guide, UCAM-CL-
TR-947, June 2020. 29

Digital Security by Design Software Ecosystem Competition

More Related Content

What's hot

Similar to Digital Security by Design Software Ecosystem Competition

More from KTN

Recently uploaded

Digital Security by Design Software Ecosystem Competition