High-Assurance Separation Kernels: A Survey on Formal Methods

0.77 MB·

by  Yongwang Zhao

1
High-Assurance Separation Kernels: A Survey on Formal Methods
YongwangZhao,BeihangUniversity,China
DavidSana´n,NanyangTechnologicalUniversity,Singapore
FuyuanZhang,NanyangTechnologicalUniversity,Singapore
YangLiu,NanyangTechnologicalUniversity,Singapore
Separationkernelsprovidetemporal/spatialseparationandcontrolledinformationflowtotheirhostedapplications.They
areintroducedtodecoupletheanalysisofapplicationsinpartitionsfromtheanalysisofthekernelitself.Morethan20
implementationsofseparationkernelshavebeendevelopedandwidelyappliedincriticaldomains,e.g.,avionics/aerospace,
military/defense,andmedicaldevices.Formalmethodsaremandatedbythesecurity/safetycertificationofseparationkernels
7 andhavebeencarriedoutsincethisconceptemerged.However,thisfieldlacksasurveytosystematicallystudy,compare,
1 andanalyzerelatedwork.Ontheotherhand,high-assuranceseparationkernelsbyformalmethodsstillfacebigchallenges.
0 Inthispaper,ananalyticalframeworkisfirstproposedtoclarifythefunctionalities,implementations,propertiesandstan-
2 dards,andformalmethodsapplicationofseparationkernels.Basedontheproposedanalyticalframework,ataxonomyis
designedaccordingtoformalmethodsapplication,functionalities,andpropertiesofseparationkernels.Researchworksin
n
theliteraturearethencategorizedandoverviewedbythetaxonomy.Inaccordancewiththeanalyticalframework,acompre-
a
hensiveanalysisanddiscussionofrelatedworkarepresented.Finally,fourchallengesandtheirpossibletechnicaldirections
J
forfutureresearchareidentified,e.g.specificationbottleneck,multicoreandconcurrency,andautomationoffullformal

6 verification.

CCSConcepts:•Softwareanditsengineering→Operatingsystems;Formalmethods;•Computersystemsorganization
]
E →Real-timeoperatingsystems;•Securityandprivacy→Formalmethodsandtheoryofsecurity;
S GeneralTerms:Design,Security,Verification
.
s AdditionalKeyWordsandPhrases:SeparationKernel,FormalMethods,Survey,FormalSpecification,FormalVerification,
c Security,Safety
[

1
1. INTRODUCTION
v
High-assurancesystemsrequirecompellingevidencestoshowthattheirdeliveredservicessatisfy
5
3 critical properties, e.g. security and safety [McLean and Heitmeyer 1995]. If high-assurance sys-
5 tems fail to meet their critical requirements, it could result in security breaches, loss of lives, or
1 significantpropertydamage.Duetothecriticalityofsuchsystems,itishighlydesiredthattheyare
0 developedinarigorousprocess.Theavionicscommunityhasdevelopedasetofguidelinesforthe
. rigorous development of safety-critical systems, e.g., DO-178B/C [RTCA, Inc. 1992; RTCA, Inc.
1
0 2011].WhilsttheCommonCriteria(CC)[NationalSecurityAgency2012]providesguidelinesfor
7 security-criticalsystems.Inhigh-assurancesystems,TrustedComputingBase(TCB)[Department
1 ofDefense1985]isdefinedas:“Asmallamountofsoftwareandhardwarethatsecuritydependson
: and that we distinguish from a much larger amount that can misbehave without affecting security
v
[Lampsonetal.1992]”.
i
X
r
a ThisresearchissupportedinpartbytheNationalResearchFoundation,PrimeMinister’sOffice,SingaporeunderitsNa-
tionalCybersecurityR&DProgram(AwardNo.NRF2014NCR-NCR001-30)andadministeredbytheNationalCybersecu-
rityR&DDirectorate.Aminorpartofthispaperwaspresentedin[Zhaoetal.2016c].
Author’s addresses: Y. Zhao (corresponding author), School of Computer Science and Engineering, Beihang Univer-
sity, Haidian District, Beijing 100191, P. R. China (Email: [email protected]); D. Sana´n, F. Zhang, Y. Liu, School
of Computer Science and Engineering, Nanyang Technological University, 50 Nanyang Avenue, Singapore 639798
(Email:{sanan,fuzh,yangliu}@ntu.edu.sg).
Permissiontomakedigitalorhardcopiesofpartorallofthisworkforpersonalorclassroomuseisgrantedwithoutfee
providedthatcopiesarenotmadeordistributedforprofitorcommercialadvantageandthatcopiesbearthisnoticeandthe
fullcitationonthefirstpage.Copyrightsforthird-partycomponentsofthisworkmustbehonored.Forallotheruses,contact
theowner/author(s).
©2017Copyrightheldbytheowner/author(s). 0000-0000/2017/01-ART1$15.00
DOI:0000001.0000001
ACMJournalName,Vol.1,No.1,Article1,Publicationdate:January2017.
1:2 Y.Zhaoetal.
The concept of separation kernel is introduced [Rushby 1981] to dissociate the kernel verifica-
tionfromtheverificationoftrustedcodebelongingtoseparatedcomponents.Themainpurposeof
separationkernelsistoenforcetheseparationofallsoftwarecomponentswhilereducingthesizeof
theTCB.Securityiscarriedoutpartlybyseparatingphysicallysystemcomponents,andpartlyby
meansoftrustedfunctionalityaccomplishedwithinsomeofthosecomponentsbeingseparated.The
conceptofseparationkerneloriginatestheMultipleIndependentLevelsofSecurity/Safety(MILS)
[Jimetal.2006]whichisahigh-assurancesecurity/safetyarchitecturebasedonseparation[Rushby
1981] and controlled information flow [Denning 1976]. Separation kernels first came into use in
theavionicsdomain,withtheacceptanceofIntegratedModularAvionics(IMA)[ParrandEdwards
1999] in this domain in the 1990s. A significant foundation of IMA is the separation of system
resources into isolated computation spaces – called partitions. Separation kernels are adopted as
partitioningkernels[OpenGroup2003],whichmainlyconcernssafety.
Separationkernelscanbeconsideredasafundamentalpartofhigh-assurancesystems.Asapart
of the TCB, separation kernels are small enough to allow formal verification of their correctness.
The increasing evidences show successful applications of formal methods on software develop-
ment, not only as theoretical research in the academy, but also deployed in industrial applications
[Woodcocketal.2009].Traditionally,certifiedsecurityisachievedbyCCevaluation[NationalSe-
curityAgency2012],inwhichformalmethodsaremandatedforhighestassurancelevels.Itrequires
comprehensivesecurityanalysisusingformalrepresentationsofthesecuritymodelandfunctional
specificationaswellasformalproofsofcorrespondencebetweenthem.Inparticular,theSeparation
KernelProtectionProfile(SKPP)[NationalSecurityAgency2007]isaninstantiatedprofileofCC
for separation kernels. Safety is usually governed by RTCA DO-178B [RTCA, Inc. 1992] whose
successor DO-178C [RTCA, Inc. 2011] published in 2011 includes a technology supplement of
formalmethods.
Due to the wide application of high-assurance systems, applying formal methods on separation
kernelshasnotonlybeenahotresearchtopicsincetheconceptemerged,butalsoattractedindustrial
concerns. Although more than 20 implementations have been developed in industry or academia,
and furthermore formal methods have been applied on some of them for the purpose of CC and
DO-178B/C certification, high-assurance separation kernels still face challenges [Barhorst et al.
2009; Alan and Robert 2015; D-MILS 2014]. The approaches and techniques of formal methods
forseparationkernelsarenumerous,butthetopiclacksastateoftheartsurveyandacomprehen-
sivetaxonomytoeasetheapplicationofformalmethodsoverthem.Itisthereforesignificantand
urgenttohaveathoroughandcomprehensivestudyonthistopictoprovideausefulreferencefor
further research and industrial applications. To the best of our knowledge, our work is the first to
systematicallyoverview,categorize,analyzeanddiscussformalmethodsapplicationonseparation
kernels.
Thispaperaimsatdistillingthelandscapeinthefieldofformalmethodsapplicationonseparation
kernelsbystudying,classifying,comparing,andanalyzingrelatedworkforthepurposeoffiguring
out challenges and potential research directions in future. Specifically, we present the following
contributionsinthispaper:
(1) We propose an analytical framework to understand and classify related work. In the frame-
work, we clarify a set of concepts related to separation kernels, define a reference architecture,
compareimplementations,studycriticalpropertiesandrelatedstandards,andthenidentifyanappli-
cationschemaofformalmethodsforseparationkernels.Theanalyticalframeworkisthefoundation
ofthissurvey.
(2)Weproposeataxonomyofapplyingformalmethodsonseparationkernelsaccordingtothean-
alyticalframework.Thefirstlevelofthetaxonomyisdesignedaccordingtotheapplicationschema
offormalmethods.Thelowerlevelsarebasedonthereferencearchitectureandcriticalproperties.
Then,wegrouptogethertherelatedworkaccordingtothetaxonomy.
(3)Wepresentadetailedanalysisanddiscussionoftherelatedwork.Wecompareformalmethods
andcertificationsusedinacomprehensivesetofimplementations.Theimportanceoffunctionalities
in the reference architecture is identified in formal specifications and models. Relations among
ACMJournalName,Vol.1,No.1,Article1,Publicationdate:January2017.
High-AssuranceSeparationKernels:ASurveyonFormalMethods 1:3
is a
Security kernel Micro kernel
extends is a
is a variant of
Separation kernel Partitioning kernel
implements implements
Embedded Hypervisor
Domain of generalized separation kernel
Fig.1. RelationshipofDifferentTypesofKernels.
criticalpropertiesareclarified.Theverifiedproperties,usedapproaches,andsizesofresearchworks
onformalverificationarecompared.Then,wegiveanoverallcomparisonofthemaccordingtothe
taxonomy.
(4) We discuss the challenges of applying formal methods on separation kernels and figure out
potentialresearchdirectionsinthisfield.Weidentifyfourchallenges,i.e.,eliminatingspecification
bottleneck,automatingfullformalverification,multicoreandconcurrency,andformaldevelopment
andcodegeneration.Then,weproposetechnicaldirectionstoaddresseachchallengeinfuture.
Comparedtoourpreviouswork[Zhaoetal.2016c],contributions(1),(3),(4)andtheproposed
taxonomy in contribution (2) in this paper are new. The detailed description of research works in
[Zhaoetal.2016c]isreorganizedbythetaxonomyandshortenedtoabriefoverviewofrelatedwork
incontribution(2).Thepreviousworkisalsoextendedbytheresearchworksoftwonewcategories
underthetaxonomy.Therestofthispaperisorganizedasfollows.Section2presentstheanalytical
framework. Section 3 presents the taxonomy and overview of research works in the literature. In
Section4,weanalyzeanddiscusstheresearchworksthroughcomprehensivecomparisons.Section
5 identifies challenges and potential technical directions in this field. Finally, Section 6 gives the
conclusionofthissurvey.
2. ANALYTICALFRAMEWORK
In this section, we present an analytical framework for separation kernels. The framework is the
foundationofthetaxonomy,analysisanddiscussioninthenextsections.First,weclarifyasetofre-
latedconceptsandproposeareferencearchitectureforseparationkernelsinwhichcommonandop-
tionalcomponentsareidentified.Second,wesurveyimplementationsfromindustryandacademia.
Third,weclassifycriticalpropertiesofseparationkernelsandsurveyrelatedstandards.Finally,we
sketchoutanapplicationschemaofformalmethodsforhigh-assuranceseparationkernels.
2.1. ConceptsandReferenceArchitecture
We first clarify the relationship among concepts of security kernel, separation kernel, partition-
ing kernel, microkernel, and embedded hypervisor, which is shown in Fig. 1. The security kernel
[AmesJretal.1983]isthecentralpartofsystemstoimplementthebasicsecurityproceduresfor
controllingaccesstosystemresources.Securityrequirementsofsystemstobeassuredarespecified
as security policies. A reference monitor controls the access of subjects to resources according to
thepolicies.Separationkernelsextendsecuritykernelswithpartitionsandmapexportedresources
into partitions. Separation kernels enforce partitions to have spatial and temporal separation, and
allowsubjectsbelongingtopartitionstocauseflowtotransferinformationamongthem.Theparti-
tioningkernel[Rushby2000;OpenGroup2003;Leineretal.2007]isavariantofseparationkernels
inthedomainofIMAandconcernssafeseparationlargelybasedonanARINC653[Aeronautical
Radio,Inc.2013]styleseparationscheme.Partitioningkernelsspecializeandenhancethetemporal
ACMJournalName,Vol.1,No.1,Article1,Publicationdate:January2017.
1:4 Y.Zhaoetal.
Information Flow
......
Partition1 Partition2 Partition3 Partitionn
Application Application Application Application Application
Software Software Software Software Software
Operating System Library Operating System Operating System Library
Separation Kernel Interface
Partition Management Communication Process Management Monitoring
S
Scheduling Keepa
rnra
Clock&Timer Management Interrupt Management Memory Management eltio
Policies n
Hardware Interface
Core
Clock&Timer Interrupt Controller Processor Memory(MMU)
Hardware
Common Component Optional Component
Fig.2. ReferenceArchitectureofSeparationKernels.
andspatialseparationwithastatictable-drivenschedulingapproach[RamamrithamandStankovic
1994]andstaticresourceallocationforpartitions.
Unlike traditional operating systems, separation kernels do not provide services such as device
driversandfilesystems,butasetofveryspecificfunctionalitiestoenforcesecurityseparationand
informationflowcontrols,inordertokeepthemsmallenoughtoallowformalverificationoftheir
correctness. The primary motivation of these kernels is also the one behind microkernels [Wulf
etal.1974;Jochen1993;Hohmuthetal.2004].Intermsofthesourcecodesize,thesekernelsare
usuallysizinglessthan10,000linesofcode,whichisthecodescaleofmicrokernels.Ontheother
hand, with the rise of more powerful multiprocessor embedded systems, virtualization provides a
promising technique to improve functionalities of high-assurance systems [Heiser 2008; Aguiar
andHessel2012].Embeddedhypervisorsareconsequentlyusedtoimplementsecuritykernels(e.g.
[Paul2005;Saileretal.2005a;Saileretal.2005b]),separationkernels(e.g.[XtratuM2015;West
etal.2016]),andpartitioningkernels(e.g.[VanderLeest2010;HanandJin2011;VanderLeestetal.
2013]).
Duetotheincreasingcomplexity,scale,andmixedcriticalrequirementsofhigh-assurancesys-
tems, various techniques and approaches are integrated [Barhorst et al. 2009] together. From now
on, we use the term separation kernel to cover the concepts of security kernel, original separa-
tion kernel, partitioning kernel, and embedded hypervisor. Based on the landscape of separation
kernels,weproposeareferencearchitecture,asshowninFig.2,forseparationkernelstoprovide
functionalitiestoanalyzeresearchworks.Weclassifythefunctionalitiesintocommonandoptional
components.Commoncomponentsrepresentaleastsetoffunctionalitiestoimplementaseparation
kernel. Optional components are usually supported for complex systems. Hypervisor-based sepa-
ration kernels usually manage partitions (i.e., VMs) and leave process management to guest OSs.
Thecommunicationmechanismsupportsinter-andintra-partitioncommunication.Policiesmaybe
security,safety,real-time,andfault-tolerancepolicies,etc.Theconfigurationforseparation,suchas
memoryseparationconfigurationandschedulingwindowsforpartitions,canalsobeconsideredin
thepolicies.Managementofhardware(e.g.clock,timer,interrupt,andmemory)arenecessaryfor
hypervisor-basedseparationkernels.However,simpleseparationkernelsmanipulatetheunderlying
hardwareviahardwareinterface.
ACMJournalName,Vol.1,No.1,Article1,Publicationdate:January2017.
High-AssuranceSeparationKernels:ASurveyonFormalMethods 1:5
TableI.ComparisonofSeparationKernelImplementations
Multi Open
No Name Timeline ISA Language LOC
Core Source
IndustrialImplementations
1 PikeOS[SYSGO2015] ?-now PowerPC,x86, (cid:51) C,ASM <10k (cid:55)
ARM,MIPS,
SPARC
2 VxWorks653[WindRiver2015a] ?-now PowerPC (cid:51) C,ASM ? (cid:55)
3 VxWorksMILS[WindRiver ?-now PowerPC (cid:51) C,ASM ? (cid:55)
2015b]
4 INTEGRITY-178B[GreenHills ?-now ARM,x86, (cid:51) C,ASM ? (cid:55)
2015a] PowerPC,MIPS
5 INTEGRITY ?-now x86,ARM, (cid:51) C,ASM ? (cid:55)
Multivisor[GreenHills2015b]
PowerPC
6 LynxSecure[Lynx2015b] ?-now x86 (cid:51) C,ASM ? (cid:55)
7 LynxOS-178[Lynx2015a] ?-now x86PowerPC (cid:51) C,ASM ? (cid:55)
8 DDC-IDeos[DDC-I2015] ?-now x86,PowerPC, (cid:51) C,ASM ? (cid:55)
ARM,MIPS
9 AAMP7a[Collins2015] 2001- N/A (cid:55) ? (cid:55)
now
10 ED[Heitmeyeretal.2006;2008] 2006-? ? ? C,ASM ≈3k (cid:55)
11 ARLXhypervisor[Genesys ?-now x86,ARM (cid:55) C,ASM ? (cid:51)
2015]
AcademicImplementations
12 seL4[Murrayetal.2012;2013] 2008- ARM,x86 (cid:51) C,ASM ≈9k (cid:51)
now
13 OKL4Microvisor[Systems 2009- ARM (cid:51) C,ASM ? (cid:51)
2015] now
14 XtratuM[XtratuM2015] 2004- SPARC,x86, (cid:51) C,ASM ≈9k (cid:51)
now PowerPC,ARM
15 PROSPER[PROSPER2015] 2012- ARM (cid:55) C,ASM ? (cid:55)
now
16 Xenon[FreitasandMcDermott 2011-? x86,ARM, (cid:51) C,ASM ? (cid:55)
2011] PowerPC
17 Quest-V[Westetal.2016] 2012- x86 (cid:51) C,ASM ? (cid:55)
now
18 Muen[Muen2015] 2013- x86 (cid:51) SPARK, ≈4k (cid:51)
now ASM
19 POK[POK2015] 2009- PowerPC,SPARC, (cid:55) C,ASM ≈7k (cid:51)
2013 x86
20 AIR/AIRII[AIR2015] 2007- SPARC ? C,ASM ? (cid:55)
2011
?meanswedonotfindanyliteraturetoshowtheevidence.
aThisisaprocessor,ahardwareimplementationofseparationkernel.
2.2. SeparationKernelImplementations
Duetothewideacceptanceofseparationkernels,manyimplementationsincludingindustrialprod-
uctsandacademicprototypeshavebeendevelopedinrecentyears.InTableI,wecomparetwenty
implementationsfromindustryandacademia.Thetimelineinthe3rdcolumnshowsthetimethey
startedandthetimetheystoppeddevelopmentoftheseparationkernels.Theunderlyinginstruction
setarchitectures(ISA)andwhethertheysupportmulti-coreprocessorsaresurveyedincolumns4
and 5, respectively. We also survey the development languages, the line of the code (LOC), and
whethertheyareopen-source.
Bycomparingtheseimplementations,wehavethefollowingfindings.
—Mostoftheseparationkernelsarestillinuseanddeveloping.Veryfewopen-sourceprojectshave
stopped.
ACMJournalName,Vol.1,No.1,Article1,Publicationdate:January2017.
1:6 Y.Zhaoetal.
—Inordertoprovidesafety/securitycriticalsolutions,variousISAsaresupportedbyseparationker-
nels,inparticularARM,SPARC,andPowerPC.Multicoreprocessorsareincreasinglydeployed
insafety/securitycriticalsystemstofulfilthedemandofprocessingpowerinintegratedsystems.
Therefore, multicore processors are supported by most of separation kernels regardless of in in-
dustryandacademia.
—The LOC of separation kernels that we can find in the literature is less than ten thousand. Most
ofimplementationsadoptmicrokernelsasthefoundationandshiftoutthecomplexservicesinto
system partitions. For the sake of portability and efficiency, separation kernels in particulars are
written in the C programming language embedded with pieces of ASM. Moreover, separation
kernelsinacademiaareusuallydeliveredinopen-sourceprojects.
—Withthetrendofintegratingapplicationsononecomputingplatform(e.g.,IMA),nativeinterfer-
enceprovidedbyseparationkernelsisoftennotpowerfulforapplicationdevelopment.Theem-
beddedhypervisoriscurrentlyamainstreamformofseparationkernelsinindustryandacademia.
Virtual machine management provides a straightforward approach for the spatial separation of
resources. Moreover, embedded hypervisors virtualize general-purpose operating systems (e.g.,
Linux)inpartitionsandpermitthedeploymentoflegacyapplications.
2.3. CriticalPropertiesandStandards
Traditionally,criticalpropertiesofhigh-assurancesystemsaresafety,security,real-time,andfault-
tolerance [McLean and Heitmeyer 1995; Rushby 1994]. Different from the classical categories of
criticalproperties,NEAT arewellknownpropertiesconsideredinseparationkernels,whichstands
for“Non-bypassable,Evaluatable,AlwaysinvokedandTamper”proof[Vanfleetetal.2005;Open-
Group2003].Howevertheseintuitiveconceptsarenoteasytoformalizenortoprovidedirectproofs.
Instead, separation kernels are normally verified by formally showing that they provide the right
functionalities for MILS systems according to the following critical properties [Jim et al. 2006;
Vanfleetetal.2005;Rushby2000],whichiscalledDIDT inthissurvey.
—Data Separation: Also known as ‘Data Isolation”, each partition is deployed as a separated re-
source. Applications in one partition can neither modify applications and private data in other
partitionsnorcontrolprivatedevicesandactuatorsinotherpartitions.
—Information Flow Security: Also known as “Control of Information Flow”, information flow
betweenpartitionsisdefinedfromasourcepartition,whichisauthenticated,toasetofreceivers
aswellauthenticated;additionally,thesourceisauthenticatedtothereceivers.
—Temporal Separation: it allows partitions to share physical resources across different time pe-
riods. A resource is assigned to one component for a slice of time, then sanitized and assigned
to another component. Services received from shared resources by applications in one partition
cannotbeaffectedbyotherpartitions.
—DamageLimitation:damageiscontainedbyrestrainingfailuresfrompropagatingfromonepar-
titiontoothers.
Thepropertiesofdataseparation,informationflowsecurity,anddamagelimitationareallspatial
properties. They are collectively called “spatial separation” properties. Data separation requires
memoryaddressspaces/dataofonepartitiontobeindependentofanyotherpartitioninthesystem.
Information flow security is a variation of data separation. Pure data separation is not pragmatic,
thereforeseparationkernelsdefineauthorizedchannelsbetweenpartitionstoprovideinter-partition
communication.Puredataisolationispermittedtobeviolatedonlythroughthesechannels.Damage
limitationisachievedbyotherthreepropertiessincethedamagetoapplicationsinonepartitionare
limited.
Due to criticality of high-assurance systems, there are mandatory verification and validation
(V&V) activities in their design and analysis process to ensure that the systems fully meet their
functionalrequirements.SeveralspecificationshavebeencreatedtostandardizeactivitiesinV&V
processes by international organizations. CC [National Security Agency 2012], which is also the
internationalstandardISO/IEC15408,andSKPP[NationalSecurityAgency2007]areusuallyap-
ACMJournalName,Vol.1,No.1,Article1,Publicationdate:January2017.
High-AssuranceSeparationKernels:ASurveyonFormalMethods 1:7
TableII.CriticalPropertiesandStandards
SpatialSeparation Temporal
Property Standards
Data InformationFlow Damage Separation
Separation Security Limitation
Safety DO-178B/C,ARINC653, (cid:51) (cid:55) (cid:51) (cid:51)
IEC61508,EN50128
Security CC,SKPP (cid:51) (cid:51) (cid:51) (cid:51)
Real-time ARINC653 (cid:55) (cid:55) (cid:55) (cid:51)
Fault-tolerance ARINC653 (cid:51) (cid:55) (cid:51) (cid:55)
(cid:51)meansaDIDTpropertycontributestoimprovetheassuranceofatraditionalcriticalproperty.
Informal Documents
Design Requirements
Formalization Formalization
Specification Verification Properties
tneme High-level Design Model noita
n Low-level Design Model c
ifeR ifire Formal Logic,
Implementation Model V Machine Checkable Artefacts
Synthesis Abstraction
Implementation
Source Code Compile Binary Code
Fig.3. ApplicationSchemaofFormalMethodsonSeparationKernels.
pliedtosecurityofseparationkernels.AlthoughtheSKPPwassunsetin2011,NSAstillrecommend
separationkernelsforsecurity-criticalsystems.Asforsafety,Espositoetal.[2013]hassummarized
a set of well-known safety standards for high-assurance systems. Many of them have also been
applied to separation kernels. Another notable standard for separation kernels is the ARINC 653
standard[AeronauticalRadio,Inc.2013]whichisasetofspecificationstoguidemanufacturersin
avionicapplicationsoftwaretowardsmaximumstandardization.Itaimsatprovidingastandardized
interfacebetweenseparationkernelsandapplicationsoftware,aswellasthesystemfunctionalities
ofseparationkernels.
InTableII,weoverviewthetraditionalcriticalpropertiesofhigh-assurancesystems,theirrelated
standards,andwhetherDIDTpropertiescontributetoimprovetheassuranceoftraditionalcritical
properties.
2.4. ApplicationSchemaofFormalMethods
In software engineering, formal methods provides a set of mathematically based techniques and
toolstospecify,develop,andverifysoftwaresystems[ClarkeandWing1996;BowenandHinchey
2006].WedepictanapplicationschemaofformalmethodsonseparationkernelsinFig.3,inwhich
theartefactsandtechniquesareidentified.
—Formal specification uses languages with a rigorous syntax and semantics to give a precise de-
scription of the system and its desired properties. Informal requirements may be translated into
properties of the system specification. The system specification would further have formal de-
scription of system behavior, which is translated from the informal design. Formal specification
can be used to validate the completeness and accuracy of the system requirements and to guide
subsequent development activities. Formal specification may be refined to high-level, low-level,
ACMJournalName,Vol.1,No.1,Article1,Publicationdate:January2017.
1:8 Y.Zhaoetal.
TableIII.CommonCriteriaEvaluationLevelsandRequirementsofFormalMethods
Common Requirement Functional High-Level Low-Level Implementation
Criteria Specification Design Design
EAL1–4
EAL5 (cid:35) (cid:35) (cid:35) (cid:35) (cid:35)
EAL6 (cid:32) (cid:71)(cid:35) (cid:71)(cid:35) (cid:35) (cid:35)
EAL7 (cid:32) (cid:71)(cid:35) (cid:71)(cid:35) (cid:71)(cid:35) (cid:35)
Formalmethodslevelofso(cid:32)ftwareartefacts: :(cid:32)informal; :semifo(cid:32)rmal; :formal (cid:71)(cid:35) (cid:35)
(cid:35) (cid:71)(cid:35) (cid:32)
andimplementationmodelsstepbystepandfurthermorebeusedforformalsynthesisofimple-
mentations.
—Formalverificationistheacttoensurethecorrectnessofintendedsystemswithrespecttoacertain
formal specification or property. One approach of formal verification is model checking, which
systematicallyandexhaustivelyexploresthemathematicalmodeltochecksatisfactionofproper-
ties.Anotheroneistheoremproving,whosefirststepistogenerateacollectionofproofobliga-
tionsfromthesystemanditsspecifications.Thetruthoftheproofobligationsimpliestheconfor-
manceofthesystemtoitsspecification.Thesecondstepistodischargetheproofobligationsin
aninteractiveorautomatedmanner.
—Therearetwoapproachestoformalverificationofseparationkernelsattheimplementationlevel::
theoremprovingtheimplementationmodelbyabstractionfromsource/binarycode,andsoftware
modelchecking[JhalaandMajumdar2009].
Manysecurityandsafetystandardscurrentlymandatetheuseofformalmethodstocertifycor-
rectness of separation kernels. The Common Criteria defines clear treatment of software artefacts
fordifferentevaluationlevels,whichisshowninTableIII.TheevaluationthroughCCdefinesEval-
uationAssuranceLevels(EAL)fromEAL1toEAL7(formallyverified,designedandtested).The
EAL7mandatesformalverificationofthelow-leveldesignmodelusingmathematicalmodelsand
theoremproving.AsaspecificprofileofCC,SKPPmandatesformalmethodsonseparationkernels
too.DO-178Chasaformalmethodssupplement(DO-333)toaddressformalmethodstocomple-
menttesting.IEC61508definesfunctionalsafetyandmethodsforelectronicsystems.Certification
ofSafetyIntegrityLevel(SIL)4inthisstandardhighlyrecommendtheuseofformalmethods.
3. TAXONOMYOFAPPLYINGFORMALMETHODSONSEPARATIONKERNELS
Wefirstproposeataxonomyofapplyingformalmethodsonseparationkernelsinthissection.The
taxonomy is to group together related work that share common objectives and characteristics to
yieldclearcategoryformationandeasiercomparativeanalysis.Then,weoverviewtherelatedwork
usingtheproposedtaxonomy.
3.1. Taxonomy
The taxonomy is designed based on the analytical framework and is shown in Fig. 4. Level 0 is
therootelement.Level1ofthetaxonomyisdesignedaccordingtotheapplicationschemaoffor-
malmethodsonseparationkernels(seeFig.3).Level2isdesignedconsideringthefunctionalities
in the reference architecture (see Fig. 2), critical properties, and implementations. The subcate-
goriesof“FormalSpecificationandModelofSKs”aredesignedbyconsideringfunctionalitiesin
thereferencearchitecture.Thesubcategoriesof“FormalizationofCriticalProperties”and“Formal
VerificationofSKs”aredesignedusingthecriticalpropertiesofseparationkernels.Sincethe“dam-
agelimitation”propertyisenforcedindirectlybytheotherthreeproperties,thereisnorelatedwork
offormalizationandformalverificationofthisproperty,andweomititinourtaxonomy.Fromthe
implementations of separation kernels (see Table I), we could see that they are almost developed
using the C programming language. Thus, beside binary code we only consider code abstraction
fromtheClanguageinthecategory“CodeAbstractionofSKs”.Wediscussresearchworksoneach
categoryinthefollowingsubsections.
ACMJournalName,Vol.1,No.1,Article1,Publicationdate:January2017.
High-AssuranceSeparationKernels:ASurveyonFormalMethods 1:9
Applying Formal Methods
on Separation Kernels (SKs)
Formal Specification& Formalization of Formal Verification Code Abstraction Code Synthesis
Model of SKs (1) Critical Properties (2) of SKs (3) of SKs (4) of SKs (5)
PMooldiceyl SpFeucnifcictiaotnioanl& SpInetceifrifcaacteion SepDaartaation FIlonwfo rSmeactuiornity STeepmapraotriaoln DaVtae Srifeicpaatrioatnion SeIncfuorrimtya Vtioenri fiFclaotwio n TempVoerarilf iScaetpioanration C La(4n-gau)age Bina(4ry- bC)ode
(1-a) Model(1-b) (1-c) (2-a) (2-b) (2-c) (3-a) (3-b) (3-c)
Fig.4. ProposedTaxonomyofApplyingFormalMethodsonSeparationKernel.
3.2. FormalSpecificationandModelofSKs(Category1)
Thissubsectionoverviewsresearchworksaboutformaldescriptionoffunctionalitiesofseparation
kernels.ExceptkernelinterfaceandpoliciesinFig.2,wegroupresearchworksofotherfunction-
alitiesintothecategory“functionalspecificationandmodel”.
3.2.1. PolicyModel(Category1-a). Aformalpolicyisakindofformalspecificationtodescribe
whatthesystemallowsandprohibits.Formalpoliciesofseparationkernelsactuallydefinethesecu-
rity/safetyrequirementsandcanbecategorizedaccordingtothecriticalproperties.Thepoliciesare
usuallyconfiguredduringsystembuilt-timeandloadedduringinitializationofseparationkernels.
Dataseparationpolicydefinesstrictdataseparationthatdoesnotallowdataexchangebetween
partitions.Thesepoliciesincludememoryseparation,deviceseparation,etc.Forinstance,ARINC
653definesasetofpartitionsandastaticmemoryallocationpolicyforthem[AeronauticalRadio,
Inc.2010].
The inter-partition flow policy (IPFP) [Levin et al. 2007] is a sort of information flow policy
for separation kernels on MILS. Separation kernels map exported resources (e.g., communication
objects) into partitions by a function resource map ∶ resource → partition. IPFP is expressed
abstractlyinapartitionflowmatrixpartition flow ∶ partition×partition → mode,whoseen-
triesindicatethe mode oftheflow.Themode indicatesthedirectionofthe flow,e.g.“Write”and
“Read”.ResourcesfromapartitionareaddressedequivalentlywithrespecttoIPFP.Onepartition
canbeallowedtoaccessallresourcesinanotherpartition.AnothertypeofIPFPisportandchannel
basedinformationflowusedinARINC653.Partitionedinformationflowpolicy(PIFP)[Levinetal.
2010] extends IPFP in SKPP with two different granularities of requirements: partitions and sub-
jects/resourcesThisabstractionallowssubjectsfromapartitiontohavedifferentaccessprivileges
toresourcesallocatedinthesamepartitionoreveninadifferentpartition.
Fault policy is a type of damage limitation policy. A typical fault policy for separation kernels
isthehealthmonitoring(HM)inARINC653.TheHMreportsandrespondstohardware,kernel,
andapplicationfaultsandfailures.ARINC653supportsHMbyprovidingasetofhierarchicalHM
configuration tables and application level error handlers. Scheduling policy is a type of temporal
separation policy. A typical scheduling policy for separation kernels is the partition time window
configuration in ARINC 653. The scheduling specified in ARINC 653 is a two-level scheduling.
The partition scheduling is a fixed, cycle based scheduling and is strictly deterministic over time.
Thiscyclicschedulingconsistsofamajortimeframe(MTF)thatissplitintopartitiontimewindows
(PTW).EachPTW hasanoffsetandaduration,whichisassociatedtoagivenpartition.
3.2.2. FunctionalSpecificationandModel(Category1-b). Weoverviewasetofformalspecifica-
tionsandmodelsofseparationkernelshere.Refinementisoftenappliedtocreateconcretemodels
fromabstractspecificationsinastep-wisemanner.Wecategorizeresearchworksaccordingtospec-
ificationlanguagesused,i.e.system/softwarespecificationlanguages,formallanguagesintheorem
provers,andarchitecturedescriptionlanguages.
ACMJournalName,Vol.1,No.1,Article1,Publicationdate:January2017.
1:10 Y.Zhaoetal.
Usingsystem/softwarespecificationlanguages. Aspecificationlanguageisahigh-levellanguage
otherthanaprogramminglanguageforsystemanalysisanddesignandtoproduceexecutablecode.
Many specification approaches use algebraic or model-theoretic structures to model systems step
bystepbyrefinement.Inthefollowingwedescriberelatedworkusingsoftwarespecificationlan-
guages, such as Z notation, B method, and Alley, to construct formal specifications of separation
kernels.
Craig[2007]concernsentirelywiththespecification,design,andrefinementofoperatingsystem
kernels in Z [Abrial et al. 1980], one of which is a separation kernel. Refinement goes down to
a level where source code in programming languages (e.g., C and Ada) can be extracted from Z
specification. The specification and proofs are done by hand on paper. This work is upgraded in
[VelykisandFreitas2010]bytakingintoaccountseparationkernelrequirementsin[Rushby1981]
and SKPP [National Security Agency 2007]. Craig’s original specification is augmented using Z
notation [Jim and Jim 1996] mechanizing it using the Z/Eves theorem prover. As a consequent,
syntax errors, missing invariants and new security properties to guarantee correct operations are
found.
TheBMethod[Abrial1996]hasbeenusedtoformallyspecifyasecurepartitioningkernel(SPK)
in[Andre´2009].Thehigh-levelspecificationconstitutesacompletearchitecturaldesignofthesys-
temandissimulatedandvalidatedinProB[LeuschelandButler2003].ThePIFPpolicyisrefined
to a level from which C code can be automatically generated. Finally, an open source micro ker-
nel,i.e.,PREX,isadoptedtointegratethePIFPimplementation.MajorfunctionalitiesoftheOS-K
separationkernel[Kawamoritaetal.2010],suchaspartitionmanagement,inter-partitioncommu-
nication, access control, are also designed in the B method. Proof obligations are generated and
checkedusingtheB4freetool.Almostthewholetotalityofthe2,700proofobligationscomprising
theverificationareautomaticallyprovenusingB4free.
Aiming at least privilege separation kernel (LPSK), Phelps et al. [2008] develop a formal se-
curity policy model and a top-level specification in Alloy [Jackson 2012]. They utilize the Alloy
Analyzer to verify the consistency of the specification. The top-level specification is a refinement
ofthePIFPpolicymodelandusesstatetransitionstomodeltwoseparationsubsystemsofLPSK,
systeminitializationandthesystemduringruntime.In[Martinetal.2000;Martinetal.2002],three
levels of abstraction and refinement are used to formally develop the MASK separation kernel in
SPECWARE,whichisanenvironmentforformalspecificationanddevelopment.Theabstractspec-
ification refines the MASK policies and concerns the communication among Cells using strands,
whichisaflowofinstructionsthatareexecutedwhenamessageisinsertedintothestrandofacell.
Itisrefinedtothekernelspecificationprimarilyconcerningthedatastructure.Finally,thebottom
layer specification is manually translated into C source code. For the purpose of information flow
securityoftheXenonhypervisor[McDermottandFreitas2008],FreitasandMcDermott[2011]use
CircustoformallymodelthehypercallinterfacebehaviourofXenon.Circus[Oliveiraetal.2009]
is a combination of Z, CSP and the refinement calculus. The whole model covers a subset of the
hypercallinterfaceandisover4,500pagesofCircus.
Usingtheoremprovers. Theoremprovers(e.g.Isabelle/HOL,Coq)generallyhaveasmalllogical
kernel,providepowerfulexpressivelanguagesforspecification,andsupportreasoningabouthigh-
order logic. They have been applied for formal verification of operating system kernels, such as
seL4 [Klein et al. 2009; Klein et al. 2014] and CertiKOS [Gu et al. 2015]. Inspired by successful
application of theorem provers on general-purpose microkernels, they are adopted on kernels in
recentyears.
TheformalverificationoftheseL4microkernelhasbeendoneusingIsabelle/HOL[Nipkowetal.
2002].TheIsabelle/HOLspecificationofseL4isextendedin[Murrayetal.2013]toformallyverify
informationflowsecurityofseL4.Inordertoactasaseparationkernel,seL4isminimallyextended
by a static partition-based scheduler implementing a static round-robin scheduling between parti-
tions, which are assigned fixe execution time slices. They also make small changes in the kernel
APIsandaddthesecuritypolicy.AimingataprecisemodelofPikeOSandapreciseformulation
ACMJournalName,Vol.1,No.1,Article1,Publicationdate:January2017.