[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrWg+vZWAdY-6etLnh=wyB1aXdG9s8ASUXX=cjjFm7CKZQ@mail.gmail.com>
Date: Tue, 25 Jun 2019 13:13:11 -0700
From: Andy Lutomirski <luto@...nel.org>
To: Kees Cook <keescook@...omium.org>
Cc: Florian Weimer <fweimer@...hat.com>, Linux API <linux-api@...r.kernel.org>,
Kernel Hardening <kernel-hardening@...ts.openwall.com>, linux-x86_64@...r.kernel.org,
linux-arch <linux-arch@...r.kernel.org>, Andy Lutomirski <luto@...nel.org>,
"Carlos O'Donell" <carlos@...hat.com>
Subject: Re: Detecting the availability of VSYSCALL
On Tue, Jun 25, 2019 at 1:08 PM Kees Cook <keescook@...omium.org> wrote:
>
> On Tue, Jun 25, 2019 at 05:15:27PM +0200, Florian Weimer wrote:
> > Should we try mapping something at the magic address (without MAP_FIXED)
> > and see if we get back a different address? Something in the auxiliary
> > vector would work for us, too, but nothing seems to exists there
> > unfortunately.
>
> It seems like mmap() won't even work because it's in the high memory
> area. I can't map something a page under the vsyscall page either, so I
> can't distinguish it with mmap, mprotect, madvise, or msync. :(
>
I keep contemplating making munmap() work on it. That would nicely
answer the question: if munmap() fails, it's not there, and, if
munmap() succeeds, it's not there :)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
