From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5343 Path: news.gmane.org!not-for-mail From: Andy Lutomirski Newsgroups: gmane.linux.lib.musl.general,gmane.linux.ports.arm.kernel Subject: Re: Re: Thread pointer changes Date: Fri, 27 Jun 2014 15:51:04 -0700 Message-ID: References: <20140610072835.GA8466@brightrain.aerifal.cx> <20140611145533.GT179@brightrain.aerifal.cx> <53ADC5B1.6080905@amacapital.net> <20140627200949.GQ32514@n2100.arm.linux.org.uk> <20140627210931.GT23102@port70.net> <20140627213051.GS32514@n2100.arm.linux.org.uk> <20140627215541.GC16724@brightrain.aerifal.cx> <20140627221744.GU32514@n2100.arm.linux.org.uk> <20140627224017.GU23102@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1403909505 12485 80.91.229.3 (27 Jun 2014 22:51:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 27 Jun 2014 22:51:45 +0000 (UTC) Cc: Russell King - ARM Linux , Rich Felker , musl@lists.openwall.com, Kees Cook , "linux-arm-kernel@lists.infradead.org" To: Szabolcs Nagy Original-X-From: musl-return-5348-gllmg-musl=m.gmane.org@lists.openwall.com Sat Jun 28 00:51:38 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 1X0ezY-0000Vh-NF for gllmg-musl@plane.gmane.org; Sat, 28 Jun 2014 00:51:36 +0200 Original-Received: (qmail 30431 invoked by uid 550); 27 Jun 2014 22:51:36 -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 30423 invoked from network); 27 Jun 2014 22:51:36 -0000 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=pZQDk8cfx74o/h4R0py+3Tx0xxYCySQgxtWFG7E+N7Q=; b=P/DCD1QhHCes+K0CpOHprw0plj5OF5IdKfJ5lPh+K+4RtySGjKBnB/e/gcV2bWSLDQ 8tYt5NjL768FlxR6xOmxUUpS7booDpnBTtEGNLYMOYrRAs/4BAvA11fu0vHpsF+q1UUv YaJSf7VrmlZcNdZHr/8Y1r0xRGwI2gonOYvmjQNNoWOyNLh1dHEVd7XvS0vP8S9F7P/C 73gc88ftzXpAwkZwSwEkTs5v4n7QEZXz4NWgOtHNS6Zg59ZyFwPrZBU685XVPUSUQNIJ 7emFXswDB1u7i/qAPZGA1jVWQsBLQplVISc3G1AGclCYJMfUbRg0ScnwdxLx9xVsKYgI CD2w== X-Gm-Message-State: ALoCoQlczRgXRmAjNml90nPYL5ch2kz/kzekiYBROCLsWdlsgIwCglbHkfCFJ/bNtCiYvVPZ4Cdp X-Received: by 10.112.136.196 with SMTP id qc4mr17699876lbb.6.1403909484908; Fri, 27 Jun 2014 15:51:24 -0700 (PDT) In-Reply-To: <20140627224017.GU23102@port70.net> Xref: news.gmane.org gmane.linux.lib.musl.general:5343 gmane.linux.ports.arm.kernel:336488 Archived-At: On Fri, Jun 27, 2014 at 3:40 PM, Szabolcs Nagy wrote: > * Russell King - ARM Linux [2014-06-27 23:17:44 +0100]: >> I think you're are missing one obvious solution to this which you can do: >> you are passed the HWCAP fields in the ELF auxinfo. This will tell you >> if the CPU has TLS support or not. If it has TLS support, then you don't >> need to use the kuser helpers, and you know that it is a CPU which is ARM >> architecture v6k or later, and it has things like the CP15 barrier >> instructions. If you want to know that the CPU supports the DMB >> instruction rather than the CP15 barrier instruction, then you have to >> check the uname details, or read /proc/cpuinfo (but I'd rather you >> didn't.) >> > > but cp15 barrier is deprecated on armv7+ > > and i think the kernel can avoid the barriers on non-smp systems making > kuser helpers possibly preferable even if TLS HWCAP flag is set IMO it would be much better to do this by either telling userspace that the system is !SMP or by allowing the kuser helpers to live at a randomized address. There's already been at least one paper describing an exploit technique that's blocked by vsyscall emulation. This kind of hardening takes a while to get deployed, and making new userspace not depend on fixed-address code is a good thing to get started on, at least when targetting newer hardware. --Andy