From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5356 Path: news.gmane.org!not-for-mail From: u-igbb@aetey.se Newsgroups: gmane.linux.lib.musl.general,gmane.linux.ports.arm.kernel Subject: Re: Re: Thread pointer changes Date: Sat, 28 Jun 2014 09:09:57 +0200 Message-ID: <20140628070957.GK5343@example.net> References: <20140610072835.GA8466@brightrain.aerifal.cx> <20140611145533.GT179@brightrain.aerifal.cx> <53ADC5B1.6080905@amacapital.net> <20140627213743.GB16724@brightrain.aerifal.cx> <20140627220400.GT32514@n2100.arm.linux.org.uk> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1403939455 31600 80.91.229.3 (28 Jun 2014 07:10:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 28 Jun 2014 07:10:55 +0000 (UTC) Cc: linux-arm-kernel@lists.infradead.org To: musl@lists.openwall.com Original-X-From: musl-return-5361-gllmg-musl=m.gmane.org@lists.openwall.com Sat Jun 28 09:10:49 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1X0mme-0003kk-9R for gllmg-musl@plane.gmane.org; Sat, 28 Jun 2014 09:10:48 +0200 Original-Received: (qmail 26532 invoked by uid 550); 28 Jun 2014 07:10:45 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 26516 invoked from network); 28 Jun 2014 07:10:44 -0000 X-T2-Spam-Status: No, hits=0.8 required=5.0 tests=BAYES_50 Received-SPF: none receiver=mailfe02.swip.net; client-ip=178.217.187.39; envelope-from=u-igbb@aetey.se Content-Disposition: inline In-Reply-To: <20140627220400.GT32514@n2100.arm.linux.org.uk> User-Agent: Mutt/1.5.23 (2014-03-12) Xref: news.gmane.org gmane.linux.lib.musl.general:5356 gmane.linux.ports.arm.kernel:336535 Archived-At: On Fri, Jun 27, 2014 at 11:04:00PM +0100, Russell King - ARM Linux wrote: > The kuser page isn't going anywhere _except_ for one situation: where > the system integrator has determined that they have built their > userspace not to require the kuser helpers, and wish to have greater > security and performance through doing so. > If the userspace requires the kuser helpers, then the page *must* be > provided by the kernel. > > It is a system integrator/distro bug to provide a kernel with the kuser > helpers disabled, but then to provide a libc which requires the page. ... > The system integrator has a choice to make: [how to compile the kernel and the library] I would like you to be aware that the assumed "system integrator/distro" is not necessarily a single entity. Generally speaking it is different parties who choose the kernel and the libc_s_ being used (note the plural). Running statically linked binaries is not the only example of this. Running applications from a global file system (where the shared libraries being used are placed too) is what we do all the time. We want the users to be able to run our software on all and any distros (and they do). The common denominator is the Linux ABI against the kernel. The more "locally defined" this ABI happens to be, the less usable/useful it is. This does not invalidate your point - of course the hardware owner/administrator _may_ choose to render third-party applications unusable on that hardware unit, that's fine. But is he/she the same party as the "system integrator"? Not necessarily. Regards, Rune