linux-kernel - Re: [PATCH] x86: Deprecate a.out support

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:   Tue, 5 Mar 2019 18:31:34 +0100
From:   Borislav Petkov <bp@...en8.de>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Alan Cox <gnomes@...rguk.ukuu.org.uk>,
        Matthew Wilcox <willy@...radead.org>,
        Jann Horn <jannh@...gle.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        Thomas Gleixner <tglx@...utronix.de>,
        kernel list <linux-kernel@...r.kernel.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        the arch/x86 maintainers <x86@...nel.org>,
        Linux API <linux-api@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Richard Weinberger <richard@....at>,
        Anton Ivanov <anton.ivanov@...bridgegreys.com>
Subject: Re: [PATCH] x86: Deprecate a.out support

On Tue, Mar 05, 2019 at 08:22:21AM -0800, Linus Torvalds wrote:
> Because I think all the known *bugs* we had were with the core dumping
> code, weren't they?

Well, I'm aware of only this one I fixed but who knows what else has
bitrotten out there through the years...

> Removing it looks trivial. Untested patch attached.
> 
> Then I'd be much happier with your "let's deprecate a.out entirely" as
> a second patch, because I think it's a unrelated issue and much more
> likely to have somebody pipe up and say "hey, I have this sequence
> that generates executables dynamically, and I use a.out because it's
> much simpler than ELF, and now it's broken". Or something.

Hohumm, yap, it all makes sense to me. That's definitely the safer
approach without us having to revert patches later.

So how do you wanna handle this?

I guess the easiest would be if you apply your patch directly now and
add the a.out phase-out strategy we're going for in its commit message
so that people are aware of what we're doing.

This will allow for other arch maintainers to delete
arch/*/include/asm/a.out-core.h, Jann mentions in the other mail, after
-rc1 is cut.

And then I'll carry any other patches through the tip tree ontop of -rc1
too.

Thx.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.