From owner-freebsd-stable@FreeBSD.ORG Wed Apr 4 16:25:49 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 016321065670 for ; Wed, 4 Apr 2012 16:25:49 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 99BA38FC1B for ; Wed, 4 Apr 2012 16:25:48 +0000 (UTC) Received: by vbmv11 with SMTP id v11so421744vbm.13 for ; Wed, 04 Apr 2012 09:25:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=XcrsRa2POI4hcu78tJ1bupFQqY0+weX3Gigu8mM4x6k=; b=b7kcRFvYcbv/izuDktIphnFUqNaEUFtN9hvIeOqO3Uk5mzSnJt3RqLgUW0MWYdZJf6 mGxQm0QO7FONuTf4gnE5gVlrwNnJdiAMAPoqZExen2AuHfljuRoBO9NEEk+ROQ2TaK2K g+0jGGIsFz0vrcWmTn1blTBP8YIdtzjF81PNo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=XcrsRa2POI4hcu78tJ1bupFQqY0+weX3Gigu8mM4x6k=; b=I5HljkNPjNf8koIWKItf2KmzitMnOGJQWzsMVl0kodK2icnUg5x7gwm3HyEq1l56vQ NFIugpFQWbwqHl/eGPQ70xQWTtQJxa5dkGL6YdaZJhNxcmizADlWJY0lMhk35yzHdtH2 M2lb3nn740YwCZ49skY3K2BGSWc6mfv3WvvHFRBG/lo8PIYWrU1jWnzvhD6Rg0ysqcqm 0UuijfcpuvF+h2bL3p+r6TPi/PtJ62CuJex0J/Efse9DP9J+Tf+mNHHnlxwQc8HuZVSa gkEtcVBbnEfZzL4uk+I906lU7OkKfR3u25z7FiagKhsaLfrTqsVpdkjo7af5815DMYtp hs2w== MIME-Version: 1.0 Received: by 10.52.177.34 with SMTP id cn2mr6883010vdc.64.1333556748025; Wed, 04 Apr 2012 09:25:48 -0700 (PDT) Received: by 10.220.180.199 with HTTP; Wed, 4 Apr 2012 09:25:47 -0700 (PDT) In-Reply-To: <1333555093.1090.81.camel@revolution.hippie.lan> References: <4F766F29.2030803@cs.stonybrook.edu> <4F79D88B.3040102@cs.stonybrook.edu> <4F79E27E.3000509@cs.stonybrook.edu> <4F79FCB8.1090003@cs.stonybrook.edu> <4F7A05C4.9070808@cs.stonybrook.edu> <20120403170259.GA94837@neutralgood.org> <1333550029.1090.67.camel@revolution.hippie.lan> <1333555093.1090.81.camel@revolution.hippie.lan> Date: Wed, 4 Apr 2012 09:25:47 -0700 Message-ID: From: Peter Wemm To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnultT+RdcZ9FpN4RP4iJNf8EFuPWaoYhQGcH3cATBjgt54R+2O8APqiON05K8M8JCFul9A Cc: freebsd-stable@freebsd.org, jb Subject: Re: Text relocations in kernel modules X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 16:25:49 -0000 On Wed, Apr 4, 2012 at 8:58 AM, Ian Lepore wrote: [..] > This whole relocation question is just a big red herring. =A0The kernel > loader relocating a kernel module at load time does not open any > opportunity for userland code to launch an attack on the memory pages > into which the module gets loaded. It is even more of a red herring because the basic assumption of why the relocation is a problem is invalid. In userland, a text relocation happens like this: mprotect(addr, PROT_READ|PROT_WRITE|PROT_EXEC, PAGE_SIZE); fixup_text_relocation() mprotect(addr, PROT_READ|PROT_EXEC) It's easy to see why this is something that you'd want to avoid. It causes a write fault, dirties an entire page, and leaves userland text writeable for a moment. Reducing these is worthwhile as a goal of hardening. The PaX hardening patches explicitly disable this mark/unmark phase in userland ld.so. In userland, a -fPIC cross-file relocation happens like this: fixup_readwrite_PLT_relocation() Note that the PLT is always read/write. If you look at certain tools that manage code injection you'll see that they intercept the PLT and can get away with it quite nicely. Having -fPIC relocations makes it a little easier because there's a single address to intercept. In the kernel, there is no distinction between text and data at all. It is read/write always, there is no write bit flipping, ever. A kernel text relocation on i386 looks like this: fixup_relocation(); A kernel text relocation with -fPIC on i386 looks like this: panic("reloc type not implemented") A kernel text relocation on amd64 looks like this: fixup_relocation(). Neither i386 or amd64 do -fPIC modules. There is no brief window that text is writeable, because it is always writeable by the kernel, as it comes from the kernel malloc pool(). --=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell