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

▶
posix mini challenge
SMART_READER_LITE
LIVE PREVIEW

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

Mar 21, 2024 228 likes •422 views

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

slide-1
SLIDE 1

POSIX mini-challenge 01

POSIX mini-challenge

Leo Freitas and Jim Woodcock University of York December 2006 @ TC Dublin

slide-2
SLIDE 2

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

slide-3
SLIDE 3

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)

slide-4
SLIDE 4

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

slide-5
SLIDE 5

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?
slide-6
SLIDE 6

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

create, open, close, unlink, read, write, truncate, ftruncate, stat, fstat, mkdir, rmdir, rename, opendir, readdir, rewinddir, closedir, format, mount, unmount

slide-7
SLIDE 7

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
slide-8
SLIDE 8

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?
slide-9
SLIDE 9

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”

slide-10
SLIDE 10

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)
slide-11
SLIDE 11

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
slide-12
SLIDE 12

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
slide-13
SLIDE 13

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
slide-14
SLIDE 14

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
slide-15
SLIDE 15

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
slide-16
SLIDE 16

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)
slide-17
SLIDE 17

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
slide-18
SLIDE 18

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?