From patchwork Tue Apr 8 20:19:01 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kees Cook X-Patchwork-Id: 3950931 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 02B569F370 for ; Tue, 8 Apr 2014 20:24:41 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 26420204D3 for ; Tue, 8 Apr 2014 20:24:40 +0000 (UTC) Received: from casper.infradead.org (casper.infradead.org [85.118.1.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1F295204B0 for ; Tue, 8 Apr 2014 20:24:39 +0000 (UTC) Received: from merlin.infradead.org ([2001:4978:20e::2]) by casper.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1WXcZN-0008Hf-3s; Tue, 08 Apr 2014 20:24:33 +0000 Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1WXcUT-0006Xj-1m; Tue, 08 Apr 2014 20:19:29 +0000 Received: from mail-ob0-x22f.google.com ([2607:f8b0:4003:c01::22f]) by merlin.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1WXcUP-0006Wg-IQ for linux-arm-kernel@lists.infradead.org; Tue, 08 Apr 2014 20:19:27 +0000 Received: by mail-ob0-f175.google.com with SMTP id uy5so1626113obc.34 for ; Tue, 08 Apr 2014 13:19:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=3YlwHI0HwCONkxe19ETpLeuRTXFdPwgC4kqIs/UYIUw=; b=VymZ/Vgl8AMMEvx7YDvzXGIsgyrPpfubSzBL/BWPgJuoF+R0oXE+D0UYCl7l7u5r1B 10jZFFIuL2LkEOsG83j4YQArtQzp5PNhE9B+5nl97+sbQsXb7qdfcllIGnlZRvJTGOLm 6zNpKSIb8ouwirElTDrLfqu+6kCddmoo6vV2GQmauC3uOIyo1kvLbPOjYUFreD7uR42C O4ibFPnC81egZxuZEsS5QhKQbvjk+HWn0IaeJpRhCevz8Xz6CyVwcnUQ1V0I0P7COixa iFHIpxKC8Z8QzH2Ok+3Cfxv5NergU75K9AHnCpJKjJG1LDzl36uCBzDIeBTlKnVMT0lR CRaQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=3YlwHI0HwCONkxe19ETpLeuRTXFdPwgC4kqIs/UYIUw=; b=nMYtLc7OBdYwGswYE50MlLWfz1uOJLIzb39WY8uHO2+ZuYKO90LE7Y1IQHuDCBdvHe vSqPcMGIEQr/u8alFAMGiXDb8pbC0Ux3yYOZlkcQmRFY9oxFtYJmIR/8cpVA6izEq8eT oc1NPzcu7/y1kxld+dqch+RSBtBypvrygIHNo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3YlwHI0HwCONkxe19ETpLeuRTXFdPwgC4kqIs/UYIUw=; b=Nfriwm0SEld77x8sVbO3h/DtZhpKYrzhiA+b0YL3y0qWBTM96ynImE5W9G6PhpkLUO KdFupshQ3PI+iVaV2Q+X6uJRLufAGYZsL2Err/LCS28cUn8KpKWF98QkUiXod5nPWW8C WVu3aO72C4B9VQEBCef2nlScxryJmD30nMk9HSGHjynbNYlIUUXOmWUe0xAPEOFMT/Va 8cxvFSbb+t4oD2sdqQ+ON2I2z/9Y137Pu4RmJYFCSR6zY5yDv5xGbQp09dbfyD9uBdLy NegB8SRy5FKv7cWBa7HvxPw/wC87zZoQIO5uvZpF+feUEC2B9/EMbvC/NIu3D4nBQC1E yKVg== X-Gm-Message-State: ALoCoQnLhY5Y4xcIkGmXziVdx2U5HjFq9g1TFPAqEk3P8FIEXybmSO7MtRByTDfirEuwO2fEoq6CDjFbG8A/iQtt3/4/5E3RwHvf4NowDaoNwCCiqqPUALB5EHpzGnl891SnKkjuU0YsyGN0Bkwk4+wOHifxIVFPVTZpewuvWbiRxpkxeKlTfqJBnnd9QZcFEdqGxzVMLO3NHf/NbaoLNmzoqpUOrzcTWg== MIME-Version: 1.0 X-Received: by 10.182.233.201 with SMTP id ty9mr5036578obc.29.1396988341887; Tue, 08 Apr 2014 13:19:01 -0700 (PDT) Received: by 10.182.226.163 with HTTP; Tue, 8 Apr 2014 13:19:01 -0700 (PDT) In-Reply-To: <20140408194815.GA6188@debian> References: <1396577719-14786-1-git-send-email-keescook@chromium.org> <1396577719-14786-3-git-send-email-keescook@chromium.org> <20140404195818.GA21028@debian> <1396960898.3567.55.camel@linaro1.home> <1396973561.14809.26.camel@linaro1.home> <20140408194815.GA6188@debian> Date: Tue, 8 Apr 2014 13:19:01 -0700 X-Google-Sender-Auth: 3KiuvRtndHDapdig2ybSxqOBxwk Message-ID: Subject: Re: [PATCH 2/2] ARM: mm: make text and rodata read-only From: Kees Cook To: Rabin Vincent X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20140408_161925_685014_789394F7 X-CRM114-Status: GOOD ( 26.31 ) X-Spam-Score: -2.3 (--) Cc: "Jon Medhurst \(Tixy\)" , Laura Abbott , Catalin Marinas , Will Deacon , LKML , Alexander Holler , Russell King , "linux-arm-kernel@lists.infradead.org" X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_MED,RP_MATCHES_RCVD,T_DKIM_INVALID,UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Tue, Apr 8, 2014 at 12:48 PM, Rabin Vincent wrote: > On Tue, Apr 08, 2014 at 09:59:07AM -0700, Kees Cook wrote: >> On Tue, Apr 8, 2014 at 9:12 AM, Jon Medhurst (Tixy) wrote: >> > And is the page table being modified unique to the current CPU? I >> > thought a common set of page tables was shared across all of them. If >> > that is the case then one CPU can modify the PTE to be writeable, >> > another CPU take a TLB miss and pull in that writeable entry, which will >> > stay there until it drops out the TLB at some indefinite point in the >> > future. That's the scenario I was getting at with my previous comment. >> >> As I understood it, this would be true for small PTEs, but sections >> are fully duplicated on each CPU so we don't run that risk. This was >> the whole source of my problem with this patch series: even a full >> all-CPU TLB flush wasn't working -- the section permissions were >> unique to the CPU since the entries were duplicated. > > The PGD is per-mm_struct. mm_structs can be shared between processes. > So the PGD is not per CPU. > > This set_kernel_text_rw() is called from ftrace in stop_machine() on one > CPU. All other CPUs will be spinning in kernel threads inside the loop > in multi_cpu_stop(), with interrupts disabled. Since kernel threads use > the last process' mm, it is possible for the other CPU(s) to be > currently using the same mm as the modifying CPU. > > For any other CPU to pull in the writable entry it would have to get a > TLB miss inside the loop in multi_cpu_stop(), after the state transition > to MULTI_STOP_RUN and before the state transition to MULTI_STOP_EXIT. > This is unlikely, but theoretically possible, for example if > multi_cpu_stop() straddles sections. Ah! Now I understand. Thanks for the clarification. > To prevent any stale entries being used indefinitely, perhaps the all > CPU TLB flush can be inserted into > ftrace_arch_code_modify_post_process(), which is called after the > stop_machine() and which is where x86 for example makes the entries > read-only again. Do you mean something like this? Thanks! -Kees diff --git a/arch/arm/kernel/ftrace.c b/arch/arm/kernel/ftrace.c index ea446ae09c89..b8c75e45a950 100644 --- a/arch/arm/kernel/ftrace.c +++ b/arch/arm/kernel/ftrace.c @@ -90,6 +90,8 @@ int ftrace_arch_code_modify_prepare(void) int ftrace_arch_code_modify_post_process(void) { set_all_modules_text_ro(); + /* Make sure any TLB misses during machine stop are cleared. */ + flush_tlb_all(); return 0; }