From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6236 Path: news.gmane.org!not-for-mail From: Andy Lutomirski Newsgroups: gmane.linux.lib.musl.general Subject: Re: A running list of questions from "porting" Slackware to musl Date: Wed, 01 Oct 2014 08:00:59 -0700 Message-ID: <542C172B.5030601@mit.edu> References: <542AA579.2040304@langurwallah.org> <20140930153216.GA1785@newbook> <20140930155023.GC23797@brightrain.aerifal.cx> <542B41C4.1040701@amacapital.net> <20141001000516.GI23797@brightrain.aerifal.cx> <542B95DB.7050209@mit.edu> <20141001132932.GJ23797@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1412175683 2653 80.91.229.3 (1 Oct 2014 15:01:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 1 Oct 2014 15:01:23 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6249-gllmg-musl=m.gmane.org@lists.openwall.com Wed Oct 01 17:01:17 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 1XZLP2-0005Rl-Ob for gllmg-musl@plane.gmane.org; Wed, 01 Oct 2014 17:01:16 +0200 Original-Received: (qmail 26141 invoked by uid 550); 1 Oct 2014 15:01:16 -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 26128 invoked from network); 1 Oct 2014 15:01:15 -0000 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=WWHp9uEBjFFFnD+hNYWWQSCmOCP18aXA3kATqeegAts=; b=KQe8lmSSwzd4zO0SvG6UaJantIIZUdaU7Rct4trIIjCRrqvp8Q1viG1ZfjYdDx92k8 ZfGNn70wB86LR4RiIg01ACOBGnF9HzEd025RekmtM3/Wnqr/RZe4F2fiIL3tj1dS1lCT NIH9yr3bxA3dsq6q2O6P5d8ZqvCl6sEa6S10o81QUTA6mVWmGT7FyYtgWG/xRxwkG89h qHArU9vrEWGdOQBcNiNmbmn/gg5TC8gM2Yc4igvWwMVolUsRAFMRESVKhdHKiPA2/3cQ QFhHDMMleNHGcoXNuFkkbt987igpA4d9Nj/C5HtAcfGjGM4UFLcOIYQ60ZYgu6LDzlDa oKHw== X-Gm-Message-State: ALoCoQl8QDp18OAj/jFALZHKy1iceJUQkz6/fhDgJuvktYkaUcJo4zsEgFAIZUP6rHk6fOeIFzBw X-Received: by 10.68.242.161 with SMTP id wr1mr5532559pbc.167.1412175663585; Wed, 01 Oct 2014 08:01:03 -0700 (PDT) X-Google-Original-From: Andy Lutomirski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 In-Reply-To: <20141001132932.GJ23797@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:6236 Archived-At: On 10/01/2014 06:29 AM, Rich Felker wrote: > On Tue, Sep 30, 2014 at 10:49:15PM -0700, Andy Lutomirski wrote: >>>> (Even better: the loader could patch the PLT with a direct jump. Could >>>> musl do this? At least in the case where the symbol is within 2G of the >>>> PLT entry, >>> >>> This is really not a good idea. The old PowerPC ABI did this, and musl >>> does not support it (it requires the new "secure-plt" mode). Hardened >>> kernels have various restrictions on modifying executable pages, up to >>> and including completely forbidding this kind of usage. And even if >>> it's not forbidden, it's going to use more memory due to an additional >>> page (or more) per shared library that's not going to be sharable. >>> Also it requires complex per-arch code (minimal machine code >>> generation, instruction cache flushing/barriers, etc.). >> >> That extra page might not be needed if the linker could end up >> removing a bunch of GOT entries for functions that don't have their >> addresses taken. (Or, on x86_64, where unaligned access is cheap, >> the GOT could actually overlap the PLT in memory, but only if > > This is not an option. It would require the page containing the GOT > (and a lot of data) to be executable. Not only is this a huge security > risk (makes exploiting other vulnerabilities a lot easier); it's also > physically impossible to do on hardened kernels which simply lack > "rwx" permission for mappings. No rwx mapping would ever be needed. The GOT would be shoved *into* the text segment, and the loader would switch it to rw, write in the relocations, and switch it back to rx. Some hardened kernels disallow this. I think that this particular hardening option has long since served its purpose (distros no longer ship things that are dangerous like this), but any exploit that can convince a buggy program to do: - mprotect to rw (or just find an rw mapping to begin with) - attacker-controlled shellcode write - mprotect to rx - attacker-contolled jump on a non-stack address has already won (they could just as easily have written a ROP or SROP payload, or they could have written an environment block and called execve instead of mprotect). Disallowing the mprotect to rx is IMO utterly pointless and merely annoys everyone who tries to write a JIT compiler. At least new enough kernels probably allow reliable JITting using memfd_create and two mmap calls. (It wouldn't work anyway as I've described it because x86_64 has no 64-bit absolute jump.) Anyway, this is off-topic enough that I'll shut up now. > >>>> this should be straightforward if no threads have been >>>> started yet. >>> >>> Threads having been started or not are not relevant. The newly loaded >>> code is not visible until dlopen returns, so nothing can race with >>> modifications to it. >> >> True, at least when lazy binding is off. > > musl does not do lazy binding at all, and won't. There's been some > demand for it in terms of allowing loading hacks where the symbols > needed by the loaded library are not provided until later, but that > can be satisfied by emulating it (basically, keeping a list of > unsatisfied relocs and retrying them after each dlopen) rather than > actually doing lazy binding at call time. > > Rich >