linux-kernel - Re: [PATCH v2] ELF: add and use SUPPRESS_WARN_UNUSED

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: <CAHk-=wgitzn6sqXZ0YjFW-pYadEXU808QPJZ5OXvM5oB47K_Lw@mail.gmail.com>
Date:   Fri, 25 Jun 2021 20:13:20 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Al Viro <viro@...iv.linux.org.uk>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Alexey Dobriyan <adobriyan@...il.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Miguel Ojeda <ojeda@...nel.org>
Subject: Re: [PATCH v2] ELF: add and use SUPPRESS_WARN_UNUSED_RESULT

On Fri, Jun 25, 2021 at 7:37 PM Al Viro <viro@...iv.linux.org.uk> wrote:
>
> Wasn't there some emulator (dosemu? wine?) that relied upon that?
> Said that, I could be easily wrong - half-asleep right now...

Different issue.

dosemu used to use vm86 mode to do hardware acceleration of 16-bit
emulation. And the way vm86 mode works, it all has to be mapped
beginning at address 0.

So yes, dosemu used to do a mmap at address 0 too, but it didn't use
this ELF mmap MMAP_PAGE_ZERO personality thing to do it, it just did
its own (it also wants a lot more than one page).

Nobody uses vm86 mode any more, because hardware acceleration of
16-bit code just isn't relevant any more. Any 16-bit code you have
doesn't need special hw modes to run sufficiently fast.

Plus x86-64 doesn't support vm86 mode at all (well, technically you
can do it in a VM that runs a 32-bit OS if you really really want to,
but see above as to why you don't really need it).

There are other things that have mmap'ed things at zero. I think all
PA-RISC HP-UX binaries used to do the same thing iBCS2 did, and the
compiler would actually hoist loads to before the NULL pointer test,
so it was pretty much "architectural". Afaik, that's the same reason
why iBCS2 did that zero mapping too, but PA-RISC just required it a
lot more.

It's a horrible thing to do, and only makes debugging harder (because
you won't actually get a SIGSEGV on a NULL pointer load, you'll just
silently get a zero value and your buggy program will continue
running).

                 Linus