RA-report contains the old MRENCLAVE

[Kailai-Wang]

Context

It normally happens after the enclave update, sometimes the new registered enclave in the teerex registry still contains the old MRENCLAVE, which probably comes from the RA report, even if it's generated live.

Why is that? Maybe ra-report has a cache/time threshold where it only updates the MRENCLAVE in a fixed frequency?

It's a big issue for IDHub because it will convey the wrong MRENCLAVE, related: #1779

---

✔️ Please set appropriate labels and assignees if applicable.

[felixfaisal]

@Kailai-Wang I tried reproducing this bug with scripts, but I was not able to.
I performed an upgrade and checked the Enclave registry and it has the latest MRENCLAVE. Am I missing something here?

[Kailai-Wang]

@Kailai-Wang I tried reproducing this bug with scripts, but I was not able to. I performed an upgrade and checked the Enclave registry and it has the latest MRENCLAVE. Am I missing something here?

In my experience it normally happens when you do back-to-back enclave updates with different MRENCLAVE, then the registry would contain the MRENCLAVE in the first attempt

[BillyWooo]

@Kailai-Wang when you say 'back-to-back`, do you mean updating different MRENCLAVEs in a short time?
For example:

• system running with A-MRENCLAVE
• update a new B-MRENCLAVE
• in a short time, update a new C-MRENCLAVE
• From teerex.enclaveRegistry, there is still B-MRENCLAVE? or even A-MRENCLAVE?

[Kailai-Wang]

Yes in my experience the registry will have B-MRENCLAVE

[felixfaisal]

A follow up question to the above:

• Is this observed when we are running the parachain without tee-dev features?

[Kailai-Wang]

Yes but I can't guarantee that it won't happen under dev. From the code it's getting the mrenclave from RA-report, so we have to really check what's inside it and how it's generated.

[felixfaisal]

Performed couple of enclave-update using the scripts I wrote, and below is the storage for scheduledEnclave

[
  [
    [
      770
    ]
    0x2e9ce4132616aae78ec94b2936952ac06d1fca6f19b4cdc22951e16caeb442f8
  ]
  [
    [
      334
    ]
    0x495348ba6fafa4ac391c403dcfd7048a33cc14a17f16b302307c4cc4a1e257e6
  ]
  [
    [
      399
    ]
    0x5ef7e7aa791c84d7201400efb6e01bcebd7133fb619c0e5f5ac013bf56c8e38b
  ]
  [
    [
      831
    ]
    0xbe2cb1c639b974c5449b76f4ef74da8d6528d611486f690eb09a00fec02fbe72
  ]
  [
    [
      272
    ]
    0xecfd8ed38dc5ed3b5e2a1bc47287e75a322d6b3a5b1890cc92d20df0c2ecbe34
  ]
  [
    [
      892
    ]
    0x0482ac8a2b3161cd45dba284b337ecfa171b654c1f034faae590b1e7db466195
  ]
  [
    [
      710
    ]
    0x50662115cae4d11fdd8689cb4ab776843c8d7a7e4091a50444dc808e9bc45e20
  ]
  [
    [
      212
    ]
    0x75b9ee9780c4a02fa7ec7c8acffe5c212304e1bfaeae778791387472fdba765f
  ]
]

All of them were able to successfully go on to be a part of EnclaveRegistry. So if we were to see this bug again it would be easier to identify the issue if we have the following:

• The log of the new enclave that is running, which is running to register to enclave
• The storage of ScheduledEnclave
• The RA Report of the new enclave that is running, which will be present in the logs

It is difficult to determine that the cause of this could be RA report. But will research more into RA Report generation and if it indeed does some caching that we are not aware of.

[Kailai-Wang]

@felixfaisal did you test it in prod mode? Maybe it only happens with prod mode.

I'm pretty sure it happened a few times already, and not only when I did the enclave update. You can search for "mrenclave mismatch" in slack

[felixfaisal]

I tested it on parachain with tee-dev feature and Enclave is in dev mode, I will test again with Enclave and Parachain in non-dev modes.

[BillyWooo]

• Repeated testing and came to conclusion that: leave it for the moment. Cannot be reproduced any more.
• Do find a small bug inside the deploy.sh about parachain building flag.

[Kailai-Wang]

Haven't observed it for a long time, closing it now