Received: by 10.192.165.148 with SMTP id m20csp1415714imm; Fri, 27 Apr 2018 20:06:37 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrgLbM4Af49qg8RS9S1GddOO9GQuthsXs6CuLyikF8plbHIrMFwRA1WR7FcC10k4R9cYOwW X-Received: by 2002:a65:6216:: with SMTP id d22-v6mr4109506pgv.344.1524884797490; Fri, 27 Apr 2018 20:06:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524884797; cv=none; d=google.com; s=arc-20160816; b=YiuSAsxcpxVSdjTSeq/C+rNmIPLm7IhujZN3btdQ20JXRUYdES14OMD0Kv+Pc7wGmj RGY1rlb/UOa06ggZVnJYG+vkSXl6R42WrPA0TJ+94V8JI7OB5Wlls4Exvz76vJLvV/uI RqYnMgz1+DKGqCVpwdJfOESX75Ovti/Qkcd7qtQAZDXuksURM2QirEf4L20tGBZUfFkH zTiafAOhlaBqlWHez5nK9MyR5D70Ep0FgfN+T+MkUm+5RyOEGaH+U+gg2L948DQJSq2l odazs2sttIY+FCF4uQY8d8QPs+/HeZmfsHPrFVlCaQmzZF8UejXfY55/JgQF+zOkhRrZ H9Sg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature:dkim-signature :arc-authentication-results; bh=UDvyLlObd1guRbxbKyGLdTkE43oy+FouD+RP7HujI2o=; b=q78Imk/V5DYwpRpJQMJwh30RcDHE8+2Svzwjjrrr4VJRVRhHpehGG0swSw9Usu+diC XjCDR46jv4Bpj/INtgrQ8jXB5GowIqTISsoUFoNG7wK4kO6UMCeIdOm5v2ZwOO2j6Y1l bCr1tNW8nYEpJoKu2ucT//cBRB7oWMZL4k/ErE91LE/YMqqamCjve16BjKxwO+fV8eOp WNADyDemU7Z3lC/z/++kkRsY2oevI/CqdR2U6h0LRAlrFjuo0qpojcB11MEhQB2MzHiT ZKUDz7YpE8YPsO7d0q9RLzrqmPRuxYa4ry45Ka/euOVcoaYd0cjBeyK32FgPejKi+OYm M/fw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@google.com header.s=20161025 header.b=jlVSkcCj; dkim=fail header.i=@chromium.org header.s=google header.b=lXEmJEDT; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k3-v6si2373694pgn.634.2018.04.27.20.06.23; Fri, 27 Apr 2018 20:06:37 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@google.com header.s=20161025 header.b=jlVSkcCj; dkim=fail header.i=@chromium.org header.s=google header.b=lXEmJEDT; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933173AbeD1DFT (ORCPT + 99 others); Fri, 27 Apr 2018 23:05:19 -0400 Received: from mail-vk0-f65.google.com ([209.85.213.65]:42316 "EHLO mail-vk0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759316AbeD1DFS (ORCPT ); Fri, 27 Apr 2018 23:05:18 -0400 Received: by mail-vk0-f65.google.com with SMTP id j7-v6so2104917vkc.9 for ; Fri, 27 Apr 2018 20:05:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=UDvyLlObd1guRbxbKyGLdTkE43oy+FouD+RP7HujI2o=; b=jlVSkcCjgz2IhW2xTnfYZIdXVFfWSUwPKruMVCxg6rh9bEIADCljrsBVwpGul/i2Sf Ps1U4FEKg3MdsIkhR58c1jpeN+Hut7ziBLx9lAJ7+k+aiopyes7c7n86L8LP3mdLqyJ/ zPQl8ZH8pCuofpOEPsxbnkgY6Gcf9AI/hteu/iKmpxk+Bliyq6n19EfVobggRdfuWUAx USEbfT/ODJLh7xty/4+uYgdmhn/rp5GZLLrTbrBjsh1zcowozpq2Q1lVKhsesP6LTj4m N8w+I1iKdbXRVazby3gl1LrLKnrq/1h35ydcUijb47pB0XG2j7VuCmGU7Q6rp7JAcp61 M7PQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=UDvyLlObd1guRbxbKyGLdTkE43oy+FouD+RP7HujI2o=; b=lXEmJEDTJw43rZV37aiHMa9B2C1g7xRQRwDQhNrJ7bSlxFjqXD3iQdknRkx1l3FwM8 wOxfFRGCc+rO35U8pC0KhxdvDgnXid2TI+2wNyVSXvHHO4Nm2ynTidaOAVI4DsRRi912 /s3RHds2Iw7vObRPpk2q28S1jytglE6z98nTY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=UDvyLlObd1guRbxbKyGLdTkE43oy+FouD+RP7HujI2o=; b=YhRefXGKcpmZVZIHH2Y4+cfzILFxQFP2OY74OM0ga8+m2GgL+7yQTn5ieG3Kddv8zk 40du+6HTIPYQDwswKG4/hxadmLVeWtmJ4Xt1xjGXIEBCO4I1eYBoN+J6OpNVX7HZLWYC Jvw1DBw74hbZJaspZOxO6PCENiox9d4SqdJozb+VjvkjRcIKc7XosKmUY5lSrAr5CZ3V M0AhK+8Oq6Lr49DIm9zwlxB5ufSsxZaZsW6/HULEyJO4uZFS6JaMUathqUuK5kDL6S+q HEjOeeK1oxOai2j9i9hCg0XbIbJuHQq0nUsDOhQulRj1TXfuLQz+eErHwmpLEaDKAe5U 37Wg== X-Gm-Message-State: ALQs6tCs+74+Gp24RZihaoTNh8wAUx9YdkX/EdMakrxpMGH35ztmaDga 3m7ynKkSg7hvgcAfiPnMl+/ZWhA71HLBCJvoHUszSg== X-Received: by 2002:a1f:3096:: with SMTP id w144-v6mr3110182vkw.121.1524884717078; Fri, 27 Apr 2018 20:05:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.164.81 with HTTP; Fri, 27 Apr 2018 20:05:16 -0700 (PDT) In-Reply-To: <1524866145-20337-1-git-send-email-jhugo@codeaurora.org> References: <1524866145-20337-1-git-send-email-jhugo@codeaurora.org> From: Kees Cook Date: Fri, 27 Apr 2018 20:05:16 -0700 X-Google-Sender-Auth: yHprDh0MSGo7eE3_dbCof1L1yzo Message-ID: Subject: Re: [PATCH v2] init: Fix false positives in W+X checking To: Andrew Morton , "Paul E. McKenney" Cc: Jeffrey Hugo , linux-arm-kernel , LKML , Mark Rutland , Jan Glauber , Ard Biesheuvel , Catalin Marinas , Will Deacon , Laura Abbott , Timur Tabi , Stephen Smalley , Ingo Molnar , Thomas Gleixner , Peter Zijlstra Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 27, 2018 at 2:55 PM, Jeffrey Hugo wrote: > load_module() creates W+X mappings via __vmalloc_node_range() (from > layout_and_allocate()->move_module()->module_alloc()) by using > PAGE_KERNEL_EXEC. These mappings are later cleaned up via > "call_rcu_sched(&freeinit->rcu, do_free_init)" from do_init_module(). > > This is a problem because call_rcu_sched() queues work, which can be run > after debug_checkwx() is run, resulting in a race condition. If hit, the > race results in a nasty splat about insecure W+X mappings, which results > in a poor user experience as these are not the mappings that > debug_checkwx() is intended to catch. > > This issue is observed on multiple arm64 platforms, and has been > artificially triggered on an x86 platform. > > Address the race by flushing the queued work before running the > arch-defined mark_rodata_ro() which then calls debug_checkwx(). > > Reported-by: Timur Tabi > Reported-by: Jan Glauber > Fixes: e1a58320a38d ("x86/mm: Warn on W^X mappings") > Signed-off-by: Jeffrey Hugo Acked-by: Kees Cook -Kees > --- > > v1: > -was "arm64: mm: Fix false positives in W+X checking" (see [1]) > -moved to common code based on review and confirmation of issue on x86 > > [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2018-April/573776.html > > init/main.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/init/main.c b/init/main.c > index b795aa3..499d957 100644 > --- a/init/main.c > +++ b/init/main.c > @@ -1034,6 +1034,13 @@ static int __init set_debug_rodata(char *str) > static void mark_readonly(void) > { > if (rodata_enabled) { > + /* > + * load_module() results in W+X mappings, which are cleaned up > + * with call_rcu_sched(). Let's make sure that queued work is > + * flushed so that we don't hit false positives looking for > + * insecure pages which are W+X. > + */ > + rcu_barrier_sched(); > mark_rodata_ro(); > rodata_test(); > } else > -- > Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. > Qualcomm Technologies, Inc. is a member of the > Code Aurora Forum, a Linux Foundation Collaborative Project. > -- Kees Cook Pixel Security