
Using TLA+ to Understand Xen Vchan - technion
http://roscidus.com/blog/blog/2019/01/01/using-tla-plus-to-understand-xen-vchan/
======
pron
> Writing formal proofs is a little tedious, largely because TLA is an untyped
> language.

I've written a somewhat lengthy discussion of this point on the TLA+
subreddit:
[https://www.reddit.com/r/tlaplus/comments/abi3oz/using_tla_t...](https://www.reddit.com/r/tlaplus/comments/abi3oz/using_tla_to_understand_xen_vchan/ed0imf1/)

~~~
mjb
I agree with a lot of that, but in practice some syntactic sugar around types
in TLA+ (or at least canned type invariant macros) would make it easier to
write concise readable specs. Think "x is a natural number", "y is a member of
set x", etc. It wouldn't satisfy the type theory folks, but would be nice for
TLA+ users. In practice, it seems like everybody (including me) ends up re-
writing a whole lot of type invariants in each TLA+ spec, and it would be nice
to avoid that both to reduce boilerplate and to communicate to the reader what
the author's intent was around data types.

~~~
pron
It may be worthwhile to allow declarations of the form

    
    
        VARIABLE x ∈ Nat
    

but I haven't considered all the implications of doing that. May be worth a
discussion on the mailing list or at the conference in September.

As to "satisfying the type theory folks," I'm not sure what it means. Type
theory studies the features of typed formalisms; it makes no claims as to
_when_ working in a typed formalism is preferable to working in untyped ones
(although different people have different opinions). There are implementations
of TLA in typed formalisms (in particular, Isabelle and Coq). Lamport explains
why he designed TLA+ as an untyped language.

~~~
mjb
I think it is worth a discussion.

I simply meant that adding simple macros wouldn't make TLA+ typed, and so
wouldn't make the people who think TLA+ should be typed any happier than they
are today.

~~~
pron
There are typed TLA formalisms[1], but they're not called TLA+. I don't know
what it means to want TLA+ to be typed. It's like saying someone wants the
untyped lambda calculus to be typed. I can understand someone who thinks
Lamport was misguided in designing TLA+ as an untyped formalism, but so far it
seems that he was right (for the reasons I detailed in my Reddit comment).

[1]: [https://www.isa-afp.org/entries/TLA.html](https://www.isa-
afp.org/entries/TLA.html),
[https://drive.google.com/file/d/1rAn3N5hViv3xNe2E55lMzpFFym1...](https://drive.google.com/file/d/1rAn3N5hViv3xNe2E55lMzpFFym1lpx9C/view)

------
transpute
Additional information on Xen inter-VM communication is available at
[https://wiki.xenproject.org/wiki/Argo:_Hypervisor-
Mediated_E...](https://wiki.xenproject.org/wiki/Argo:_Hypervisor-
Mediated_Exchange_\(HMX\)_for_Xen)

 _> The technologies provided by VMMs for communication between VMs have a
critical impact on VM isolation properties, on the confidence components can
have in the delivery of data and in the integrity of the data that is
received. The video below identifies aspects of inter-VM communication system
architecture that support important properties that are valuable for building
secure systems. Terminology is introduced to enable classification of the
existing body of art and survey relevant communication technologies in modern
hypervisor, OS and microkernel systems. An example is presented — Argo, an
inter-VM communication mechanism developed for the Xen hypervisor — and how it
is distinguished from other communication channels on the Xen platform and
elsewhere._

------
michaelmior
Always love seeing more examples of TLA+ in action!

> One really nice feature of TLC is that (unlike a fuzz tester) it does a
> breadth-first search and therefore finds minimal counter-examples for
> invariants.

It's worth noting that many fuzzers go to great lengths to produce examples
that are as small as possible, but it's true that this just comes naturally
with TLC.

~~~
im_down_w_otp
It seems like an odd comparison though. Considering that TLC is exercising a
very, very coarse model and a fuzzer is usually exercising a real
interface/implementation. The former is dealing with an idealized
simplification and the latter is dealing with a shape of real domain coverage
when searching for counter-examples.

Making even moderately complex TLA+ models or minor iterations on a simple
model's depth of representation often results in exploding the search space
for TLC and consequently the time to perform checking.

Both classes of tools are useful, but the comparison seemed odd since you
wouldn't use TLA+ like a fuzzer, nor vice versa.

~~~
pron
> Considering that TLC is exercising a very, very coarse model and a fuzzer is
> usually exercising a real interface/implementation. The former is dealing
> with an idealized simplification and the latter is dealing with a shape of
> real domain coverage when searching for counter-examples.

TLC checks the TLA+ specification, however detailed it is. In practice, it's
true that it is usually much more useful to specify at a level well above the
code, but it could be at the same abstraction level as the code (the
specification could even be mechanically generated from the code), or even, in
principle, much finer: you can refine the TLA+ specification to an arbitrary
level, including down to the level of electronics in the CPU. However, very
fine specifications are far less practical.

> Making even moderately complex TLA+ models or minor iterations on a simple
> model's depth of representation often results in exploding the search space
> for TLC and consequently the time to perform checking.

You can avoid the explosion by asking TLC to sample the behaviors in the same
way a fuzzer does, but then you'll lose the exhaustiveness and the proof of
absence of errors.

~~~
im_down_w_otp
I'm aware of both of these things.

In either case the purpose and thus optimization of each kind of tool is
fairly different, even if abstractly they're both "state space exploration",
which made the comparison seem odd to me.

------
sidcom
What a well written article!

