From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8BB28C04AB4 for ; Fri, 17 May 2019 15:56:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5B6922083E for ; Fri, 17 May 2019 15:56:56 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="E7oWj3DD" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729303AbfEQP4z (ORCPT ); Fri, 17 May 2019 11:56:55 -0400 Received: from mail-pl1-f194.google.com ([209.85.214.194]:46029 "EHLO mail-pl1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728664AbfEQP4y (ORCPT ); Fri, 17 May 2019 11:56:54 -0400 Received: by mail-pl1-f194.google.com with SMTP id a5so3520219pls.12 for ; Fri, 17 May 2019 08:56:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=nrqjUKLpsCtJJ04ErApfFg0RR5DmaSuhMiOpsYm4b/k=; b=E7oWj3DDjt+kEdZeewfLumYWCuhjVUc/osh0djljunRfkteN7XJXNs5MS+RX5GI/Lq Puj3Z3HgxCD/6AC6HOECerm430xm+nTSbJv05r7At57ftXWvGwRJYxFFEUoVKbSOr4Gr iBqixCpWNw+8db7SWpOHdiN1vkT5zH1by9VEE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=nrqjUKLpsCtJJ04ErApfFg0RR5DmaSuhMiOpsYm4b/k=; b=Ti6ojibe1PQlTMHFadCFBMvkBjqOTpPbJ4E1w+TMYmZrbUIojg+eWVT5oSum10gJXB p3V22PIL7P+ALdHjYc2Bq4SJrbztcm8sunMAjTvMCI572EvGUsgHVsx935+oE6rQcdWK e4Yt3n9IPZ5DmvfQq8krgbi6GCuuNZg0MjYZY1MO1x17IOSUi2s98YH/szmcIHfdyEhP M1sLAqBRRK08zf9gV/mgdu+p1XG7P7KFsg1K9dntJMZvpKU7tUEtOdQOxl1MYHjz8OgW o1bNE9SAVp56yIG+d4kxVpmTfQVhYOam1s54gS8heFvdojWEqk55pcb9AMWa72KsG7tA /D/Q== X-Gm-Message-State: APjAAAXZ4DiuCBH8Qy8QcZ/OzjG1YfcYEc1+rDz9cLaQyDGHBUj3tMEL 371uAZtZvpKlS/1Lrmq7ctj3Bb+GMeM= X-Google-Smtp-Source: APXvYqx5L1JIW0KgYJL4c2qH5Z+VHBDccN7Wk+p90g4IAEzcge2qHeMGOakMMnS0HM9WEXWMQfyTKA== X-Received: by 2002:a17:902:2bc9:: with SMTP id l67mr21517345plb.171.1558108614314; Fri, 17 May 2019 08:56:54 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id 2sm11532199pgc.49.2019.05.17.08.56.53 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 17 May 2019 08:56:53 -0700 (PDT) Date: Fri, 17 May 2019 08:56:52 -0700 From: Kees Cook To: Dan Williams Cc: Jan Kara , linux-nvdimm , stable , Jeff Moyer , Ingo Molnar , Christoph Hellwig , Al Viro , Thomas Gleixner , Matthew Wilcox , Jeff Smits , linux-fsdevel , Linux Kernel Mailing List Subject: Re: [PATCH] libnvdimm/pmem: Bypass CONFIG_HARDENED_USERCOPY overhead Message-ID: <201905170855.8E2E1AC616@keescook> References: <155805321833.867447.3864104616303535270.stgit@dwillia2-desk3.amr.corp.intel.com> <20190517084739.GB20550@quack2.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 17, 2019 at 08:08:27AM -0700, Dan Williams wrote: > As far as I can see it's mostly check_heap_object() that is the > problem, so I'm open to finding a way to just bypass that sub-routine. > However, as far as I can see none of the other block / filesystem user > copy implementations submit to the hardened checks, like > bio_copy_from_iter(), and iov_iter_copy_from_user_atomic() . So, > either those need to grow additional checks, or the hardened copy > implementation is targeting single object copy use cases, not > necessarily block-I/O. Yes, Kees, please advise. The intention is mainly for copies that haven't had explicit bounds checking already performed on them, yes. Is there something getting checked out of the slab, or is it literally just the overhead of doing the "is this slab?" check that you're seeing? -- Kees Cook