Date
1 - 11 of 11
rv(64) address space size
the current size of the virtual address space is 48 bits. (per the june 2019 spec - volume II)
as many of you know, INTEL has increased their address space to 57 bits. several designers of server and hpc class of riscv systems have asked me about this.
so, what is the current view on this. will riscv support the a 57 bit logical address space.
with the newer class of NVM being implemented, many systems are looking at directly addressing, cluster-wide ALL of physlcal memory
as many of you know, INTEL has increased their address space to 57 bits. several designers of server and hpc class of riscv systems have asked me about this.
so, what is the current view on this. will riscv support the a 57 bit logical address space.
with the newer class of NVM being implemented, many systems are looking at directly addressing, cluster-wide ALL of physlcal memory
The basic design is already laid out for expansion to Sv57 and Sv64 following the template of fewer bits,
toggle quoted message
Show quoted text
Krste
On Nov 25, 2020, at 1:15 PM, swallach <steven.wallach@...> wrote:the current size of the virtual address space is 48 bits. (per the june 2019 spec - volume II)
as many of you know, INTEL has increased their address space to 57 bits. several designers of server and hpc class of riscv systems have asked me about this.
so, what is the current view on this. will riscv support the a 57 bit logical address space.
with the newer class of NVM being implemented, many systems are looking at directly addressing, cluster-wide ALL of physlcal memory
is this documented?
much appreciated
On Nov 25, 2020, at 5:10 PM, Krste Asanovic <krste@...> wrote:
The basic design is already laid out for expansion to Sv57 and Sv64 following the template of fewer bits,KrsteOn Nov 25, 2020, at 1:15 PM, swallach <steven.wallach@...> wrote:the current size of the virtual address space is 48 bits. (per the june 2019 spec - volume II)
as many of you know, INTEL has increased their address space to 57 bits. several designers of server and hpc class of riscv systems have asked me about this.
so, what is the current view on this. will riscv support the a 57 bit logical address space.
with the newer class of NVM being implemented, many systems are looking at directly addressing, cluster-wide ALL of physlcal memory
WARNING / LEGAL TEXT: This message is intended only for the use of the individual or entity to which it is addressed and may contain information which is privileged, confidential, proprietary, or exempt from disclosure under applicable law. If you are not the intended recipient or the person responsible for delivering the message to the intended recipient, you are strictly prohibited from disclosing, distributing, copying, or in any way using this message. If you have received this communication in error, please notify the sender and destroy and delete any copies you may have received.
http://www.bsc.es/disclaimer
andrew@...
It hasn’t been standardized yet, but there is a placeholder for the Sv57 encoding in the satp.MODE register field. There isn’t a chapter on the Sv57 spec, but it will follow the pattern of Sv39 -> Sv48, with one additional page-table level.
I will suggest to the virtual memory task group that we include Sv57 in the next batch of things we put up for ratification.
On Wed, Nov 25, 2020 at 2:15 PM swallach <steven.wallach@...> wrote:
is this documented?much appreciatedOn Nov 25, 2020, at 5:10 PM, Krste Asanovic <krste@...> wrote:The basic design is already laid out for expansion to Sv57 and Sv64 following the template of fewer bits,KrsteOn Nov 25, 2020, at 1:15 PM, swallach <steven.wallach@...> wrote:the current size of the virtual address space is 48 bits. (per the june 2019 spec - volume II)
as many of you know, INTEL has increased their address space to 57 bits. several designers of server and hpc class of riscv systems have asked me about this.
so, what is the current view on this. will riscv support the a 57 bit logical address space.
with the newer class of NVM being implemented, many systems are looking at directly addressing, cluster-wide ALL of physlcal memory
WARNING / LEGAL TEXT: This message is intended only for the use of the
individual or entity to which it is addressed and may contain
information which is privileged, confidential, proprietary, or exempt
from disclosure under applicable law. If you are not the intended
recipient or the person responsible for delivering the message to the
intended recipient, you are strictly prohibited from disclosing,
distributing, copying, or in any way using this message. If you have
received this communication in error, please notify the sender and
destroy and delete any copies you may have received.
http://www.bsc.es/disclaimer
this is a good start
imho, perhaps not not for sv57, but for sv64, we incorporate some of the suggestions
of the KASLR people. there are linux versions that implement their suggestions. perhaps only for sv64.
but thus should be up to discussion
It hasn’t been standardized yet, but there is a placeholder for the Sv57 encoding in the satp.MODE register field. There isn’t a chapter on the Sv57 spec, but it will follow the pattern of Sv39 -> Sv48, with one additional page-table level.
I will suggest to the virtual memory task group that we include Sv57 in the next batch of things we put up for ratification.
On Wed, Nov 25, 2020 at 2:15 PM swallach <steven.wallach@...> wrote:
is this documented?much appreciated
WARNING / LEGAL TEXT: This message is intended only for the use of the individual or entity to which it is addressed and may contain information which is privileged, confidential, proprietary, or exempt from disclosure under applicable law. If you are not the intended recipient or the person responsible for delivering the message to the intended recipient, you are strictly prohibited from disclosing, distributing, copying, or in any way using this message. If you have received this communication in error, please notify the sender and destroy and delete any copies you may have received.
http://www.bsc.es/disclaimer
Jonathan Behrens <behrensj@...>
imho, perhaps not not for sv57, but for sv64, we incorporate some of the suggestionsof the KASLR people. there are linux versions that implement their suggestions. perhaps only for sv64.
Could you clarify what suggestions you think we should implement? The KAISER paper describes a way of mitigating side channel attacks, but do you have specific lessons you think we should learn from it for designing sv64?
Jonathan
this is a good startimho, perhaps not not for sv57, but for sv64, we incorporate some of the suggestionsof the KASLR people. there are linux versions that implement their suggestions. perhaps only for sv64.but thus should be up to discussionIt hasn’t been standardized yet, but there is a placeholder for the Sv57 encoding in the satp.MODE register field. There isn’t a chapter on the Sv57 spec, but it will follow the pattern of Sv39 -> Sv48, with one additional page-table level.I will suggest to the virtual memory task group that we include Sv57 in the next batch of things we put up for ratification.On Wed, Nov 25, 2020 at 2:15 PM swallach <steven.wallach@...> wrote:is this documented?much appreciated
WARNING / LEGAL TEXT: This message is intended only for the use of the individual or entity to which it is addressed and may contain information which is privileged, confidential, proprietary, or exempt from disclosure under applicable law. If you are not the intended recipient or the person responsible for delivering the message to the intended recipient, you are strictly prohibited from disclosing, distributing, copying, or in any way using this message. If you have received this communication in error, please notify the sender and destroy and delete any copies you may have received.
http://www.bsc.es/disclaimer
this would take some time. but to begin
WARNING / LEGAL TEXT: This message is intended only for the use of the individual or entity to which it is addressed and may contain information which is privileged, confidential, proprietary, or exempt from disclosure under applicable law. If you are not the intended recipient or the person responsible for delivering the message to the intended recipient, you are strictly prohibited from disclosing, distributing, copying, or in any way using this message. If you have received this communication in error, please notify the sender and destroy and delete any copies you may have received.
http://www.bsc.es/disclaimer
separating kernel from user, provides both the first level of isolation. this can be further used for
.hypervisor isolation
trojan horse pointers protection
etc
i attached one snapshot from the kalsr paper and also mark hills presentation on spectre and meltdown
KALSR does NOT solver the world’s security problems. it is only the beginning.
and within the context if rv64 (maybe rv47) this helps, aand their suggestions maybe more adoptable within the current definitional framework
if you have questions on the paper, for particular issues, please post them
--------------------------------------------------
imho, perhaps not not for sv57, but for sv64, we incorporate some of the suggestionsof the KASLR people. there are linux versions that implement their suggestions. perhaps only for sv64.
Could you clarify what suggestions you think we should implement? The KAISER paper describes a way of mitigating side channel attacks, but do you have specific lessons you think we should learn from it for designing sv64?
WARNING / LEGAL TEXT: This message is intended only for the use of the individual or entity to which it is addressed and may contain information which is privileged, confidential, proprietary, or exempt from disclosure under applicable law. If you are not the intended recipient or the person responsible for delivering the message to the intended recipient, you are strictly prohibited from disclosing, distributing, copying, or in any way using this message. If you have received this communication in error, please notify the sender and destroy and delete any copies you may have received.
http://www.bsc.es/disclaimer
—————
Jonathan Behrens <behrensj@...>
RISC-V can already support KAISER now so I'm not sure why rv64 would need anything special for it?
As a side note, that paper seriously understates the costs of KAISER. On other workloads it can be 2-3 orders of magnitude higher overhead (which is why Linux only enables it on processors that are vulnerable to Meltdown).
Jonathan
this would take some time. but to beginseparating kernel from user, provides both the first level of isolation. this can be further used for.hypervisor isolationtrojan horse pointers protectionetci attached one snapshot from the kalsr paper and also mark hills presentation on spectre and meltdownKALSR does NOT solver the world’s security problems. it is only the beginning.and within the context if rv64 (maybe rv47) this helps, aand their suggestions maybe more adoptable within the current definitional frameworkif you have questions on the paper, for particular issues, please post them--------------------------------------------------imho, perhaps not not for sv57, but for sv64, we incorporate some of the suggestionsof the KASLR people. there are linux versions that implement their suggestions. perhaps only for sv64.Could you clarify what suggestions you think we should implement? The KAISER paper describes a way of mitigating side channel attacks, but do you have specific lessons you think we should learn from it for designing sv64?
WARNING / LEGAL TEXT: This message is intended only for the use of the individual or entity to which it is addressed and may contain information which is privileged, confidential, proprietary, or exempt from disclosure under applicable law. If you are not the intended recipient or the person responsible for delivering the message to the intended recipient, you are strictly prohibited from disclosing, distributing, copying, or in any way using this message. If you have received this communication in error, please notify the sender and destroy and delete any copies you may have received.
http://www.bsc.es/disclaimer—————
attached at my comments.
like everything else, performance is always a function of the implementation. same ISA, different implementation, different performance.
there are several themes to this thread.
1. do nothing for rv57 (keep INTEL)
2. add a some trivial stuff to rv57 (va translation) - NOTE the comment on what ARM has done
3. do something better for rv64 (currently intel has no rv64)
clearly the application space needs to be considered to answer the above themes.
having done this too many times, my philosophy is to make a system call as efficient as a subroutine call/return. and make pointer dereferencing as secure as we can make it.
Trojan Horse Pointers are EVIL.
have a happy and safe thanksgiving
http://bsc.es/disclaimer
like everything else, performance is always a function of the implementation. same ISA, different implementation, different performance.
there are several themes to this thread.
1. do nothing for rv57 (keep INTEL)
2. add a some trivial stuff to rv57 (va translation) - NOTE the comment on what ARM has done
3. do something better for rv64 (currently intel has no rv64)
clearly the application space needs to be considered to answer the above themes.
having done this too many times, my philosophy is to make a system call as efficient as a subroutine call/return. and make pointer dereferencing as secure as we can make it.
Trojan Horse Pointers are EVIL.
have a happy and safe thanksgiving
http://bsc.es/disclaimer
mick@...
Hello Steven,
Στις 2020-11-26 18:04, swallach έγραψε:
KAISER/KPTI is a software mitigation for leakages initially related to KASLR (another software mitigation) and later on to kernel memory's contents (Meltdown). It was merged upstream when Meltdown was discovered, and as Jonathan mentioned the performance penalty can get much worse than 0.28% (some benchmarks here -> http://www.brendangregg.com/blog/2018-02-09/kpti-kaiser-meltdown-performance.html) which is why it remains an optional feature, and even when enabled in the kernel it's only activated for CPUS vulnerable to Meltdown (check out X86_BUG_CPU_INSECURE).
A bit off-topic: have in mind there is an on-going discussion on the TEE TG about a Supervisor-level PMP mechanism which can further isolate the kernel memory from the user even when no MMU is available.
Regards,
Nick
Στις 2020-11-26 18:04, swallach έγραψε:
attached at my comments.I'm trying to understand from your comments what ISA-related changes do you propose for Sv57/Sv64 other than the address space extension, the only comment I got is the TTBR0/1 split on ARM/ARM64. Also I don't see why Sv57/Sv64 should be treated differently security-wise, could you please clarify ?
like everything else, performance is always a function of the
implementation. same ISA, different implementation, different
performance.
there are several themes to this thread.
1. do nothing for rv57 (keep INTEL)
2. add a some trivial stuff to rv57 (va translation) - NOTE the
comment on what ARM has done
3. do something better for rv64 (currently intel has no rv64)
KAISER/KPTI is a software mitigation for leakages initially related to KASLR (another software mitigation) and later on to kernel memory's contents (Meltdown). It was merged upstream when Meltdown was discovered, and as Jonathan mentioned the performance penalty can get much worse than 0.28% (some benchmarks here -> http://www.brendangregg.com/blog/2018-02-09/kpti-kaiser-meltdown-performance.html) which is why it remains an optional feature, and even when enabled in the kernel it's only activated for CPUS vulnerable to Meltdown (check out X86_BUG_CPU_INSECURE).
A bit off-topic: have in mind there is an on-going discussion on the TEE TG about a Supervisor-level PMP mechanism which can further isolate the kernel memory from the user even when no MMU is available.
Regards,
Nick
thank you for your comment
1. for now, i am only proposing the addition of the ARM extensions to sv57. the reason being that current linux, for ARM, can function with this extension
2. for sv64, i would propose a more thorough, both analysis and extension, for security. it is unclear to me how this would function within the riscv privileged working group.
3. i am NOT adverse to adding other security extensions to sv57. i just want to make sure the ARM extension is specified
i hope this clarifies my views
----------------
WARNING / LEGAL TEXT: This message is intended only for the use of the individual or entity to which it is addressed and may contain information which is privileged, confidential, proprietary, or exempt from disclosure under applicable law. If you are not the intended recipient or the person responsible for delivering the message to the intended recipient, you are strictly prohibited from disclosing, distributing, copying, or in any way using this message. If you have received this communication in error, please notify the sender and destroy and delete any copies you may have received.
http://www.bsc.es/disclaimer