Trusted execution in the cloud



System Documentation

Background Papers


Description of repositories and wikis used for the project.


Remember that only the admin repo is private. All other repos are available to the general public.


Remember that only the is private. All other wikis are available to the general public.


Description of our working environment.

Coming soon

Information for Students

Student specific information.

ITTC and Core Hours

Students need to be in the laboratory during core hours 10am-3pm during weekdays. The only exceptions being classes and one-time activities. When you work other than that is up to you, but you will certainly need to work more than just core hours. Some of you will be nocturnal, some will be morning people, and in quite rare cases you might actually work 8-5. We don’t care as long as you’re around for core hours. If you’re not going to be around, make sure you adviser knows.

During the academic year please hang around Nichols when you’re not in class. You are welcome to use ITTC resources for classwork, hold meetings in the lab, and generally treat the lab as your home as long as it does not interfere with our work.


We will schedule project meetings at least once a week. You need to be there and let your advisor know if for some reason you’re not. Chances are advisers will also meet with their groups separately. How that is structure is up to you and your advisor.

We will also schedule a reading group that you will be asked to attend. Most students have a ton to learn when they join the group and it’s easiest todo that together.


  1. emacs - for papers and code. Use auctex mode for LaTeX. reftex is also exceptionally useful for managing bibliography files. Use the standard markdown mode for markdown files.
  2. latex - for papers and documentation. Use the natbib package for bibliographies and references. Use flyspell for on-the-fly spell checking.
  3. bibtex - for references. We will maintain a BibTeX database that will be common across the project in the doc repository.
  4. beamer - for presentations.
  5. markdown - for documentation, wikis, and we pages
  6. git - for repository management. Commit often and branch for new code development.
  7. GitHub - for repository hosting. We will share all of our code and papers for the project under the armored software group. You must have a GitHub id to work with our repositories.


Publication is the currency of academia and we will publish frequently. Here are some guidelines for papers:

  1. Author lists are students first and faculty second.
  2. Author lists should always err on the side of being inclusive.
  3. Publications written for the project should always include one or more faculty advisers.
  4. Always acknowledge the sponsor using the footnote:

This work in sponsored by the United States Department of Defense

What done means

If you are asked is a development task done, here are your criteria for deciding:

  1. Code compiles and runs in our standard working environment
  2. Makefiles are up-to-date and support system building
  3. Code has been tested in our standard working environment
  4. Code is checked into the proper repository
  5. Documentation is checked into the proper repository
  6. Test cases installed for nightly build testing

Not being done is usually okay. Saying you’re done when you don’t meet the done criteria is always bad.

The Team

Self-sufficiency is not our goal. Ask questions, cite references, and reuse code and systems where possible.