linux-kernel - Re: ARM: static kernel in vmalloc space

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]

Message-ID: <CAK8P3a2PNZY-9L9+SFDLtrp731ZGo6Nbs-7jY6E2PwWXa0kfKw@mail.gmail.com>
Date:   Thu, 14 May 2020 14:41:11 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     afzal mohammed <afzal.mohd.ma@...il.com>
Cc:     Russell King <linux@...linux.org.uk>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: ARM: static kernel in vmalloc space

On Thu, May 14, 2020 at 1:18 PM afzal mohammed <afzal.mohd.ma@...il.com> wrote:
> On Tue, May 12, 2020 at 09:49:59PM +0200, Arnd Bergmann wrote:
>
> > Any idea which bit you want to try next?
>
> My plan has been to next post patches for the static kernel migration
> to vmalloc space (currently the code is rigid, taking easy route
> wherever possible & not of high quality) as that feature has an
> independent existence & adds value by itself.  And then start working
> on other steps towards VMSPLIT_4G_4G.
>
> Now that you mentioned about other things, i will slowly start those
> as well.

Sounds good.

> > Creating a raw_copy_{from,to}_user()
> > based on get_user_pages()/kmap_atomic()/memcpy() is probably a good
> > next thing to do. I think it can be done one page at a time with only
> > checking for
> > get_fs(), access_ok(), and page permissions, while get_user()/put_user()
> > need to handle a few more corner cases.
>
> Before starting w/ other things, i would like to align on the high
> level design,
>
> My understanding (mostly based on your comments) as follows,
> (i currently do not have a firm grip over these things, hope to have
> it once started w/ the implementation)
>
> 1. SoC w/ LPAE
> 2. TTBR1 (top 256MB) for static kernel, modules, io mappings, vmalloc,
>         kmap, fixmap & vectors

Right, these kind of go together because pre-LPAE cannot do the
same TTBR1 split, and they more frequently have conflicting
static mappings.

It's clearly possible to do something very similar for older chips
(v6 or v7 without LPAE, possibly even v5), it just gets harder
while providing less benefit.

> 3. TTBR0 (low 3768MB) for user space & lowmem (kernel lowmem to have
>         separate ASID)

Right. This could in theory become a boot-time decision, using
a larger TTBR1 on machines that want more vmalloc space, but a
hardcoded 3840/256 split is likely the best compromise of all the
constraints.

> 4. for user space to/from copy
>  a. pin user pages
>  b. kmap user page (can't corresponding lowmem be used instead ?)
>  c. copy

Right, this is probably the simplest and most generic implementation,
it can even be in an architecture-independent lib/uaccess-generic
file.

These are the trade-offs I see:

- we can have optimizations for get_user/put_user or small copy_from_user
  based on ttbr0 switching, but large copies should probably use the pinned
  page approach anyway, and it's easier to only have one method to
  start with, and then measure the overhead before starting to optimize.

- In the long run, there is no need for kmap()/kmap_atomic() after
  highmem gets removed from the kernel, but for the next few years
  we should still assume that highmem can be used, in order to support
  systems like the 8GB highbank, armadaxp, keystone2 or virtual
  machines. For lowmem pages (i.e. all pages when highmem is
  disabled), kmap_atomic() falls back to page_address() anyway,
  so there is no much overhead.

      Arnd