1. Tech-Privileged
  2. Topics

rv(64) address space size

swallach
 

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




----------------

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 ?


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

mick@...
 

Hello Steven,

Στις 2020-11-26 18:04, swallach έγραψε:
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)
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 ?

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
swallach
 

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

comments_linux_kernel_address_Spaces_kaiser.pdf

comments_linux_kernel_address_Spaces_kaiser.pdf

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


On Wed, Nov 25, 2020 at 6:52 PM swallach via lists.riscv.org <steven.wallach=bsc.es@...> wrote:
this would take some time.  but to begin

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 suggestions
  of 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



—————
swallach
 

this would take some time.  but to begin

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 suggestions
  of 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



—————


hill_mark_wisconsin_meltdown_spectre.pptx

hill_mark_wisconsin_meltdown_spectre.pptx
isolation.pdf

isolation.pdf

Jonathan Behrens <behrensj@...>
 

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.

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

On Wed, Nov 25, 2020 at 5:31 PM swallach via lists.riscv.org <steven.wallach=bsc.es@...> wrote:
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


swallach
 

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


linux_kernel_address_Spaces_kaiser.pdf

linux_kernel_address_Spaces_kaiser.pdf

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 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,
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
















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
swallach
 

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,
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



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

Krste Asanovic
 

The basic design is already laid out for expansion to Sv57 and Sv64 following the template of fewer bits,
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

swallach
 

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

1 - 11 of 11