From: "Michael Kerrisk (man-pages)" <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: "H.J. Lu" <hjl.tools-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Carlos O'Donell <carlos-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
linux-man <linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Cc: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
Jeff Law <law-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
Zack Weinberg <zackw-VmQCmMdMyN0AvxtiuMwx3w@public.gmane.org>,
Andi Kleen <andi-Vw/NltI1exuRpAAqCnN02g@public.gmane.org>,
Adhemerval Zanella
<adhemerval.zanella-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
GNU C Library
<libc-alpha-9JcytcrH/bA+uJoB2kUjGw@public.gmane.org>
Subject: Re: [PATCH] Add Prefer_MAP_32BIT_EXEC to map executable pages with MAP_32BIT
Date: Wed, 16 Dec 2015 15:02:04 +0100 [thread overview]
Message-ID: <56716EDC.7020205@gmail.com> (raw)
In-Reply-To: <CAMe9rOo1OBOGruWMoLTx96wnkKUYPzBZ5HcOCFdGJEp+jTRzVA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 12/15/2015 10:34 PM, H.J. Lu wrote:
> On Tue, Dec 15, 2015 at 1:06 PM, Carlos O'Donell <carlos-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>> On 12/15/2015 03:08 PM, H.J. Lu wrote:
>>> On Tue, Dec 15, 2015 at 10:38 AM, Carlos O'Donell <carlos-H+wXaHxf7aJhl2p70BpVqQ@public.gmane.orgm> wrote:
>>>>> On 12/15/2015 01:27 PM, Carlos O'Donell wrote:
>>>>>>> + cpu_features->feature[index_Prefer_MAP_32BIT_EXEC]
>>>>>>> + |= get_prefer_map_32bit_exec ();
>>>>>>>
>>>>>>> You wouldn't need get_prefer_map_32bit_exec, since this is all part of
>>>>>>> the code, like dl-librecon.h, which parses the extra env var.
>>>>>
>>>>> To be clear:
>>>>>
>>>>> * Add new bit flag definitions for cpu_features.
>>>>> * Add a sysdeps/unix/sysv/linux/x86_64/dl-silvermont.h
>>>>> * Fill in EXTRA_LD_ENVVARS or add new ones.
>>>>> * Write to rtld's GLRO cpu_features the bit you need based
>>>>> on __libc_enable_secure.
>>>>>
>>>>> That should simplify and concentrate the Silvermont fixes to
>>>>> just two files, making future maintenance and documentation
>>>>> easier.
>>>>>
>>>>>
>>> This is the updated patch. I put EXTRA_LD_ENVVARS and
>>> EXTRA_UNSECURE_ENVVARS in x86_64/64/dl-librecon.h
>>> to be consistent with i386/dl-librecon.h. If we ever need to
>>> update EXTRA_LD_ENVVARS/EXTRA_UNSECURE_ENVVARS
>>> in the future, we have a single file to change.
>>>
>>> Tested on x86-64. OK for master?
>>>
>>> Thanks for all the feedbacks and suggestions.
>>
>> This looks much better and much cleaner. Looks good to me now. It also
>> appears you have consesnsus with this last change.
>>
>> It needs a bug # please since you're fixing a user-visible performance
>> problem on Silvermont.
>
> I opened
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=19367
>
> and checked in my patch.
>
>> It appears to meet Zack's requirement to choose a security safe default
>> at the expense of performance (I agree with that).
>>
>> I *strongly* urge you to immediately submit a patch to the linux man
>> pages project to document that as of 2.23 this new flag exists and
>> does what you describe it does.
(Thanks, Carlos.)
> Here is a patch for Linux man page.
Thanks, H.J. I applied the patch and tweaked your text somewhat.
Does the following look okay?
LD_PREFER_MAP_32BIT_EXEC
(x86-64 only)(glibc since 2.23) According to the Intel
Silvermont software optimization guide, for 64-bit appli‐
cations, branch prediction performance can be negatively
impacted when the target of a branch is more than 4GB away
from the branch. If this environment variable is set (to
any value), ld.so will first try to map executable pages
using the mmap(2) MAP_32BIT flag, and fall back to mapping
without that flag if that attempt fails. NB: MAP_32BIT
will map to the low 2GB (not 2GB) of the address space.
Because MAP_32BIT reduces the address range available for
address space layout randomization (ASLR), LD_PRE‐
FER_MAP_32BIT_EXEC is always disabled in secure-execution
mode.
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2015-12-16 14:02 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-15 21:34 [PATCH] Add Prefer_MAP_32BIT_EXEC to map executable pages with MAP_32BIT H.J. Lu
[not found] ` <CAMe9rOo1OBOGruWMoLTx96wnkKUYPzBZ5HcOCFdGJEp+jTRzVA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-12-16 14:02 ` Michael Kerrisk (man-pages) [this message]
[not found] ` <56716EDC.7020205-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-12-16 14:04 ` Carlos O'Donell
2015-12-16 14:16 ` Phil Blundell
[not found] ` <1450275413.1472.215.camel-MHJFCCCcTeg@public.gmane.org>
2015-12-16 14:33 ` Michael Kerrisk (man-pages)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56716EDC.7020205@gmail.com \
--to=mtk.manpages-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
--cc=adhemerval.zanella-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=andi-Vw/NltI1exuRpAAqCnN02g@public.gmane.org \
--cc=carlos-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=hjl.tools-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=law-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=libc-alpha-9JcytcrH/bA+uJoB2kUjGw@public.gmane.org \
--cc=linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=zackw-VmQCmMdMyN0AvxtiuMwx3w@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.