)]}'
{
  "commit": "3bb8a1ba66c1a1c4ae6e501f4529a88dd23076ed",
  "tree": "b29680c2d9fe1032ef90c62f611e2b9a85308b99",
  "parents": [
    "7ef24d911e4c2af34054edcef2d4588f0d5c98e5"
  ],
  "author": {
    "name": "David Chisnall",
    "email": "github@theravensnest.org",
    "time": "Tue May 21 17:05:58 2024 +0100"
  },
  "committer": {
    "name": "David Chisnall",
    "email": "davidchisnall@users.noreply.github.com",
    "time": "Thu May 23 14:30:59 2024 +0100"
  },
  "message": "Remove the exciting jump instruction from boot.S\n\nThis cjalr cra is in some code that is first hit after a cjal and so the\ncjalr cra returns.  The caller then discards the value written back to\ncra as the link operation in the jump-and-link instruction.  It is then\nused as a call, with cra initialised to a jump address.\n\nThis was done as a code-size optimisation, but there\u0027s actually no need\nto zero the registers at the start.  The code that runs with the\n(possibly uninitialised) values in registers (most implementations will\nzero in boot ROM or hardware anyway) all runs with access to the\nprimordial capabilities and so there is no way that this can possibly\nleak information.\n\nThe first untrusted code runs after the *second* pass through this\nblock.\n\nSimply removing this should shave 10 bytes off the loader without\naffecting security.  More importantly, this is the *only* place where we\nabuse cjalr in this way.  This abuse is incompatible with separating\nsentries into forward and backward control-flow arcs (see\nMicrosoft/CHERIoT-Sail#54), which has a much bigger impact on security.\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "60da6f0ace6ea63ac753877d8347ffb2e0933ce6",
      "old_mode": 33188,
      "old_path": "sdk/core/loader/boot.S",
      "new_id": "ae915cba3b2a31537ee6c5d0488c8f027135dc5c",
      "new_mode": 33188,
      "new_path": "sdk/core/loader/boot.S"
    }
  ]
}