Can We Prove Time Protection?
CCan We Prove Time Protection?
Gernot Heiser
UNSW Sydneyand Data61, [email protected]
Gerwin Klein
Data61, CSIROand UNSW [email protected]
Toby Murray
University of Melbourneand Data61, [email protected]
ABSTRACT
Timing channels are a significant and growing securitythreat in computer systems, with no established solution.We have recently argued that the OS must provide timeprotection , in analogy to the established memory protec-tion, to protect applications from information leakagethrough timing channels. Based on a recently-proposedimplementation of time protection in the seL4 microker-nel, we investigate how such an implementation couldbe formally proved to prevent timing channels. We pos-tulate that this should be possible by reasoning about ahighly abstracted representation of the shared hardwareresources that cause timing channels.
Timing channels are a major threat to information se-curity, they exist where the timing of a sequence ofobservable events depends on secret information [Wray1991]. The observation might be of an externally visibleevent, such as the response time of a server, and might beexploitable over intercontinental distances [Cock et al.2014]. Or it might only be locally observable, i.e. by aprocess or VM co-located on the same physical machine,which still enables remote attacks, if the observing pro-cess has access to the network and is controlled by aremote agent. The seriousness of the threat was recentlyhighlighted by the Spectre attacks [Kocher et al. 2019],where speculatively executed gadgets leak informationvia a covert timing channel.The secret-dependence of events may have algorith-mic causes, e.g. crypto implementations with secret-dependent code paths. Or they may result from interfer-ence resulting from competing access to limited hard-ware resources, such as caches; there exists a wide vari-ety of such micro-architectural channels [Ge et al. 2018b].Whether algorithmic or micro-architectural, thosechannels represent information flow across protectionboundaries, i.e. the boundaries are leaky . Ensuring thesecurity of these boundaries should be the job of the op-erating system (OS); however, no contemporary, general-purpose OS seems to be capable of if. Clearly, this is notan acceptable situation, and we have recently called forOSes to provide time protection [Ge et al. 2018a] as the temporal equivalent of the well-established concept ofmemory protection.Memory protection is a solved problem: the formalverification of seL4 proved, among others, that the ker-nel is able to enforce spatial integrity, availability andconfidentiality [Klein et al. 2014]. This categoricallyrules out information leakage via storage channels (pro-vided that the kernel is aware of the state that can beused for such channels). However, the approach taken inthe seL4 verification has no concept of time, and there-fore cannot make any claims about timing channels . Our aim is to rule out timing-channel leakagejust as categorically as information flow via stor-age.
Put differently, we aim to formally prove correctimplementation of time protection . This paper investi-gates the feasibility of, and prerequisites for, achievingthe stated aim. Obviously we would not bother writingthis paper if we were not convinced that it is feasible toachieve our aim, under certain conditions, which comedown to hardware satisfying certain requirements. Wehave recently demonstrated that not all recent proces-sors satisfy these requirements, resulting in a call for anew, security-oriented hardware-software contract [Geet al. 2018a]. We claim that, for hardware that hon-ours this contract, we will be able to achieve our aimof proving time protection, and thus eliminate micro-architectural timing channels.Note that other physical channels, such as powerdraw, temperature, or acoustic or electromagnetic ema-nation, are outside the scope of this work.
The basic problem we are concerned with is a secret heldby one security domain, Hi, being leaked to another do-main, Lo, which is not supposed to know it. The leakingmight be intentional, by a bad actor (Trojan) inside Hi,constituting a covert channel . Or it can be unintentional,via a side channel . Note that Hi, Lo are relative to a par-ticular secret, we do not assume a hierarchical securitypolicy such as Bell and LaPadula [1976], and there maybe other secrets for which the roles of the domains arereversed. It is the duty of the OS to prevent any unau-thorised information flow, no matter what the system’sspecific security policy might be. a r X i v : . [ c s . O S ] J a n ernot Heiser, Gerwin Klein, and Toby Murray Our notion of a security domain refers to a subset ofthe system which is treated as an opaque unit by the sys-tem’s security policy (i.e. intra-domain information flowis not restricted by the policy). In OS terms, a domainconsists of one or more (cooperating) processes.We assume that the OS provides strong, verifiedmemory protection, and is free of storage channels,seL4 being an example. Our primary concern is micro-architectural channels, i.e. channels that exploit compe-tition for finite hardware resources that are abstractedaway by the instruction-set architecture (ISA), the clas-sic hardware-software contract. This means that algo-rithmic channels are not our primary concern, but wewill discuss in Sect. 4.3 how time protection can be em-ployed to remove such channels (within limits).Like memory protection, time protection is a black-box OS mechanism, that provides mandatory securityenforcement without relying on application cooperation.For realism, i.e. to ensure that contemporary hard-ware is at least close to satisfying the requirements oftime protection (and can fully satisfy them with minorenhancements) we limit our scope in one importantway: we do not (yet) attempt to prevent covert channels through stateless interconnects. Such channels, exploit-ing the finite bandwidth of interconnects through con-current competing access, are trivial to implement: aTrojan running on one core signals by modulating itsuse of interconnect bandwidth, and a spy running on adifferent core measures the remaining bandwidth by try-ing to saturate the shared interconnect. Such channelscan only be prevented with hardware support that is notavailable on any contemporary mainstream hardware. We will be able to extend time protection in a fairlystraightforward way, should such hardware support (orat least an accepted model for it) become available.An obvious example of the excluded scenario wouldbe a covert channel between two virtual machines (VMs)concurrently executing on different cores of the sameprocessor on a public cloud. Such a covert channel isnot a particular concern, as the Trojan in the victim VMdoes not need the co-located spy, as it can communicateby other means, e.g. modulating its network commu-nication. Side channels are a real concern in the cloudscenario, but stateless interconnects reveal no addressinformation. As a consequence, no such side channelshave been demonstrated to date [Ge et al. 2018b], andthey are likely impossible. Intel recently introduced memory bandwidth allocation (MBA) tech-nology, which imposes approximate limits on the memory bandwidthavailable to a core [Intel Corporation 2016]. While this represents astep towards bandwidth partitioning, the approximate enforcement isnot sufficient for preventing covert channels.
There are two ways in which Lo may learn Hi’s secret: bytiming observable actions of Hi, or by Lo observing howits own execution speed is influenced by Hi’s execution.
This channel utilises the performance impact of interfer-ence between processes resulting from competition forshared hardware resources, especially stateful resourcessuch as caches, TLBs, branch predictors and pre-fetcherstate machines. For example, Lo’s rate of progress (per-formance) is affected by cache misses. If Lo shares acache with Hi (either time-sharing a core-private cacheor concurrently sharing a cache with Hi’s core), then themiss rate will depend on Hi’s cache usage. If the cache isset-associative (which almost all of them are nowadays),then the pattern of cache misses will also reveal addressinformation from Hi. Such address information supportsthe implementation of side channels with potentiallyhigh bandwidth, e.g. where the secret is used to index atable [Ge et al. 2018b].An effective exploitation of such a channel is the prime-and-probe technique [Osvik et al. 2006; Percival2005]. Here Lo fills the cache by traversing a buffer largeenough to cover the cache (prime phase). After or whileHi is executing, Lo traverses the buffer again, moni-toring the time taken for each access (probe phase); along latency indicates a conflict miss with Hi’s cachefootprint. The address of the missing access reveals theindex bits of Hi’s access.Prime-and-probe can be used as a high-bandwidthcovert channel, where Hi explicitly encodes informationinto the memory addresses accessed, or as a side channel,where the encoding is implicit in Hi’s normal execution(e.g. via a secret-derived array index). It can be usedfor time-shared (core-private) caches as well as cachesshared between cores.
On a first glance this might seem like a silly case, whyworry about a covert channel if there is an overt one,such as message passing? However, this situation isin fact common: Hi might be a downgrader , an entitytrusted to handle secrets and decide which can be safelydeclassified. A common example is a crypto component,which encrypts secrets, e.g. from a web server, and pub-lishes the encrypted text, by handing them to a networkunit; this is shown in Figure 1.In this case, the leakage might be resulting from analgorithmic channel (e.g. a crypto implementation withsecret-dependent execution), a Trojan modulating the an We Prove Time Protection? H I Web server L O Network StackShared HardwareH I Encryption
Figure 1: Encryption engine as a downgrader. speed of the encryption (possibly via micro-architecturalinterference), or the server itself leaking through thetiming of messages to the crypto component.Time protection here must make execution time de-terministic, meaning that message passing or contextswitching happen at pre-determined times. Obviously,the OS can only provide the mechanism here (determin-istic switch/delivery time), not the policy (the time ofthe switch). This must be set by the system designeror security officer, taking into account issues like theworst-case execution time (WCET) of the encryption.Cock et al. [2014] have proposed a possible model:a synchronous IPC channel switches to the receiveronly once the sender domain has executed for a pre-determined minimum amount of time. It is then left tothe system designer to determine a safe time threshold.
As micro-architectural timing channels result from com-petition for (non-architected) hardware resources, elim-inating them requires removing the competition. Thismeans the OS must either partition those resources be-tween security domains, or reset them to a defined,history-independent state between accesses from dif-ferent domains.Resetting, e.g. flushing caches, only helps where ac-cesses from different domains are separated in time, i.e.for time-shared resources. In other words, resetting onlyworks for resources that are private to an executionstream. In the absence of hyperthreading, this appliesto core-local resources, such as the L1 caches, privateL2 caches (on Intel hardware), TLBs, branch predictors,and core-local prefetchers.Partitioning is the only option where concurrent ac-cesses happen, i.e. for caches shared between cores. Itwould also be the only option for core-local state whenhyperthreading is enabled. However, no mainstreamhardware supports partitioning of hardware resourcesbetween hyperthreads, and such partitioning wouldseem fundamentally at odds with the concept of hy-perthreading, which is based on improving hardwareutilisation by sharing. Consequently there are a plethora of side-channel attacks between hyperthreads [Ge et al.2018b]. We have to conclude that hyperthreading isfundamentally insecure , and multiple hardware threadsmust never be allocated to different security domains(multi-threading a single domain is not a security issue).Partitioning of shared (physically-addressed) cachesis possible without extra hardware support by usingpage colouring [Kessler and Hill 1992; Liedtke et al. 1997;Lynch et al. 1992]. This uses the fact that the associativelookup of a large cache forces a page into a specificsubset of the cache, so only pages mapping to the samesubset, said to have the same colour, can compete forcache space. By ensuring that different security domainsare allocated physical page frames of disjoint colours, theOS can partition the cache between domains. Modernlast-level caches have at least 64 different colours.In general, micro-architectural timing channels can beprevented if all shared hardware can be either partitionedof flushed by the OS , with flushing the only option whereaccesses are concurrent. Together with a few other con-ditions outlined by Ge et al. [2018a], these form part ofa security-oriented hardware-software contract, calledthe aISA (augmented ISA), that allows the OS to pre-vent timing channels. The ISA alone is an insufficientcontract for ensuring security [Heiser 2018; Hill 2018].
We have recently proposed an implementation of timeprotection in seL4, for hardware that conforms to asecurity-oriented aISA [Ge et al. 2019]. It uses cachecolouring to partition shared caches. As even read-onlysharing of code is sufficient for creating a channel [Gul-lasch et al. 2011; Yarom and Falkner 2014], we also colourthe kernel image. This is achieved by a policy-free kernelclone mechanism, which allows setting up a domain-private kernel image in coloured memory.We flush time-shared micro-architectural state oneach domain switch (but not on intra-domain context-switches). For writable micro-architectural state (e.g.the L1 data cache), the latency of the flush is itself de-pendent on execution history (number of dirty lines),which would create a channel. We avoid this channelby padding the domain-switch latency to a fixed value.For generality (see Sect. 4.3) we make determining thepadding time not the job of the OS, but an attribute ofthe switched-from security domain, controlled by thesystem designer. Specifically, we specify that the nextdomain will not start executing earlier than the previousdomain’s time slice plus the padding time.The padding time should obviously be at least theworst-case latency of the flush, but also needs to account ernot Heiser, Gerwin Klein, and Toby Murray for any delay of the handling of the preemption-timerinterrupt by other kernel entries (resulting from systemcalls or interrupts).Finally, interrupts could also be used as a channel,if the Trojan triggers an I/O such that its completioninterrupt fires during Lo’s execution [Ge et al. 2019]. Weprevent this by partitioning interrupts (other than thepreemption timer) between domains, and keep all inter-rupts masked that are not associated with the presently-executing domain.
Padding is a general mechanism that can also be used toprevent algorithmic channels. In the scenario of Figure 1,we can pad the execution time of the downgrader to asafe value (an upper bound of its execution time). Inpractice, this is very wastive if padding is done by busylooping. To make it practical, another Hi process shouldbe scheduled for padding. Obviously, that interim pro-cess must be preempted early enough to allow the kernelto switch domains without exceeding the pad time (asthis might introduce new channels). This may not bestraightforward to implement, but it is clearly possible.
At first glance, one might expect that proving time pro-tection is a hopeless exercise. After all, the precise inter-action between microarchitectural state and executionlatency is unspecified for modern hardware platforms,and the latency of some instructions may vary by ordersof magnitude depending on hardware state. Formallyreasoning about precise execution latencies is thereforeinfeasible [Klein et al. 2011].However, we argue that reasoning about the exactlatency of executions is unnecessary.
The key insightis that these channels are effected by shared hard-ware resources, and if we can prove that no shar-ing happens, there can be no timing channels.
Con-sequently, proving temporal isolation requires formalmodels of microarchitectural state, but these can be keptabstract, providing only detail to identify resources thatneed to be partitioned (and how such partitioning is per-formed), and state that must be reset (and how to resetit). That is, we do not need to know how long an instruc-tion will take to execute, only which micro-architecturalstate its execution time depends on and how this statebehaves wrt. partitioning and flushing.For partitionable state, temporal isolation becomes a functional property (namely an invariant about correctpartitioning) that can be verified without any referenceto time, meaning existing verification techniques apply. For state that requires flushing, correct application ofthe flush is also a functional property. As mentioned inSect. 4.2, the latency of flushing operations themselvesneeds to be hidden by the OS, by padding its execution.Correct padding can be verified with a relatively simpleformalisation of hardware clocks, which allows veri-fying padding time by simply comparing time stamps,reducing this to a functional property as well.Once timing-channel reasoning is reduced to the ver-ification of functional properties, it should be possi-ble to integrate it into existing proof frameworks ofstorage-channel freedom, such as seL4’s informationflow proofs [Murray et al. 2013].Indeed, under this approach timing-channel rea-soning is transmuted into reasoning about storagechannels , reducing it to a solved problem, and alsoenabling reasoning about timing-channels without ref-erence to precise execution time. This possibility mayseem surprising, but it is known that the distinction be-tween storage and timing channels is not fundamental,but refers to the mechanisms used for exploitation [Wray1991]. In our case we transform the temporal interfer-ence problem into a spatial one, by reasoning about theshared hardware resources which the channels exploit.
Carrying out these proofs requires a model of the sharedhardware resources (the microarchitectural model ) thatinfluence execution latencies, as well as a simple modelof a hardware clock (the time model ) to allow reasoningabout elapsed time intervals. Naturally these models areinterrelated: how much an execution step advances thehardware clock naturally depends on the microarchitec-tural state that influences execution time.Crucially, a precise description of this interaction isnot necessary. Instead, the interaction can be faithfullyyet feasibly modelled as follows. Firstly, the microar-chitectural model must delineate the partitionable statefrom the flushable state, and all microarchitectural statemust be partitionable or flushable (Sect. 4.1). Secondly,the time model, which captures how far time advanceson each execution step, is defined as a deterministicyet unspecified function of the microarchitectural state.Then, when the microarchitectural state is properly par-titioned and flushed, one can prove that a security do-main’s execution time cannot be influenced by otherdomains (see Sect. 5.2 below).This construction neatly reflects the basic assump-tions that (i) the hardware provides sufficient mecha-nisms to partition and flush microarchitectural statebetween security domains, that (ii) such mechanisms an We Prove Time Protection? work correctly, and that (iii) these account for all mi-croarchitectural state that influences execution time.
With these models in hand, time protection can then beproved by showing that there is no way in which theexecution of one domain can affect the execution timingof another domain.Specifically the proofs must show that all resourcepartitioning and flushing is applied at all times and notbypassable, and that domain-switches (flushing) is cor-rectly padded to a constant amount of time (under theassumption that the padding value, obtained by a sep-arate analysis, is sufficient). These proofs can then beintegrated with existing storage-channel freedom proofsto derive the absence of timing channels as follows.Without loss of generality, fix some domain (Lo) andconsider one of its execution steps for which we showits timing cannot be influenced by another domain (Hi).There are two possibilities: (Case 1) either it is an ordi-nary user-mode instruction, or (Case 2) it is a trap (asystem call, exception, or interrupt arrival). For Case1, the execution time given by the time model will beaffected by the shared hardware resources in the mi-croarchitectural model. Recall that this effect can bemodelled by an unspecified deterministic function fromthe state of the microarchitectural model to an elapsed(symbolic) time value. For an individual instruction thisfunction will examine the state of the instruction cache,namely the cache set identified by the program counter,and the state of the data cache for any memory addressaccessed by that instruction. Since the access does notfault (otherwise it would be a trap), all such memoryaccesses must lie within the physical memory of thecurrent domain and thus within areas of the cache thatcannot be affected by other partitions (due to correctcache partitioning by the kernel, or correct flushing,e.g. for the on-core L1 cache).A similar argument applies to other microarchitec-tural resources. Thus the resulting execution time can-not be affected by other partitions.For Case 2, we distinguish two sub-cases: The trap iseither (Case 2a) a system call or exception, or (Case 2b)it is the arrival of a timer interrupt signalling a switchto the next domain. For Case 2a, the execution timedepends on the state of the instruction cache wrt. thekernel instructions executed, plus the data cache for anydata accessed. However, in a partitioned system withthe kernel correctly cloned as in Sect. 4.2, the formercannot be affected by other partitions and the latter accesses only data of the current domain. The only re-maining state that might be accessed is global kerneldata, which we will prove is accessed deterministicallyand whose cache state after a domain switch is indepen-dent of prior Hi activity (due to correct flushing). Thusa similar, if naturally more involved, argument appliesas to the user mode case (Case 1). Incorporating general(i.e. non-timer) interrupts we believe is also possible,by partitioning the interrupt set as covered in Sect. 4.2.For Case 2b, we invoke the proof of the constant-timedomain switch property. □ Note that by reflecting elapsed time as a value in thestate of the time model (updated by an unspecified func-tion of the microarchitectural model), timing-channelreasoning is reduced to storage-channel reasoning, andindeed time protection itself can be phrased and provedakin to storage-channel freedom via a suitable noninter-ference property [Murray et al. 2012].
The TLB is an example where the principles of partition-ing and flushing can already be observed in a formalmodel for pure functional correctness: while not yetsuitable for reasoning about timing, Syeda and Klein[2018] provide a logic for functional correctness underan ARM-style TLB. For instance, it is easy to show in thismodel that page tables modifications under one addressspace identified (ASID) do not affect TLB consistency forany other ASID. This is the kind of partitioning theoremwe would make use of for timing-relevant state.The model in this work is a high-level abstractionof the TLB proved sound with respect to a low-levelmodel that would be infeasible to reason about directly.We propose the same for timing behaviour. Instead ofreasoning about a detailed low-level architecture modelwith precise timing information, we only record theinformation needed for timing-independence.
We conclude that proving time protection should bepossible with established formal methods, thanks to thekey insight that they result from spatial-type micro-architectural resources, and can thus be treated as stor-age channels. This requires some reasoning about thosehardware resources, but we expect to get away with veryhigh-level abstractions. The key challenge is to achieveagreement on a hardware-software contract that makesit at least possible to remove timing channels. We areclearly at the mercy of processor manufacturers here! ernot Heiser, Gerwin Klein, and Toby Murray
REFERENCES
D.E. Bell and L.J. LaPadula. 1976.
Secure Computer System: UnifiedExposition and Multics Interpretation . Technical Report MTR-2997.MITRE Corp.David Cock, Qian Ge, Toby Murray, and Gernot Heiser. 2014. TheLast Mile: An Empirical Study of Some Timing Channels on seL4.In
ACM Conference on Computer and Communications Security .Scottsdale, AZ, USA, 570–581.Qian Ge, Yuval Yarom, Tom Chothia, and Gernot Heiser. 2019. TimeProtection: the Missing OS Abstraction. In
Eurosys19 . ACM, Dres-den, Germany.Qian Ge, Yuval Yarom, David Cock, and Gernot Heiser. 2018b. ASurvey of Microarchitectural Timing Attacks and Countermeasureson Contemporary Hardware.
Journal of Cryptographic Engineering
Asia-Pacific Workshop on Systems (APSys) . ACM SIGOPS, Korea.David Gullasch, Endre Bangerter, and Stephan Krenn. 2011. CacheGames – Bringing Access-Based Cache Attacks on AES to Prac-tice. In
Proceedings of the IEEE Symposium on Security and Privacy .Oakland, CA, US, 490–505.Gernot Heiser. 2018. For Safety’s Sake: We Need a New Hardware-Software Contract!
IEEE Design and Test
35 (March 2018), 27–30.Mark D. Hill. 2018. A Primer on the Meltdown & Spectre HardwareSecurity Design Flaws and their Important Implications.
ComputerArchitecture Today (Feb. 2018).Intel Corporation 2016.
Intel 64 and IA-32 Architecture SoftwareDeveloper’s Manual Volume 2: Instruction Set Reference, A-Z
ACM Transactions on Computer Systems
10 (1992), 338–359.Gerwin Klein, June Andronick, Kevin Elphinstone, Toby Murray,Thomas Sewell, Rafal Kolanski, and Gernot Heiser. 2014. Com-prehensive Formal Verification of an OS Microkernel.
ACM Trans-actions on Computer Systems
32, 1 (Feb. 2014), 2:1–2:70. Gerwin Klein, Toby Murray, Peter Gammie, Thomas Sewell, and SimonWinwood. 2011. Provable Security: How feasible is it?. In
Workshopon Hot Topics in Operating Systems . USENIX, Napa, USA, 5.Paul Kocher, Jann Horn, Anders Fogh, Daniel Genkin, Daniel Gruss,Werner Haas, Mike Haburg, Moritz Lipp, Stefan Mangard, ThomasPrescher, Michael Schwartz, and Yuval Yarom. 2019. Spectre At-tacks: Exploiting Speculative Execution. In
IEEE Symposium onSecurity and Privacy . IEEE, San Francisco, 19–37.Jochen Liedtke, Hermann Härtig, and Michael Hohmuth. 1997. OS-controlled cache predictability for real-time systems. In
IEEE Real-Time and Embedded Technology and Applications Symposium (RTAS) .IEEE, Montreal, CA, 213–223.William L. Lynch, Brian K. Bray, and M. J. Flynn. 1992. The effect ofpage allocation on caches. In
ACM/IEE International Symposium onMicroarchitecture . 222–225.Toby Murray, Daniel Matichuk, Matthew Brassil, Peter Gammie, Tim-othy Bourke, Sean Seefried, Corey Lewis, Xin Gao, and GerwinKlein. 2013. seL4: from General Purpose to a Proof of InformationFlow Enforcement. In
IEEE Symposium on Security and Privacy . SanFrancisco, CA, 415–429.Toby Murray, Daniel Matichuk, Matthew Brassil, Peter Gammie, andGerwin Klein. 2012. Noninterference for Operating System Ker-nels. In
International Conference on Certified Programs and Proofs .Springer, Kyoto, Japan, 126–142.Dag Arne Osvik, Adi Shamir, and Eran Tromer. 2006. Cache Attacksand Countermeasures: The Case of AES. In
Proceedings of the 2006Crytographers’ track at the RSA Conference on Topics in Cryptology .Colin Percival. 2005. Cache Missing for Fun and Profit. In
BSDCon2005 . Ottawa, CA.Hira Syeda and Gerwin Klein. 2018. Program Verification in thePresence of Cached Address Translation. In
Interactive TheoremProving, ITP , Vol. 10895. Springer’s LNCS series, Oxford, UK, 542–559.John C. Wray. 1991. An analysis of covert timing channels. In
Proceed-ings of the 1991 IEEE Computer Society Symposium on Research inSecurity and Privacy . IEEE, Oakland, CA, US, 2–7.Yuval Yarom and Katrina Falkner. 2014. Flush+Reload: a High Reso-lution, Low Noise, L3 Cache Side-Channel Attack. In