POSIX mini-challenge Leo Freitas and Jim Woodcock University of - PowerPoint PPT Presentation

POSIX mini-challenge 01 POSIX mini-challenge Leo Freitas and Jim Woodcock University of York December 2006 @ TC Dublin

POSIX mini-challenge 02 A grand challenge • Tony Hoare automatically verified software: a grand scientific challenge for computing • UK EPSRC-funded meetings, US NSF-funded meetings • Z¨ urich conference vstte.inf.ethz.ch • Macau conference www.iist.unu.edu/icfem06 • FACJ 2006, IEEE Computer articles, April 2006, October 2006 • research roadmap qpq.csl.sri.com • UK-China network • VSR-net vsr.sourceforge.net

POSIX mini-challenge 03 Hoare’s Verification Grand Challenge A mature scientific discipline should set its own agenda and pursue ideals of purity, generality, and accuracy far beyond current needs what should we do? • achieve a significant body of verified programs • precise external specifications • complete internal specifications • machine-checked proofs of correctness • a collection of verified programs – 1,000,000 lines – replacing existing unverified ones (i.e., UNIX-POSIX)

POSIX mini-challenge 04 Deliverables 1. a comprehensive theory of programming • covering the features needed to build practical and reliable programs 2. a coherent toolset • automating the theory and scaling up to large codes 3. a collection of verified programs

POSIX mini-challenge 05 Formalising POSIX file-stores • requirements • discussion of objectives: JPL mini-challenge! vstte.ethz.ch/Files/joshi-holzmann.pdf • POSIX documentation guideline – standards – formal specification – Morgan & Sufrin’s UNIX file store • achieved so far • choosing formalisms • conclusions • discussion: what now/next?

POSIX mini-challenge — requirements 06 1800 APIs, where shall we start? Proposal: orthogonally layered approach (Intel inspired) • functionality modelling • hardware interfacing • fault-tolerance guarantees • risk/hazard analysis JPL minimal interface c reate, open, close, unlink, read, write, truncate, ftruncate, stat, fstat, mkdir, rmdir, rename, opendir, readdir, rewinddir, closedir, format, mount, unmount

POSIX mini-challenge — requirements 07 What to avoid? — JPL suggestions • user/group/other file permissions • hard- or symbolic-links • sockets, pipes, networking (i.e., have just plain files) In the spare time . . . • user-level operations – encryption – directory contents listing – operations with regular expressions • multi-threading and real-time • generic interface for most NAND devices

POSIX mini-challenge — requirements 08 What is our ambition? • initials scope: POSIX subset enough for flash memory • whole XNFS (network file system) interface • as much user utilities as possible Open questions: • is the whole POSIX to be a target? • set the standard for UNIX domain modelling?

POSIX mini-challenge — requirements 09 What is JPL’s ambition? — fault-tolerance issues • NAND flash hardware faults – bad blocks and read errors • reset robustness “no corruption in the presence of unexpected power loss” • JPL multi-threading disclaimer: performance traded for simplicity “we make the very conservative guarantee that the result of executing concurrent filesystem operations is equivalent to executing them in some serial order”

POSIX mini-challenge — objectives 10 What do we want? Formal model of POSIX/UNIX • functional model • hardware requirements • risk analysis and fault-tolerance dependability • do we intend to aim at coding/prototyping? JPL using our work • minimal subset first • fault-tolerance in hostile environment • flash memory hardware issues (i.e., balance levelling)

POSIX mini-challenge — documentation 11 What documents are available? The Single UNIX Specification Version 3 — Book • index/reference manual for IEEE Std. 1003.1 2001 (POSIX) • CD-ROM: set of (4000p.) requirements + specifications • www.opengroup.org/pubs/catalog/g041.htm • www.opengroup.org/onlinepubs/009695399/ • www.unix.org/version3 Z specification of POSIX — ftp.sei.cmu.edu • *real-time distributed communication* – endpoint data/message transfer: broad/multi/unicast • C-language interface for POSIX

POSIX mini-challenge — documentation 12 What documents are available? XNFS Version 3W — PDF • POSIX (network) file store interface • greatly detailed requirements • www.opengroup.org/pubs/catalog/c702.htm Morgan & Sufrin’s UNIX file store in Z — paper • *refinement to a Z hashmap (JML-aware)* • mechanically verified in Z/Eves • Fu Zheng’s MSc. dissertation

POSIX mini-challenge — documentation 13 What documents are available? Intel flash file system core — PDF • POSIX-aware interface for flash memory devices • detailed requirements and architecture • covers functionality, hardware, and fault-tolerance! • download.intel.com/design/flcomp/manuals/30443601.pdf Other flash memory file systems — WWW • IBM JFSS2 — suitable for NOR FS • YAFFS2 — improved version NOR+NAND (JPL suggestion) • en.wikipedia.org/wiki/YAFFS

POSIX mini-challenge — achievements 14 What do we have already? Morgan & Sufrin’s UNIX file store in Z/Eves IEEE 1003.21 RTDS in Z/Eves • improved version of Z spec. aimed at automation • model of priority message queues • model of endpoints for data transfer • system-wide and local-endpoint operations • multi-cast groups for endpoints • covers IEEE companion requirements document

POSIX mini-challenge — choosing formalisms 15 What shall we use for modelling? • not to be a burden or a competitive task • Z subset to allow interoperability (e.g., with B)? • JML/Spec# translators as target for coding/prototyping? • extend CZT Z2B and Z2JML (prototype) translators Importance of layered work • allows parallelism: functionality � hardware � fault-tolerance • requires an agreed architecture: Intel’s flash memory core (?) • e.g., occam-like POSIX-aware OS available

POSIX mini-challenge — choosing formalisms 16 What shall we use for modelling? Formalism interchange • trading assertions among tools & techniques • Z2B & B2Z translators • JML/Java for prototyping • Spec#/C# for implementation • JML2Spec# ? By-products • domain modelling for UNIX standardisation • interoperability among methods (theory) and their tools (practice)

POSIX mini-challenge — conclusions 17 What have we learned? General theorem proving laws • also used in Mondex, and UNIX hashmap file store • reuse of (general) laws ⇒ greater automation – injectivity: function and sequence updates – finiteness: sets and schema bindings – free types: injectivity of constructors – schema calculus: surgical expansion Open source Z/Eves • Canadian government negotiation for EVES licence • powerful theorem proving technology @ York

POSIX mini-challenge — discussion: what now/next 18 What to do next? Aim at JPL minimal subset of POSIX first What to do with the available models in Z? • refactor them for interoperability with other methods? • redo the models from scratch via requirements doc? How will be integrate/progress our work? • use VSR @ sourceforge for discussion and archive • independent student projects: interoperability of methods/tools?