riscv / riscv-CMOs

https://jira.riscv.org/browse/RVG-59
Creative Commons Attribution 4.0 International
78 stars 12 forks source link

DCBA #5

Closed AndyGlew closed 2 years ago

AndyGlew commented 3 years ago

the current CMO proposal includes DCBZ/ZALLOC type CMOs, but not DCBA type

where DCBA = allocate a line in the cache WITHOUT getting it from memory - using whatever garbage was left in the physical cache line by whoever else was using it.

it is well-known that DCBA is a security hole.. Which is why ISAs eventually created DCBZ/ZALLOC.

However, DCBA lends itself to simpler implementations, and may be acceptable for some embedded systems.

the original CMO proposal did not provide DCBA thinking that everybody would object to the security hole. However, RISC-V is learning more and more that embedded systems are willing to take shortcuts.

DCBA should be restored to the proposal.

(Q: good DCBA always assume ownership?)

strikerdw commented 3 years ago

Should you have DCBA? good question.

We ran it out the the Power (server) architecture as fast as we could, but you will be building a number of appliances and microcontrollers, so you'll probably have no choice.

Also, while you don't get the lien out of memory, I think you do have to kill off any copies of the line that exist in other caches? Certainly if the memory is coherent. If it's not, God knows what you're doing... at all. It implementation dependent stew at that point, but if you're coherent, you have to kill the other copies or the machine can instantly go incoherent (assming you're taking the allocated line modified, which seems the sensible choice there and what the implementaitons as I recall did).

As stated in another issue, it would be good for the ISA to explicitly state that implementaitons are allowed to implement this as a DCBZ (ZERO ALLOCATE). That way it's clear you have to knock off the other caches and the data that appears in the allocated line is a "safe" value.

Derek

ingallsj commented 3 years ago

I discourage adding security holes to the general-purpose base ISA extension. As security is a growing consideration in the embedded space, I similarly discourage adding ISA-level security holes there either. If a specific vendor really wants DCBA, then I suggest they implement that as a custom instruction, which the RISC-V ISA is happy to allow, but this is not something we should provide to all.

billhuffman commented 3 years ago

Certainly if we define a DCBA, we should mention the security issue in the description and allow writing something like zeros to the lines without architecturally requiring it. But we'd probably do that.

Another alternative would be to have no architectural provision but recommend that non-blocking stores wait to see if entire line is written before requesting a block. That avoids some issues, requires nothing of programmers, and is easier to do with RVWMO than with stronger memory ordering. It does tend to add buffering, the more so if the bus does not allow data to be sent with the invalidation of other caches.

dkruckemyer-ventana commented 2 years ago

Closing due to lack of discussion.