Skip to content
This repository has been archived by the owner on Jun 17, 2024. It is now read-only.

A memory and data model for miTLS #240

Open
11 of 16 tasks
nikswamy opened this issue Nov 5, 2019 · 2 comments
Open
11 of 16 tasks

A memory and data model for miTLS #240

nikswamy opened this issue Nov 5, 2019 · 2 comments

Comments

@nikswamy
Copy link
Contributor

nikswamy commented Nov 5, 2019

We have in several related branches a prototype implementation of the miTLS memory model
https://github.com/mitls/mitls-papers/wiki/The-Memory-Model-of-miTLS (private link)

To merge this into the no_hsl branch of miTLS the following work items need to be completed

F* branch: nik_dynamic_regions to be merged to master

  • Runtime support for dynamic regions in kremlin extraction (@protz )
  • We're starting with just a no-op runtime support for the dynamic region operations, mapping them to the existing malloc support. @aseemr
  • KreMLin support for const buffers (@protz)
  • Extending the HyperStack memory model to support the interface of dynamic regions (@aseemr )
  • An implementation of the witnessed_functorial lemma in LowStar.Monotonic.Buffer (@aseemr )
  • An implementation of a Buffer.sub variant that does not require a concrete length field, i.e., something like what's below. (thanks ! @R1kM )
assume
val sub (c:buffer 'a) (i:uint_32) (len:Ghost.erased uint_32)
  : Stack (buffer 'a)
    (requires fun h ->
      live h c /\
      U32.v i + U32.v (Ghost.reveal len) <= length c)
    (ensures fun h0 c' h1 ->
      h0 == h1 /\
      c' `sub_buffer i (Ghost.reveal len)` c)

EverParse changes

  • Accessors and jumpers should not take a concrete slice length. Instead they should take at most a pointer and a ghost length, as follows @tahina-pro
let accessor (p1:parser k1 t1) (p2:parser k2 t2) (g:gaccessor p1 p2 l) =
    pos:u32 -> b:buffer u8 -> len:erased u32 -> 
    Stack u32
    (requires fun h -> 
        valid (as_slice b len) p1 pos h /\ ... )
    ...
  • Accessors for tag of a tagged union @tahina-pro
  • Accessor for the discriminator of the if/then/else type @tahina-pro
  • Move mitls-fstar/src/tls/LowParse.Repr to lowparse @nikswamy @tahina-pro
  • Support for list reprs, with combinators on it like fold, etc. @nikswamy
  • QuackyDucky changes to auto-generate reprs for all types in the rfc (@ad-l @tahina-pro ?)
    For each type t, it should produce two type abbreviations:
let ptr = R.repr_ptr_p t t_parser
let pos (b:R.const_slice) = R.repr_pos_p t b t_parser

And for each field it should produce, either a FieldAccessor or a FieldReader

e.g.,

/// Reader for the protocol version
noextract
unfold
let version_reader =
  R.FieldReader
    CH.accessor_clientHello_version
    Parsers.ProtocolVersion.protocolVersion_reader

/// Accessor for the extensions
noextract
unfold
let extensions_field =
  R.FieldAccessor CH.accessor_clientHello_extensions
                  Parsers.ClientHelloExtensions.clientHelloExtensions_jumper
                  Parsers.ClientHelloExtensions.clientHelloExtensions_parser32

As we figure out how to do lists, we will require more things to be emitted by QD

miTLS changes

  • ParseFlights, Receive, Transcript use the new reprs @nikswamy
  • Provide access to the ith element of a list whose element sizes are constant @nikswamy
  • A selected example from Nego uses reprs @nikswamy
    • Negotiation.accept_ServerExtension
    • Negotiation.accept_ServerExtensions
  • A stateful API for transcript and conditional erasure of transcript values

We should maintain the functionality of no_hsl, as defined by CI

@ad-l
Copy link
Contributor

ad-l commented Nov 6, 2019

Sounds like a good plan, I'm happy to take care of the QD changes as soon as LowParse.Repr.fst is moved to LowParse

@aseemr
Copy link
Collaborator

aseemr commented Nov 27, 2019

The support for the witnessed buffer lemma and dynamic regions is in F* master. Remaining tasks there:

  • Weaken the preconditions of existing ralloc and ralloc_mm functions to work on heap regions

  • Add no-op extraction for dynamic regions that defaults to malloc etc.

Hope to finish them soon.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants