linux-kernel - Re: remove set

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:   Sat, 5 Sep 2020 14:17:16 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Christoph Hellwig <hch@....de>
Cc:     Paul Walmsley <paul.walmsley@...ive.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        linux-riscv <linux-riscv@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        linux-arch <linux-arch@...r.kernel.org>
Subject: Re: remove set_fs for riscv

On Sat, Sep 5, 2020 at 9:17 AM Christoph Hellwig <hch@....de> wrote:
>
> On Fri, Sep 04, 2020 at 08:15:03PM +0200, Arnd Bergmann wrote:
> > Is there a bigger plan for the rest? I can probably have a look at the Arm
> > OABI code if nobody else working on that yet.
>
> m68knommu seems mostly trivial and not interact much with m68k/mmu,
> so that woud be my next target.  All the other seems to share more
> code for the mmu and nommu case, so they'd have to be done per arch.

Ok.

> arm would be my first target because it is used widespread, and its
> current set_fs implemenetation is very strange.  But given thar you
> help maintaining arm SOCs and probably know the arch code much better
> than I do I'd be more than happy to leave that to you.

I would start with the syscall wrapper code that just needs a simple
set of changes to pass the arguments on as kernel pointers instead
of fake user pointers.

I'm also not too familiar with the domain handling on older Arm cores,
which I think is the main difference to other architectures. On modern
Armv6+, the set_fs() call is just an assignment to current_thread_info()->
addr_limit like on other architectures, whereas Armv5 and older
rely on special load/store instructions to perform get_user/put_user
as an unprivileged access. Removing set_fs() should allow to clean
that up nicely, but I'd worry about introducing regressions in the
process, and will probably stop short of that cleanup.

     Arnd