search

riscvarchive / riscv-platform-specs

RISC-V Profiles and Platform Specification
Creative Commons Attribution 4.0 International
112 stars 39 forks source link

Unnecessary/Inappropriate documentation of kernel address space decisions #13

Closed jrtc27 closed 2 years ago

jrtc27 commented 3 years ago

Currently the supervisor spec says:

On RV64I-based Unix-class systems the negative virtual addresses are reserved for the kernel.

Why is this part of the platform spec? What addresses are used by the kernel and what addresses are used by userspace are entirely up to the kernel and not the concern of the platform, so unless I'm missing something it does not make sense to specify arbitrary implementation details.

aswaterman commented 3 years ago

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 commented 3 years ago

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

kumarsankaran commented 3 years ago

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 https://github.com/riscv/riscv-platform-specs/issues/13#issuecomment-830506501, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABLRGVXYN43NX4EXWOQYNA3TLNWHBANCNFSM435SJGYA .

aswaterman commented 3 years ago

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 commented 3 years ago

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

Should it then be restated in this fashion?

jrtc27 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 2 years ago

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