Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migration: update system integration #91

Closed
7 tasks done
tjkirch opened this issue Jul 22, 2019 · 4 comments · Fixed by #930
Closed
7 tasks done

Migration: update system integration #91

tjkirch opened this issue Jul 22, 2019 · 4 comments · Fixed by #930
Assignees
Labels
type/enhancement New feature or request
Milestone

Comments

@tjkirch
Copy link
Contributor

tjkirch commented Jul 22, 2019

Before rebooting for an update:

  • Pull migration list from the TUF metadata
  • Select relevant migrations for this update based on incoming/outgoing versions of update
  • Download (to persistent storage) and verify relevant migrations from metadata-specified location if they are not already included in the image (with matching checksum)
  • Cache TUF metadata required to verify the migration from the root.json installed on the verity partition
    • Add functionality to record and retrieve older root.json versions in tough
  • Read the directory as a filesystem-based TUF repo when running migrations
  • Use pentacle to execute the trusted version as a sealed memfd
@tjkirch
Copy link
Contributor Author

tjkirch commented Aug 21, 2019

Sample migration metadata in some TUF-signed metadata file in repo:

("0.0", "0.1"): ["migrate_0.1_bla"],
("0.1", "0.2"): ["migrate_0.2_foo", "migrate_0.2_bar"],

(That's a "from" version, a "to" version, and list of migrations filenames. The migration filenames are listed in targets.json, so they're validated at that level.)

Or, instead of a tuple, could be a nested mapping, with the "from" version at the outside, and (potentially multiple) "to" versions on the inside.

The idea of allowing multiple "to" versions (in either format) is if we want to allow for migrations to make bigger jumps between versions for efficiency.

Either way, we do need the "from" and "to" versions, rather than walking through versions, because there's no way to know what version was before "1.0", for example.

This was referenced Aug 21, 2019
@tjkirch
Copy link
Contributor Author

tjkirch commented Sep 26, 2019

Still needs testing, but @sam-aws got most of this in #186!

@tjkirch tjkirch added the type/enhancement New feature or request label Oct 2, 2019
@tjkirch tjkirch added this to the Public Preview milestone Oct 24, 2019
@iliana iliana added the urgent label Jan 22, 2020
@tjkirch tjkirch assigned iliana and unassigned sam-aws Jan 22, 2020
@tjkirch tjkirch removed this from the Public Preview milestone Feb 18, 2020
@iliana
Copy link
Contributor

iliana commented Mar 21, 2020

Hmm, what I'm planning on doing in tough doesn't take into account downgrades where the older partition has an older root.json.

For example, if v0.4.2 is released with root.json version 3, and a downgrade is requested to v0.4.1 with root.json version 1, the cached repository metadata wouldn't include root.json version 2.

I think updog will need to know the version of root.json present in an image, which may be a more general "can we associate arbitrary metadata with an image version" question.

@iliana
Copy link
Contributor

iliana commented Mar 23, 2020

Spoke with @bcressey and we think we can work around the rollback issue by downloading all versions of root.json, which we can do without even making any changes to tough (although the "fetch this version of root.json" method might be worth including in tough).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type/enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants