linux-kernel - Re: [PATCH] prctl: Don't compile some of prctl functions when CRUI

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

Message-ID: <20190417165632.GC3040@uranus.lan>
Date:   Wed, 17 Apr 2019 19:56:32 +0300
From:   Cyrill Gorcunov <gorcunov@...il.com>
To:     Michal Koutný <mkoutny@...e.com>
Cc:     kbuild-all@...org, Michael Kerrisk <mtk.manpages@...il.com>,
        Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        Randy Dunlap <rdunlap@...radead.org>,
        kbuild test robot <lkp@...el.com>,
        Michal Hocko <mhocko@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Yang Shi <yang.shi@...ux.alibaba.com>,
        Andrew Morton <akpm@...uxfoundation.org>,
        Andrey Vagin <avagin@...nvz.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Pavel Emelyanov <xemul@...tuozzo.com>
Subject: Re: [PATCH] prctl: Don't compile some of prctl functions when CRUI

On Wed, Apr 17, 2019 at 04:44:54PM +0200, Michal Koutný wrote:
> On Wed, Apr 17, 2019 at 03:38:41PM +0300, Cyrill Gorcunov <gorcunov@...il.com> wrote:
> > I've a bit vague memory what we've ended up with, but iirc there was
> > a problem with brk() syscall or similar. Then I think we left everything
> > as is.
> Was this related to the removal of non PR_SET_MM_MAP operations too?
> Do you have any pointers to the topic?

Here some details: suprisingly there are already users of PR_SET_MM_x
operands, so we can't deprecate it (https://lkml.org/lkml/2018/5/6/127).
And then there was an attempt to change locks https://lore.kernel.org/patchwork/patch/
but since we're modifying mm-> entries we should gurd them against
simultaneous sys_brk call. Or I misunderstood you and you meant somthing
different?