From: Palmer Dabbelt <palmer@rivosinc.com>
To: jrtc27@jrtc27.com
Cc: charlie@rivosinc.com, alexghiti@rivosinc.com,
Atish Patra <atishp@rivosinc.com>,
Conor Dooley <conor@kernel.org>,
Paul Walmsley <paul.walmsley@sifive.com>,
aou@eecs.berkeley.edu, Bjorn Topel <bjorn@rivosinc.com>,
anup@brainfault.org, Evan Green <evan@rivosinc.com>,
linux-riscv@lists.infradead.org, konstantin@linuxfoundation.org,
linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [PATCH 1/2] RISC-V: mm: Restrict address space for sv39,sv48,sv57
Date: Tue, 27 Jun 2023 16:36:26 -0700 (PDT) [thread overview]
Message-ID: <mhng-7914c1d2-d671-4cc4-ba90-f85acb7c8b50@palmer-ri-x1c9> (raw)
In-Reply-To: <473F7474-D7AA-4C9F-95A3-320F1741EC50@jrtc27.com>
On Tue, 27 Jun 2023 15:32:36 PDT (-0700), jrtc27@jrtc27.com wrote:
> On 27 Jun 2023, at 23:21, Charlie Jenkins <charlie@rivosinc.com> wrote:
>>
>> Make sv39 the default address space for mmap as some applications
>> currently depend on this assumption.
>
> They are just plain wrong too. Sv48 was in even Priv v1.10 (the first
> spec where satp was named as such and contained the mode, rather than
> requiring M-mode’s help in configuring virtual memory), predating the
> ratified v1.11 spec. A 39-bit address space is pathetic and has
> implications for ASLR.
>
> I strongly suggest applications be forced to support at least Sv48,
> which is totally reasonable given the address space sizes used by other
> architectures. Sv57 is more disruptive to some runtimes, though ideally
> even that would be free for the kernel to use rather than committing to
> not using it for the default uABI.
Go and OpenJDK both broke when we expanded the VA width. I don't like
it either, but if the change breaks userspace then it's a regression and
we have to live with the bug.
> Jess
>
>> The RISC-V specification enforces
>> that bits outside of the virtual address range are not used, so
>> restricting the size of the default address space as such should be
>> temporary. A hint address passed to mmap will cause the largest address
>> space that fits entirely into the hint to be used. If the hint is less
>> than or equal to 1<<38, a 39-bit address will be used. After an address
>> space is completely full, the next smallest address space will be used.
>>
>> Signed-off-by: Charlie Jenkins <charlie@rivosinc.com>
>> ---
>> arch/riscv/include/asm/elf.h | 2 +-
>> arch/riscv/include/asm/pgtable.h | 13 +++++++++-
>> arch/riscv/include/asm/processor.h | 41 +++++++++++++++++++++++++-----
>> 3 files changed, 47 insertions(+), 9 deletions(-)
>>
>> diff --git a/arch/riscv/include/asm/elf.h b/arch/riscv/include/asm/elf.h
>> index 30e7d2455960..1b57f13a1afd 100644
>> --- a/arch/riscv/include/asm/elf.h
>> +++ b/arch/riscv/include/asm/elf.h
>> @@ -49,7 +49,7 @@ extern bool compat_elf_check_arch(Elf32_Ehdr *hdr);
>> * the loader. We need to make sure that it is out of the way of the program
>> * that it will "exec", and that there is sufficient room for the brk.
>> */
>> -#define ELF_ET_DYN_BASE ((TASK_SIZE / 3) * 2)
>> +#define ELF_ET_DYN_BASE ((DEFAULT_MAP_WINDOW / 3) * 2)
>>
>> #ifdef CONFIG_64BIT
>> #ifdef CONFIG_COMPAT
>> diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h
>> index 75970ee2bda2..e83912e97870 100644
>> --- a/arch/riscv/include/asm/pgtable.h
>> +++ b/arch/riscv/include/asm/pgtable.h
>> @@ -57,18 +57,29 @@
>> #define MODULES_END (PFN_ALIGN((unsigned long)&_start))
>> #endif
>>
>> +
>> /*
>> * Roughly size the vmemmap space to be large enough to fit enough
>> * struct pages to map half the virtual address space. Then
>> * position vmemmap directly below the VMALLOC region.
>> */
>> #ifdef CONFIG_64BIT
>> +#define VA_BITS_SV39 39
>> +#define VA_BITS_SV48 48
>> +#define VA_BITS_SV57 57
>> +
>> +#define VA_USER_SV39 (UL(1) << (VA_BITS_SV39 - 1))
>> +#define VA_USER_SV48 (UL(1) << (VA_BITS_SV48 - 1))
>> +#define VA_USER_SV57 (UL(1) << (VA_BITS_SV57 - 1))
>> +
>> #define VA_BITS (pgtable_l5_enabled ? \
>> - 57 : (pgtable_l4_enabled ? 48 : 39))
>> + VA_BITS_SV57 : (pgtable_l4_enabled ? VA_BITS_SV48 : VA_BITS_SV39))
>> #else
>> #define VA_BITS 32
>> #endif
>>
>> +#define DEFAULT_VA_BITS ((VA_BITS >= VA_BITS_SV39) ? VA_BITS_SV39 : VA_BITS)
>> +
>> #define VMEMMAP_SHIFT \
>> (VA_BITS - PAGE_SHIFT - 1 + STRUCT_PAGE_MAX_SHIFT)
>> #define VMEMMAP_SIZE BIT(VMEMMAP_SHIFT)
>> diff --git a/arch/riscv/include/asm/processor.h b/arch/riscv/include/asm/processor.h
>> index 6fb8bbec8459..019dcd4ecae4 100644
>> --- a/arch/riscv/include/asm/processor.h
>> +++ b/arch/riscv/include/asm/processor.h
>> @@ -12,20 +12,47 @@
>>
>> #include <asm/ptrace.h>
>>
>> -/*
>> - * This decides where the kernel will search for a free chunk of vm
>> - * space during mmap's.
>> - */
>> -#define TASK_UNMAPPED_BASE PAGE_ALIGN(TASK_SIZE / 3)
>> -
>> -#define STACK_TOP TASK_SIZE
>> #ifdef CONFIG_64BIT
>> +#define DEFAULT_MAP_WINDOW (UL(1) << (DEFAULT_VA_BITS - 1))
>> #define STACK_TOP_MAX TASK_SIZE_64
>> +
>> +#define arch_get_mmap_end(addr, len, flags) \
>> + ((addr) == 0 || (addr) >= VA_USER_SV57 ? STACK_TOP_MAX : \
>> + (((addr) >= VA_USER_SV48) && (VA_BITS >= VA_BITS_SV48)) ? \
>> + VA_USER_SV48 : \
>> + VA_USER_SV39)
>> +
>> +#define arch_get_mmap_base(addr, base) \
>> + (((addr >= VA_USER_SV57) && (VA_BITS >= VA_BITS_SV57)) ? \
>> + base + STACK_TOP_MAX - DEFAULT_MAP_WINDOW : \
>> + (((addr) >= VA_USER_SV48) && (VA_BITS >= VA_BITS_SV48)) ? \
>> + base + VA_USER_SV48 - DEFAULT_MAP_WINDOW : \
>> + base)
>> +
>> #else
>> +#define DEFAULT_MAP_WINDOW TASK_SIZE
>> #define STACK_TOP_MAX TASK_SIZE
>> +
>> +#define arch_get_mmap_end(addr, len, flags) \
>> + ((addr) > DEFAULT_MAP_WINDOW ? STACK_TOP_MAX : DEFAULT_MAP_WINDOW)
>> +
>> +#define arch_get_mmap_base(addr, base) \
>> + ((addr > DEFAULT_MAP_WINDOW) ? \
>> + base + STACK_TOP_MAX - DEFAULT_MAP_WINDOW : \
>> + base)
>> +
>> #endif
>> #define STACK_ALIGN 16
>>
>> +
>> +#define STACK_TOP DEFAULT_MAP_WINDOW
>> +
>> +/*
>> + * This decides where the kernel will search for a free chunk of vm
>> + * space during mmap's.
>> + */
>> +#define TASK_UNMAPPED_BASE PAGE_ALIGN(DEFAULT_MAP_WINDOW / 3)
>> +
>> #ifndef __ASSEMBLY__
>>
>> struct task_struct;
>> --
>> 2.34.1
>>
>>
>> _______________________________________________
>> linux-riscv mailing list
>> linux-riscv@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2023-06-27 23:36 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-27 22:21 [PATCH 0/2] Make SV39 the default address space Charlie Jenkins
2023-06-27 22:21 ` [PATCH 1/2] RISC-V: mm: Restrict address space for sv39,sv48,sv57 Charlie Jenkins
2023-06-27 22:32 ` Jessica Clarke
2023-06-27 23:36 ` Palmer Dabbelt [this message]
2023-06-28 7:44 ` Nick Kossifidis
2023-06-27 23:38 ` Charlie Jenkins
2023-06-28 12:34 ` Anup Patel
2023-06-29 1:38 ` Charlie Jenkins
2023-06-27 22:21 ` [PATCH 2/2] RISC-V: mm: Update documentation and include test Charlie Jenkins
2023-06-28 10:18 ` Muhammad Usama Anjum
-- strict thread matches above, loose matches on Subject: below --
2023-06-26 18:36 [PATCH 0/2] Restrict address space for sv39,sv48,sv57 Charlie Jenkins
2023-06-26 18:36 ` [PATCH 1/2] RISC-V: mm: " Charlie Jenkins
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=mhng-7914c1d2-d671-4cc4-ba90-f85acb7c8b50@palmer-ri-x1c9 \
--to=palmer@rivosinc.com \
--cc=alexghiti@rivosinc.com \
--cc=anup@brainfault.org \
--cc=aou@eecs.berkeley.edu \
--cc=atishp@rivosinc.com \
--cc=bjorn@rivosinc.com \
--cc=charlie@rivosinc.com \
--cc=conor@kernel.org \
--cc=evan@rivosinc.com \
--cc=jrtc27@jrtc27.com \
--cc=konstantin@linuxfoundation.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-riscv@lists.infradead.org \
--cc=paul.walmsley@sifive.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox