Unnecessary/Inappropriate documentation of kernel address space decisions

[riscv]

Unnecessary/Inappropriate documentation of kernel address space decisions

[aswaterman]

This was added to provide guidance to HW implementations for mitigating some kinds of speculation-based side-channel attacks: e.g., when in U-mode, don't speculatively refill the TLB for accesses to negative addresses.

[jrtc27]

This does not seem like the right way to "solve" that.

[kumarsankaran]

Hi Andrew, Does this need to be in the platform spec? Regards Kumar *From:* Jessica Clarke ***@***.***> *Sent:* Friday, April 30, 2021 8:10 PM *To:* riscv/riscv-platform-specs ***@***.***> *Cc:* Subscribed ***@***.***> *Subject:* Re: [riscv/riscv-platform-specs] Unnecessary/Inappropriate documentation of kernel address space decisions (#13) This does not seem like the right way to "solve" that. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#13 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABLRGVXYN43NX4EXWOQYNA3TLNWHBANCNFSM435SJGYA> .

[aswaterman]

Well, clearly I think it's a good idea to have it, and no one had complained about it for over 3 years...

[jscheid-ventana]

when in U-mode, don't speculatively refill the TLB for accesses to negative addresses.

Should it then be restated in this fashion?

[jrtc27]

What's wrong with just "when in U-mode, don't speculatively refill the TLB for accesses to pages without the U PTE bit"? Or are you concerned about timing attacks due to the side-effects of page-table walks too? If so that needs to be stated. But, this is really inflexible, it's effectively a heuristic for hardware to try not to leak timing information, it's not particularly robust, and is completely broken once you introduce the H extension. RISC-V's page table design is not split like Arm's, we shouldn't be trying to jam Arm's semantics into RISC-V's model. And whatever the solution is, it belongs in the ISA document, not a platform spec.

[aswaterman]

Yeah, getting to the point of being able to read the U bit is also part of the problem.

It arguably doesn't belong in the ISA spec, since it's not ISA-visible in the traditional sense.

[jrtc27]

Yeah, getting to the point of being able to read the U bit is also part of the problem.

It arguably doesn't belong in the ISA spec, since it's not ISA-visible in the traditional sense.

In the age of Spectre and Meltdown the ISA absolutely needs to be such that there are defences against these types of microarchitectural attacks. Other ISAs have speculation fences that are purely microarchitectural, for example, yet we have nothing.

[atishp04]

Closing this issue as platform spec doesn't contain this anymore.