`ace.import` may be difficult to architecturally guarantee DIEL

[lfiolhais]

The ace.import instruction is composed of two coarse operations: a set of loads, and an authentication check. Per DIEL, memory operations don't provide any guarantees about their execution timing. The same happens for the load operations in ace.import. However, the authentication check must follow DIEL. We currently don't know what is the best way to mandate this behavior without splitting the instruction.

@mocenigo @radimkrcmar @ruuddw

[ruuddw]

So are you proposing to split the load and authenticate parts? I believe I proposed something like that before (load/store become just load store, without any authentication or sealing side effects, and import/export don't implement the data transfers but only the authentication/sealing). But at that time the preference/conclusion was to keep it combined in a single instruction.
What's the concern with requiring "DIEL" only for the authentication? DIEL is probably a too strong requirement for ace.import, can't we formulate it as "implementation should ensure not to leak sensitive info via timing or other side-channel" (which in general should hold for all ACE, given the HAC goals).

[lfiolhais]

So are you proposing to split the load and authenticate parts?

I'm not proposing to split the instruction. I'm merely stating that this is a weird case, and we should discuss it.

What's the concern with requiring "DIEL" only for the authentication?

The issue is that we have an instruction where DIEL is only partially required. All instructions that currently support DIEL apply the semantics to all operations within the instruction. By enforcing DIEL in only one part of the instruction, we are breaking the architectural guarantee.

DIEL is probably a too strong requirement for ace.import, can't we formulate it as "implementation should ensure not to leak sensitive info via timing or other side-channel" (which in general should hold for all ACE, given the HAC goals).

Ironically enough, what you wrote is even stronger than DIEL. By stating "... timing or other side-channel" you are implicitly stating that side-channel guarantees go beyond execution latency.

[mocenigo]

The cryptographic parts of ace.import and ace.export all run in constant time if the implementation of AES does, and has no data dependent timings. DIEL is data-independent execution latency, and I interpret this as that any latency variation is NOT dependent on the data values. So this is a requirement that can easily be satisfied — without having to split the operations.

[mocenigo]

So are you proposing to split the load and authenticate parts?

I'm not proposing to split the instruction. I'm merely stating that this is a weird case, and we should discuss it.

What's the concern with requiring "DIEL" only for the authentication?

The issue is that we have an instruction where DIEL is only partially required. All instructions that currently support DIEL apply the semantics to all operations within the instruction. By enforcing DIEL in only one part of the instruction, we are breaking the architectural guarantee.

DIEL does not mean constant, it means Data Independent. Timing variations caused by the memory subsystem are usually data independent... unless the data is cached, that is, in which case importing the same blob twice may have a timing variation between the first and second time, and therefore importing an already used SCC will take a shorter time than importing a new one.

I do not think anything can be done in this case except mandating the SCCs to always be flushed and cleared form the caches at each write, which would be bad (in my opinion). This is an issue of patterns of data reuse, and something I do not think that can be solved at the architecture level: such "cache attacks" should then be solved by the SW itself using typical countermeasures against them.

DIEL is probably a too strong requirement for ace.import, can't we formulate it as "implementation should ensure not to leak sensitive info via timing or other side-channel" (which in general should hold for all ACE, given the HAC goals).

Ironically enough, what you wrote is even stronger than DIEL. By stating "... timing or other side-channel" you are implicitly stating that side-channel guarantees go beyond execution latency.

I added "which in general should hold for all ACE" because since we support both side-channel unprotected and protected operations, we cannot expect to have two different import/export mechanisms for them... We could, for instance by using the side-channel-unprotected version of AES when exporting contexts of side-channel-unprotected algorithms, and using the side-channel-protected version when exporting contexts of side-channel-unprotected algorithms. Actually, we should.

Anyway, I could write just "implementation should ensure not to leak sensitive info via timing"

Returning to DIEL, I will think about the best way to phrase it.