linux-kernel - Re: [PATCH] riscv: kbuild: add virtual memory system selection

Open Source and information security mailing list archives

Date:   Wed, 7 Aug 2019 09:04:40 +0200
From:   Alexandre Ghiti <alex@...ti.fr>
To:     Christoph Hellwig <hch@...radead.org>,
        Paul Walmsley <paul.walmsley@...ive.com>
Cc:     linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] riscv: kbuild: add virtual memory system selection

On 8/7/19 7:42 AM, Christoph Hellwig wrote:
> On Tue, Aug 06, 2019 at 05:02:03PM -0700, Paul Walmsley wrote:
>> The rationale is to encourage others to start laying the groundwork for
>> future Sv48 support.  The immediate trigger for it was Alex's mmap
>> randomization support patch series, which needs to set some Kconfig
>> options differently depending on the selection of Sv32/39/48.
> Writing a formal todo list is much better encouragement than adding
> dead code.  Th latter has a tendency of lingering around forever and
> actually hurting people.
>
>>> but actively harmful, which is even worse.
>> Reflecting on this assertion, the only case that I could come up with is
>> that randconfig or allyesconfig build testing could fail.  Is this the
>> case that you're thinking of, or is there a different one?  If that's the
>> one, I do agree that it would be best to avoid this case, and it looks
>> like there's no obvious way to work around that issue.
> randconfig or just a user thinking bigger is better and picking it.
>
>>> Even if we assume we want to implement Sv48 eventually (which seems
>>> to be a bit off), we need to make this a runtime choice and not a
>>> compile time one to not balloon the number of configs that distributions
>>> (and kernel developers) need to support.
>> The expectation is that kernels that support multiple virtual memory
>> system modes at runtime will probably incur either a performance or a
>> memory layout penalty for doing so.  So performance-sensitive embedded
>> applications will select only the model that they use, while distribution
>> kernels will likely take the performance hit for broader single-kernel
>> support.
> Even if we want to support Sv39 only or Sv39+Sv39 the choice in the
> patch doesn't make any sense.  So better do the whole thing when its
> ready than doing false "groundwork".

I took a look at how x86 deals with 5-level page table: it allows to handle
5-level and 4-level at runtime by folding the last page table level (cf
Documentation/x86/x86_64/5level-paging.rst). So we might want to be able to
do the same and deal with that at runtime.

Regarding my series about mmap, x86 does not care about the width of the
the address space and sets values of ARCH_MMAP_RND_BITS_MIN/MAX based
on 32bit or 64bit (but then does not respect the magic formula as in arm64).

And FYI my series and your patch are already in linux-next.

Thanks,

Alex

> _______________________________________________
> linux-riscv mailing list
> linux-riscv@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

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