Go through the above file by the start of class, Feb 23. We
will use class time to work on the following exercises (due
March 1): optimize_0plus_b, ceval_example2,
loop_never_stops, stack_compiler (extra credit:
stack_compiler_correct).

Assignment, due Feb 23: Do all 1-star exercises, and
ev_sum, ev_ev__ev, total_relation, empty_relation, le_trans,
le_plus_l, leb_correct (for this one, you may want to use
earlier lemmas), exp_match_ex1, reflect_iff

Assignment, due Feb 2 (at 2pm): Do all 1-star
exercises in Basics.v, as well as mult_S_1, andb_true_elim2,
and boolean_functions

The initial material is based on Software
Foundations (v4.0), but is slightly more recent. Therefore,
some of the future material linked on the Software Foundations web
site may change; the above-linked material is primary. Discussions
and announcements on Piazza (sign
up, if you haven't already). See Resources
section below for useful information on Coq and Proof General.

Overview

Most software is rigorously tested before it is deployed. But
testing is not enough, not even in practice, as the well-known
litany of bugs and security vulnerabilities in mature software
attests. If you want high assurance that your software does what
it is supposed to (or that it does not do what it is not
supposed to), you need to look beyond testing. This course is
focused on technology to assist in the development of
high-assurance proofs about important properties of software,
e.g., those regarding its security.

Outline

This course will be divided into roughly three parts.

During the first part, we will focus on developing formal
proofs using the Coq proof
assistant. Normally, when we think of a "proof", we think of
an informal English description of an argument. But such English
descriptions may have mistakes that go undetected, and so informal
proofs do not provide the high assurance we want. To do better, a
"proof" will be a formal object that we will construct with the
assistance of Coq, which will ensure that the proof is valid.
By valid, we simply mean that each step in the proof follows from
the basic rules of a given (higher-order) logic, and that taken
together, the steps allow us to conclude that the given property
holds.

Modern proof assistants, such as Coq, provide a uniform
environment for writing code, models of systems and mathematical
objects, logical specifications, and proofs. Programs in Coq are
written in a typed, functional language similar to OCaml, except
that the type system is much more powerful. That extra power is
used to reflect specifications and logical (math) properties as
types, while proofs are represented as functional expressions that
build evidence of the validity of a given specification. In this
fashion, Coq is able to reduce proof-checking to a form of
type-checking. In other words, the type-checker of Coq prevents
you from assembling a purported proof unless the proof is actually
valid.

For the second part, we will widen the net and look
at different tools and technologies, in particular, at Bedrock, F-star, Dafny,
Frama-C, and
perhaps other tools, depending on the interests of the students in
the class. We expect to spend a 2-3 class lectures or so on each
of these. The goal here is to learn enough about each tool to get
a sense of its strengths and weaknesses, especially as compared to
other tools. Students will participate in presenting tools they
find most interesting.

The final phase of the course will be focused on individual
projects. By this point, students will have learned enough
about the space of possibilities to pick a topic area to dig into
more deeply, e.g., by using it to build some verified software, or
to formalize an idealized system and prove metatheoretic
properties about it. While students are working on their projects,
class time will consist for further delving into the advanced
topics begun in the second third of the class.

Syllabus

Project proposal, April 7

Take-home final exam, May 11-13

Project final writeup, May 17

Prerequisite: There is no official prerequisite for this
class (beyond an undergraduate CS degree); we will attempt to make
it largely self-contained. However, as Coq is a functional
programming language, some familiarity with functional programming
will be important (ideally, with OCaml). Students should also feel
comfortable with mathematical thinking and pencil-and-paper proofs
(or be willing to put in the time to get better). We will also be
reading some technical papers from the programming languages
research literature, so having taken CMSC 631 will be helpful.
That said, we will review programming languages concepts crucial
for understanding particular papers prior to reading them. Contact
the instructor if in doubt.

Grading: Graded work is as follows:

Homeworks (40%) There will be several problem sets in Coq in
the first 1/3 of the course, and 1-2 other problem sets during
the last third.

Class participation (5%). Students are expected to come to
class and participate in discussions. Many times, class periods
will involve lectures and exploration of new tools, and students
will be expected to contribute presentations about tools of
interest. Grading criteria for in-class presentations are given
below.

Project (25%). Students will propose projects approximately
two months into the semester, to be completed by the end of the
semester (during its last 5 weeks). More details below.

Final Exam (30%). There will be a comprehensive final exam,
which will count for comp credit.

Presentations: Students making presentations will be graded
on the following criteria:

understanding: does the presenter understand the
material?

thoughtfulness: does the presenter have insights and
opinions beyond what was in the paper?

background/perspective: did the presenter read
background papers?

clarity: can the audience understand the presentation?
is the "big picture" clear? are there useful examples?

materials: do the slides or use of blackboard
illustrate and support the talk? are there diagrams to help
convey the technicalities? (when your talk gets into deep
territory, a diagram is worth 10K words)

delivery: has the the presenter practiced?

non-regurgitation: did the presenter do something
beyond simply typing sections of the paper as bullet points? did
the presenter motivate the ideas in their own words or just
state ideas from the paper verbatim?

answering questions: can the presenter handle questions
from the audience?

Remember that you will likely be able to explain more detail than
you can hope to cover in a single lecture. This is one reason that
it's hard work to prepare a good presentation: not only do you need
to understand the paper, but you need to filter out the irrelevant
details and amplify the key arguments. You'll probably have omit
entire sections of the paper from your talk -- don't worry about it.
Simply mimicking the structure of the paper ("regurgitating it")
tends to produce a disconnected sequence of boring facts. A good
talk should tell a story; every idea should be motivated, and all
facts should fit together in a coherent picture. Telling such a
story in a short time often requires creating your own explanations,
motivation, and examples. I would recommend reading some advice
by
Simon Peyton Jones on giving good presentations.

Academic Dishonesty: The university policy on academic
dishonesty is strictly followed. All graded materials (whether
exams, summaries, presentations, or projects) must be strictly
individual efforts. In the case of a group project or assignment,
only collaborations within the group are permitted.

Project

Each student will complete a final project. Projects, done
individually or in groups, will be defined according to the
participants' own interests. A student may choose to work on
verified data structures or algorithms, protocols, etc., or may
formalize some basic results from mathematics, programming
languages theory, etc. (e.g., perform the formalization in a
published paper in Coq, reproducing its results with higher
assurance).

Possible project topics should be discussed with the instructor
prior to submitting a proposal, to make sure they are in scope.
The final project writeup is due May 17. The project
proposal should be submitted by April 7, by e-mail.
It should be 1-2 pages in length, and consist of the following
components:

Problem context and project goal (1-2 short paragraphs).

Approach (1 paragraph)

Per-week timeline (bullet list covering 6 weeks, up to May 17)

Final deliverable, if any, to accompany final report (bullet)

One example project might be to mechanize the metatheory of Miller
et al's paper on authenticated data structures (ADS). The
first paragraph of the proposal would review what Miller's scheme
is. The second would state the goal for the project: To mechanize
the metatheory of the paper; in particular to mechanize, in F*
(say), the definitions of the operational semantics, type system,
auxiliary mathematics, and proof of security and correctness. Then
would come the bullet list, listing the tasks to be undertaken
each week. Finally would come the listing of the deliverable: A
report describing the artifact produced and the process and
pitfalls, along with the artifact itself and how the instructor
can use it to check the results.

Reading papers

Here is some useful advice about how to read papers. Once you get
in the groove, you should expect to spend 1-3 hours per paper (you
do not need to understand every detail, especially for the longer
papers).