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:   Mon, 7 Sep 2020 16:58:57 +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>,
        Russell King <rmk@....linux.org.uk>
Subject: Re: remove set_fs for riscv

On Mon, Sep 7, 2020 at 8:03 AM Christoph Hellwig <hch@....de> wrote:
>
> On Mon, Sep 07, 2020 at 12:14:59AM +0200, Arnd Bergmann wrote:
> > I've had a first pass at this now, see
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git/log/?h=arm-kill-set_fs
> >
> > There are a couple of things in there that ended up uglier than I was
> > hoping for, and it's completely untested beyond compilation. Is this
> > roughly what you had in mind? I can do some testing then and post
> > it to the Arm mailing list.
>
> Looks sensible.  The OABI hacks a are a little ugly, but so would be
> every other alternative.

Ok, thanks for taking a look. I've now managed to run the patched
kernel with OABI user space and tested the modified syscalls with
LTP. The 0-day bot found a regression that I have fixed.

I'll send out the series for review next.

> Note that you don't need to add a TASK_SIZE_MAX definition to arm if you
> base it on my series as that provides a default one.

I've rebased on that patch now and taken out those definitions.

> I also think with these changes arm/nommu should be able to use
> UACCESS_MEMCPY.

Probably yes, but I'd leave the current version for now. The Arm
implementation already supports combinations of range check
and domain settings, with the NOMMU targets using neither, but
sharing the same implementation as the others.

      Arnd