Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp5360689imm; Tue, 26 Jun 2018 09:56:34 -0700 (PDT) X-Google-Smtp-Source: ADUXVKKUF/D+1iaqytvpBLez2JlQ9NOwOIsdX9MIYjTB5wYz34zZU23WlhM+ah84B6kyiK4dzI3/ X-Received: by 2002:a63:27c1:: with SMTP id n184-v6mr2019738pgn.29.1530032194683; Tue, 26 Jun 2018 09:56:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530032194; cv=none; d=google.com; s=arc-20160816; b=P4bz6F2bcKyn5AyLijr6oEz7xRpDxDmvLyesQH0mn4Qs0kQRMYk+kn0qOa6b6RvHj3 eNyfF7jn4jrYPgf3tbqa09zygFzlmN2PQA/dUySjNJZvvPdJwp7kxp1Lom73TnfGvDlo dubZnuXtnq0kY1TuZjPAAQQrMObP972iN8EKVuyBp3qlxBHE/8ji+oifgtiYUccBRkXD Yr1iyTR/2Orix3Kl1hwnRoVRzgj2vNnHpGY70DRejuFDWy1bXAqT1HWs6b5mwiKUPZaf 9U58ycXuoaEL1ws1ttJFLQ1x90lY3Zb+QYK/2kNemS9zuEInRtyR5F0c0sS2N/7tyVlN hJFA== 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=2yF/chjSYg1rhHn0ubGQyEC0d68k6bewWdcfOTWkqXc=; b=ogAPYgdgb8OYK4pAGxM3kk8vLwUukbhsarogYo4Ms8vhXS2WnAG2uEhY/sJqU3z/lZ uDyPLRfyJRBd5frVvRezRefvHAJ8aptkd5ZWtp/ZW6VyvNygJMKHTyvP+TWHvt656ADL P3QltxlDJ3ToJy9ptJr5ACXq1IMUpy7x/DemnCWflTkmgOAkp6piYGhjXKtISzU7lUwb f/BdwUF1K4AaGhKwp0Vh4VMeYBLpgrgiZ2vlc7jGciX5nLHv3Lo79svYfeO9EdHIe0ot zcMqrV9eBfC6ZQKUSWDwU8mqkWFr5n9JGGt/23OVmer/irFLSKRmeE7D+xWYHs+ADP5t k6IQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@google.com header.s=20161025 header.b=kdp7CNy4; dkim=fail header.i=@chromium.org header.s=google header.b=ZGUuUzMY; 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 a3-v6si1709885pgd.288.2018.06.26.09.56.19; Tue, 26 Jun 2018 09:56:34 -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=kdp7CNy4; dkim=fail header.i=@chromium.org header.s=google header.b=ZGUuUzMY; 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 S1752732AbeFZQzC (ORCPT + 99 others); Tue, 26 Jun 2018 12:55:02 -0400 Received: from mail-yw0-f196.google.com ([209.85.161.196]:41997 "EHLO mail-yw0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752093AbeFZQzB (ORCPT ); Tue, 26 Jun 2018 12:55:01 -0400 Received: by mail-yw0-f196.google.com with SMTP id i143-v6so4857531ywc.9 for ; Tue, 26 Jun 2018 09:55:00 -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=2yF/chjSYg1rhHn0ubGQyEC0d68k6bewWdcfOTWkqXc=; b=kdp7CNy4zlwEE8sCAbmvHqTj3240XqQmiSKrY4MEqi75mn9ndWfPuJZjg3WrOkw3b7 xjdSjDUmwlho1Kyk2H9WbG1uIGDHFWfAjaLQAIJhI8Q7gJq3k0xKszFwlpoa2SMNIFFS Sa0dT7fR5WnFItmlTjCZXSjIAmsT0m1j6Yk3F1QRkI6KOmsew0EhOkltHP1YUIsoJOa6 KLFm0ZtMEjawjvQ+NqGK7PPRLKj4dEEbx0+U04jLxICaJdPNCCD0ZICX6oaBHFc489RK BaofeG78WTmXzk1Fe8fZGuIFj6MmM6Bi3Hpg1YnA4htB+m+Ch7GfAPD//Y5F/04h/15F PusQ== 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=2yF/chjSYg1rhHn0ubGQyEC0d68k6bewWdcfOTWkqXc=; b=ZGUuUzMYRSo+HkqQMSB+pIBZsu68D0h8HDE1s+4EYjxIxqe0d2VRkWIQpk3m/NYy+e mTuQh9fmzsv5nHhN0GQZSplxS1L0cxlLEoUwygyMs8ULT2DYpLLg3jsX9cabRWbQzlk8 Lq6TRUc5ZNa7qOoW03BVNr/anFT+u6rg9Ewss= 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=2yF/chjSYg1rhHn0ubGQyEC0d68k6bewWdcfOTWkqXc=; b=oPtZMirEPnQmO6h1js7rl+aXP2z9LroMDuoaS3UnIXNAy0XBDQkTNtOdiAd2GGoQK8 6Vlth+6ZPWvXR3e68hbu8fKK2fS0perkOwnc8b/kv1pupi3XQCZihzcbiHcXctg+UCYF LPtsB5vqARubSX7zSICQm/LLUPImF821GR2BzH5+zmslAkRDgsWytkg0e37uT+utbQ/c MJi2NAefh0y3TzlZj3vzCrshWmrIvLIVVfX1M4bmJ2/O+sHgQVROb96FB3trlW9Ym/wW KADdschK1VjQmraUzuwkhclCu3A1PFVLO2RmWm7AqqeICK/sfFRDo7RztmunxFHop5ju sGEg== X-Gm-Message-State: APt69E18GkeMNOAlZW5Xew8D6zQJ5O63YqO/kshvI88CtfOC33xlPh/1 5rbqu4O7uauoGSL4BlV2XLU3XU/aQHfD1J6kVYaskQ== X-Received: by 2002:a81:8743:: with SMTP id x64-v6mr1113581ywf.129.1530032100265; Tue, 26 Jun 2018 09:55:00 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:5f51:0:0:0:0:0 with HTTP; Tue, 26 Jun 2018 09:54:59 -0700 (PDT) In-Reply-To: References: <64bf81fa-0363-4b46-d8da-94285b592caa@redhat.com> From: Kees Cook Date: Tue, 26 Jun 2018 09:54:59 -0700 X-Google-Sender-Auth: yu9TgeG0dRdU7UGku88TQHx-hf8 Message-ID: Subject: Re: [PATCH] add param that allows bootline control of hardened usercopy To: Paolo Abeni Cc: Chris von Recklinghausen , LKML , linux-mm@vger.kernel.org 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 Tue, Jun 26, 2018 at 2:48 AM, Paolo Abeni wrote: > Hi, > > On Mon, 25 Jun 2018 11:21:38 -0700 Kees Cook wrote: >> On Mon, Jun 25, 2018 at 8:08 AM, Chris von Recklinghausen >> wrote: >> > Enabling HARDENED_USER_COPY causes measurable regressions in the >> > networking performances, up to 8% under UDP flood. >> >> Which function is "hot"? i.e. which copy*user() is taking up the time? >> Do you have a workload that at can be used to reproduce the problem? > > I'm running an a small packet UDP flood using pktgen vs. an host b2b > connected. On the receiver side the UDP packets are processed by a > simple user space process that just read and drop them: > > https://github.com/netoptimizer/network-testing/blob/master/src/udp_sink.c > > Not very useful from a functional PoV, it helps mostly pin-pointing > bottle-neck in the networking stack. Cool; thanks for the pointer! > When running a kernel with CONFIG_HARDENED_USERCOPY=y, I see a 5-8% > regression in the receive tput, compared to the same kernel without > such option. > > With CONFIG_HARDENED_USERCOPY=y, perf shows ~6% of CPU time spent > cumulatively in __check_object_size (~4%) and __virt_addr_valid (~2%). Are you able to see which network functions are making the __check_object_size() calls? -Kees -- Kees Cook Pixel Security