1 / 8

Integration of Safe OS Code with Spec# for Reliable Hardware-Software Interaction

This document discusses the integration and verification of safe operating system code using Spec#. It focuses on the interaction between the hardware and software layers, particularly for the Tulip Network Driver. The study details the implementation of statically typed specifications and the challenges of ensuring safety in real-time networking environments. Furthermore, it highlights improvements in static verification tools, memory safety, and the need for an incremental approach to existing hardware interaction code. Future directions include developing a declarative language for safe hardware interaction.

faunus
Télécharger la présentation

Integration of Safe OS Code with Spec# for Reliable Hardware-Software Interaction

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Checking the Hardware-Software Interface in Spec# Kevin Bierhoff (CMU) Chris Hawblitzel (Microsoft Research)

  2. Safe OS code, statically typed (?) Singularity OS Typed Untyped single hardware address space ML Java LISP Safe web plug-in Unsafe C assembler web server ... uint mode = csr6.Read32(); mode &= ~(CSR6.SR | CSR6.ST); csr6.Write32(mode); rxRing.Reset(); csr3.Write32(rxRing.BaseAddress.ToUInt32()); txRing.Reset(); csr4.Write32(txRing.BaseAddress.ToUInt32()); ... TCP/IP network driver kernel

  3. Tulip Network Adaptor host memory RX ring Tulip device own flags entry flags size1 size2 entry csr3 buffer1 address entry csr4 buffer2 address entry entry csr6 entry

  4. Safe Hardware Interaction Layer network driver ... internalvoid StartRxTxMiiSym() requires RxConfigured && TxConfigured; modifies this.rxStarted, this.txStarted; ensures RxConfigured && TxConfigured && RxStarted && TxStarted; { csr6.Write32( CSR6.MBO | CSR6.HBD | CSR6.PS | (3u << CSR6.TR_ROLL) | CSR6.ST | CSR6.SR ); rxStarted = txStarted = true; } ... safe code (Spec#) SHIL(Spec#) device csr6 Spec# = C# + logical annotations

  5. Was violated in original implementation and is now fixed Bug: SHIL pre-condition violated internal void ConfigureHostBus( uintcacheMask, uintbusMask, uintcacheAlignment, uintburstLength) requires (RxStarted == false) && (TxStarted == false); requires (cacheMask & ~(CSR0.WIE | CSR0.RLE | CSR0.RME)) == 0; requiresbusMask == 0 || busMask == CSR0.BAR; requirescacheAlignment >= 0 && cacheAlignment <= 3; requiresburstLength == 0 || burstLength == 1 || burstLength == 2 || burstLength == 4 || burstLength == 8 || burstLength == 16 || burstLength == 32; ensures (RxStarted == false) && (TxStarted == false); { csr0.Write32(cacheMask | busMask | (cacheAlignment << CSR0.CAL_ROLL) | (burstLength << CSR0.PBL_ROLL)); }

  6. Buffer ownership class TulipRxDescriptor { ... internal void Buffer1Claim(Packet! packet) requirespacket.Full; requires!Buffer1Set; ensurespacket.Empty; ensuresBuffer1Set {...} ... } single hardware address space web plug-in own flags flags size1 size2 web server buffer1 address class TulipRxRing { ... internalvoid GiveToDevice( TulipRxDescriptor! descriptor) requires !descriptor.OwnedByDevice; requires descriptor.Buffer1Set && descriptor.Buffer2Set; ensures descriptor.OwnedByDevice; ... {...} ... } buffer2 address TCP/IP buffer network driver kernel

  7. Driver, SHIL code size original code revised code (5 person-weeks) network driver network driver safe code 1800 lines driver code 1800 lines 1400 lines SHIL device (200- page doc) device (200- page doc) csr6 csr6

  8. Conclusions ML,Java Spec# LISP C assembler • Static verification tools have improved • automation • data structures, aliasing, objects, concurrency... • (run-time checking also possible) • Properties are interconnected • memory safety relies on state • Hardware is diverse (and complicated) • packet fragments • Incremental approach on existing code • Future work: declarative SHIL language

More Related