Cache invalidation

[Oleksii Kurochko]

Hi everyone,

I would like to ask a clarification question about cache invalidation in RISC-V.

In the case where the OS switches from task A to task B, shouldn't the cache be invalidated before giving control to task B? Otherwise, my understanding is that task B might gain access to some of task A's data.

If my understanding correct that to do that a platform should have ZICBOM extension?

I also could find information if cache could be disabled in RISC-V doc. Does it mean that RISC-V doesn't allow to disable cache or it could be SoC-implementation specific?

Thanks in advance,
 Oleksii

[Andrew Waterman]

On Fri, Oct 11, 2024 at 10:33 AM Oleksii Kurochko <oleksii....@gmail.com> wrote:

Hi everyone,

I would like to ask a clarification question about cache invalidation in RISC-V.

In the case where the OS switches from task A to task B, shouldn't the cache be invalidated before giving control to task B? Otherwise, my understanding is that task B might gain access to some of task A's data.

The continued presence of A's data in the cache doesn't grant B access to that data, because the memory-protection scheme (virtual memory, PMP, etc.) will have been configured to grant B access only to memory that it should have access to.  Those protections are engaged regardless of whether B's memory accesses hit in the cache.

Not flushing caches between context switches does potentially open a timing side-channel (B can determine some information about which addresses A has accessed by measuring the timing of its own memory accesses).  In some contexts, this is considered benign; in others, a cache flush might be part of (but not the entirety of) the solution.

If my understanding correct that to do that a platform should have ZICBOM extension?

I also could find information if cache could be disabled in RISC-V doc. Does it mean that RISC-V doesn't allow to disable cache or it could be SoC-implementation specific?

Thanks in advance,
 Oleksii

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/6e2c4211-ba24-4ec0-807b-06497d6c81c3n%40groups.riscv.org.

[Oleksii Kurochko]

On Sat, Oct 12, 2024 at 1:09 AM Andrew Waterman <and...@sifive.com> wrote:

On Fri, Oct 11, 2024 at 10:33 AM Oleksii Kurochko <oleksii....@gmail.com> wrote:

Hi everyone,

I would like to ask a clarification question about cache invalidation in RISC-V.

In the case where the OS switches from task A to task B, shouldn't the cache be invalidated before giving control to task B? Otherwise, my understanding is that task B might gain access to some of task A's data.

The continued presence of A's data in the cache doesn't grant B access to that data, because the memory-protection scheme (virtual memory, PMP, etc.) will have been configured to grant B access only to memory that it should have access to.  Those protections are engaged regardless of whether B's memory accesses hit in the cache.

Not flushing caches between context switches does potentially open a timing side-channel (B can determine some information about which addresses A has accessed by measuring the timing of its own memory accesses).  In some contexts, this is considered benign; in others, a cache flush might be part of (but not the entirety of) the solution.

Thanks a lot for clarifying!

Best regards,

 Oleksii