linux-kernel - Re: [PATCH 0/3] Highmem support for 32-bit RISC-V

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] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 8 Apr 2020 11:51:18 +0800
From:   Alan Kao <alankao@...estech.com>
To:     Arnd Bergmann <arnd@...db.de>
CC:     Eric Lin <tesheng@...estech.com>, Borislav Petkov <bp@...e.de>,
        Albert Ou <aou@...s.berkeley.edu>,
        Thomas Gleixner <tglx@...utronix.de>, <zong.li@...ive.com>,
        <alex@...ti.fr>,
        David Abdurachmanov <david.abdurachmanov@...il.com>,
        Anup Patel <Anup.Patel@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Steven Price <steven.price@....com>, <atish.patra@....com>,
        <yash.shah@...ive.com>, "Palmer Dabbelt" <palmer@...belt.com>,
        Greentime Hu <green.hu@...il.com>, Gary Guo <gary@...yguo.net>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        <linux-riscv@...ts.infradead.org>,
        Mike Rapoport <rppt@...ux.ibm.com>,
        "Logan Gunthorpe" <logang@...tatee.com>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 0/3] Highmem support for 32-bit RISC-V

On Thu, Apr 02, 2020 at 11:31:37AM +0200, Arnd Bergmann wrote:
> On Tue, Mar 31, 2020 at 11:34 AM Eric Lin <tesheng@...estech.com> wrote:
> >
> > With Highmem support, the kernel can map more than 1GB physical memory.
> >
> > This patchset implements Highmem for RV32, referencing to mostly nds32
> > and others like arm and mips, and it has been tested on Andes A25MP platform.
> 
> I would much prefer to not see highmem added to new architectures at all
> if possible, see https://lwn.net/Articles/813201/ for some background.
> 

Understood.

> For the arm32 architecture, we are thinking about implementing a
> VMPLIT_4G_4G option to replace highmem in the long run. The most
> likely way this would turn out at the moment looks like:
> 

Thanks for sharing the status from ARM32.  Is there any available branch
already?  It would be good to have a reference implementation.

> - have a 256MB region for vmalloc space at the top of the 4GB address
>   space, containing vmlinux, module, mmio mappings and vmalloc
>   allocations
> 
> - have 3.75GB starting at address zero for either user space or the
>   linear map.
> 
> - reserve one address space ID for kernel mappings to avoid tlb flushes
>   during normal context switches
> 
> - On any kernel entry, switch the page table to the one with the linear
>   mapping, and back to the user page table before returning to user space
>

After some survey I found previous disccusion
(https://lkml.org/lkml/2019/4/24/2110). The 5.2-based patch ended up not
being merged.  But at least we will have something to start if we want to.

Also interestingly, there was a PR for privileged spec that separates
addressing modes (https://github.com/riscv/riscv-isa-manual/pull/128) as
Sdas extension, but there was no progress afterwards.

Not very related to this thread, but there were some discussion about
ASID design in RISC-V (https://github.com/riscv/riscv-isa-manual/issues/348).
It is now in ratified 1.11 privileged spec.

> - add a generic copy_from_user/copy_to_user implementation based
>   on get_user_pages() in asm-generic/uaccess.h, using memcpy()
>   to copy from/to the page in the linear map.
> 
> - possible have architectures override get_user/put_user to use a
>   cheaper access based on a page table switch to read individual
>   words if that is cheaper than get_user_pages().
> 
> There was an implementation of this for x86 a long time ago, but
> it never got merged, mainly because there were no ASIDs on x86
> at the time and the TLB flushing during context switch were really
> expensive. As far as I can tell, all of the modern embedded cores
> do have ASIDs, and unlike x86, most do not support more than 4GB
> of physical RAM, so this scheme can work to replace highmem
> in most of the remaining cases, and provide additional benefits
> (larger user address range, higher separate of kernel/user addresses)
> at a relatively small performance cost.
> 
>        Arnd
> 

It seems to me that VMSPLIT_4G_4G is quite different from other VMSPLITs,
because it requires much more changes.

Thanks for showing the stance of kernel community against HIGHMEM support.
The cited discussion thread is comprehensive and clear.  Despite that RV32
users cannot get upstream support for their large memory, mechnisms like
VMSPLIT_4G_4G seems to be a promising way to go.  That being said, to
support the theoretical 16G physical memory, eventually kmap* will still
be needed.

Alan