linux-kernel - Re: [RFC PATCH 00/12] Introduce sv48 support without relocable kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 02 Feb 2021 19:04:45 -0800 (PST)
From:   Palmer Dabbelt <palmer@...belt.com>
To:     alex@...ti.fr
CC:     Paul Walmsley <paul.walmsley@...ive.com>, zong.li@...ive.com,
        anup@...infault.org, Christoph Hellwig <hch@....de>,
        ardb@...nel.org, Arnd Bergmann <arnd@...db.de>,
        linux-efi@...r.kernel.org, linux-arch@...r.kernel.org,
        linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject:     Re: [RFC PATCH 00/12] Introduce sv48 support without relocable kernel

On Sat, 30 Jan 2021 01:33:20 PST (-0800), alex@...ti.fr wrote:
> Hi Palmer,
>
> On 1/4/21 2:58 PM, Alexandre Ghiti wrote:
>> This patchset, contrary to the previous versions, allows to have a single
>> kernel for sv39 and sv48 without being relocatable.
>>
>> The idea comes from Arnd Bergmann who suggested to do the same as x86,
>> that is mapping the kernel to the end of the address space, which allows
>> the kernel to be linked at the same address for both sv39 and sv48 and
>> then does not require to be relocated at runtime.
>>
>> This is an RFC because I need to at least rebase a few commits and add
>> documentation. The most interesting patches where I expect feedbacks are
>> 1/12, 2/12 and 8/12. Note that moving the kernel out of the linear
>> mapping and sv48 support can be separate patchsets, I share them together
>> today to show that it works (this patchset is rebased on top of v5.10).
>>
>> If we agree about the overall idea, I'll rebase my relocatable patchset
>> on top of that and then KASLR implementation from Zong will be greatly
>> simplified since moving the kernel out of the linear mapping will avoid
>> to copy the kernel physically.
>>
>> This implements sv48 support at runtime. The kernel will try to
>> boot with 4-level page table and will fallback to 3-level if the HW does not
>> support it. Folding the 4th level into a 3-level page table has almost no
>> cost at runtime.
>>
>> Finally, the user can now ask for sv39 explicitly by using the device-tree
>> which will reduce memory footprint and reduce the number of memory accesses
>> in case of TLB miss.
>>
>> Alexandre Ghiti (12):
>>    riscv: Move kernel mapping outside of linear mapping
>>    riscv: Protect the kernel linear mapping
>>    riscv: Get rid of compile time logic with MAX_EARLY_MAPPING_SIZE
>>    riscv: Allow to dynamically define VA_BITS
>>    riscv: Simplify MAXPHYSMEM config
>>    riscv: Prepare ptdump for vm layout dynamic addresses
>>    asm-generic: Prepare for riscv use of pud_alloc_one and pud_free
>>    riscv: Implement sv48 support
>>    riscv: Allow user to downgrade to sv39 when hw supports sv48
>>    riscv: Use pgtable_l4_enabled to output mmu type in cpuinfo
>>    riscv: Explicit comment about user virtual address space size
>>    riscv: Improve virtual kernel memory layout dump
>>
>>   arch/riscv/Kconfig                      |  34 +--
>>   arch/riscv/boot/loader.lds.S            |   3 +-
>>   arch/riscv/include/asm/csr.h            |   3 +-
>>   arch/riscv/include/asm/fixmap.h         |   3 +
>>   arch/riscv/include/asm/page.h           |  33 ++-
>>   arch/riscv/include/asm/pgalloc.h        |  40 +++
>>   arch/riscv/include/asm/pgtable-64.h     | 104 ++++++-
>>   arch/riscv/include/asm/pgtable.h        |  68 +++--
>>   arch/riscv/include/asm/sparsemem.h      |   6 +-
>>   arch/riscv/kernel/cpu.c                 |  23 +-
>>   arch/riscv/kernel/head.S                |   6 +-
>>   arch/riscv/kernel/module.c              |   4 +-
>>   arch/riscv/kernel/vmlinux.lds.S         |   3 +-
>>   arch/riscv/mm/context.c                 |   2 +-
>>   arch/riscv/mm/init.c                    | 376 ++++++++++++++++++++----
>>   arch/riscv/mm/physaddr.c                |   2 +-
>>   arch/riscv/mm/ptdump.c                  |  56 +++-
>>   drivers/firmware/efi/libstub/efi-stub.c |   2 +-
>>   include/asm-generic/pgalloc.h           |  24 +-
>>   include/linux/sizes.h                   |   3 +-
>>   20 files changed, 648 insertions(+), 147 deletions(-)
>>
>
> Any thought about the idea ? Is it going in the right direction ? I have
> fixed quite a few things since I posted this so don't bother giving this
> patchset a full review.

My only real issue was the relocation stuff, which appears to be fixed.  I 
haven't had the time to look at the patches, but it wouldn't hurt to send 
another revision.  The best bet might be to just wait until 5.11 and send on 
top of that, it's too late for this one anyway and that'll be a stable base to 
test from.