Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp4418538imm; Mon, 25 Jun 2018 15:37:11 -0700 (PDT) X-Google-Smtp-Source: ADUXVKLp4V6jcp0KO/Hs54B3OrxfeK2Zr2sB81lImu3WuCL7E1cyPEBYuLJtdsd36WK9i84/izWJ X-Received: by 2002:a17:902:6b47:: with SMTP id g7-v6mr14324651plt.251.1529966231772; Mon, 25 Jun 2018 15:37:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529966231; cv=none; d=google.com; s=arc-20160816; b=MaZ7lzdo7V4V6ZwH0XwvrKbF2zYUucKqy2NvuiyKT8b63OpPXLmkXqDW8RYzj56zSf OfNNshxj7a2zkoHlcSG881wM57+VRtElCQejcLAArzhMp7fwunV7bno4s54Nf9/Wv/1R NveMfEsBVf2I1bvoBz3Z2CPbYCHqCLDjUoCiCTNswUlPd80FjNC/9tzSx3j4Zd9BXz8w uVB7EFA+y0fjT9gPEss8C0E8oxl5IVc7GrMUubeDJ/PIRuF5+sBKGr8LjaOa7HBixyFk AedHxIA8L8hKkxxM3T86bwUmEyYnzy0WvCbMbAxJCyy1PlPj0FsPntAIakiTB6VMho3b khGA== 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=xYEbe008VrJdwYdW4UOYZf/SbvbAtZWqvecgZQ5B2b8=; b=pVm+y09w8Mx2pq0KY0En9tpqfwfAQm2SoU3SRROz19aKM4NqU569Tn84jBEXxaK43J xtGR4R+S5m9SHwtI/a3b06trFn2klzPFwH+7DTTyCYbfe2W8nyiUxfGwcDsEztP/IB0Y zkgLTUAKwo1CdoZOCaL0lcqCe70HhGNi6mCYNoaNR2/vC2PKqwsH8FjsJe8qoSA19IlJ 2A7buy4qbcDGUIojzpIKyAVx1ZMRhfxo2bEBpxTZM4KbDjVMZiqN5JaiLpDCsk8abUR4 PsJrtxlDizwzECPemc47l+PMWYYSgwkeNWbDGOCJiEamgx9zT6rWeeBK+R/mvD08HliH 2lhw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@google.com header.s=20161025 header.b=SNQfvF3o; dkim=fail header.i=@chromium.org header.s=google header.b=GK1frj3w; 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 w13-v6si90681plp.51.2018.06.25.15.36.57; Mon, 25 Jun 2018 15:37:11 -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=SNQfvF3o; dkim=fail header.i=@chromium.org header.s=google header.b=GK1frj3w; 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 S1754728AbeFYWf5 (ORCPT + 99 others); Mon, 25 Jun 2018 18:35:57 -0400 Received: from mail-yw0-f194.google.com ([209.85.161.194]:46359 "EHLO mail-yw0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752553AbeFYWfz (ORCPT ); Mon, 25 Jun 2018 18:35:55 -0400 Received: by mail-yw0-f194.google.com with SMTP id g123-v6so5016181ywf.13 for ; Mon, 25 Jun 2018 15:35:55 -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=xYEbe008VrJdwYdW4UOYZf/SbvbAtZWqvecgZQ5B2b8=; b=SNQfvF3ozAmNRn6wlqli4xpbGTu9CEcfTYbhBNBkcZUDeYHMZHGsCqYGEKgBNRv2KR G5u3mWTLMkBmE+XzruZh6UPbMDH0knlKUyKCRblSmcuJ32RuKvPK6Vgz61SpEUQu10VN ybKKHCXAQIjtqpfnmhmBO1197S46IbhZA0IbQA8vOTto7v9RDDbc26ftDFEn0TMzrNE0 qp6ZvWVz0NtAiEzvPtpFKXObl3eNmxr84miAShhzg16zhdaI37jZhNETk5LGv1k7+9z1 V7gF69TUZYqQS33pAHx5jSWHQN9tgJdDIxTMd4I6umaTMpkHWiHYTSFy8jx176tVv1J6 R0vA== 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=xYEbe008VrJdwYdW4UOYZf/SbvbAtZWqvecgZQ5B2b8=; b=GK1frj3wa53jRIHBv8BTEF/Ld3PrAxIKvHai/uuY0ivleF8iZk7KmlrIpXUM3m9Vha SZrqi9gmg3YgWj0VbJgIiG5CiqwhDYjPG44W9VNL3hjej+IyVf/kBq4G0o0ZrJJ37c8n CHYGsutIh3K1Ph1XbcgLGDQNUEZow1+UktEFE= 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=xYEbe008VrJdwYdW4UOYZf/SbvbAtZWqvecgZQ5B2b8=; b=XdIbTbvoqOPv1EjEVkMLjD3mE6iFS8AoFtuKOTvSuIeqcwqVb4WxNeI8ozotuFZBqn 06A+9w3asps9yXkxeU9CeHHoDbjqa7JJ/yX8kwFBC66X/+CxI7REF9SCZFE8LmMX6kOI sPz1v7QyzUM7zOqKVBHPPqQp3gzky8CdPgxOweg7D67WW4OcsN9uwur8x1MgjDXJ1VI6 E1gwYB+9SlfNL+svkzlXd9CgmsWTTegY5lH6hIybX2ND8Y7b35uokjaHtHk0/JYGg2la emrZNw++tht4hIs9al+ukF/md3ZkVsbkBfj1zHpTW0tgDYIjqDaRAHGUusJQPk0Rwncl fs7w== X-Gm-Message-State: APt69E3qSjLx9zxSHmG1uJSx1txhERJFiDSmJsLKeY215g1Ytk7CJX1k FKhyKtiuVmI9B3XnpebQjMUedM/5KE8uDvGIRTzvWfBQw/U= X-Received: by 2002:a81:4a05:: with SMTP id x5-v6mr6921741ywa.116.1529966154877; Mon, 25 Jun 2018 15:35:54 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a25:5f51:0:0:0:0:0 with HTTP; Mon, 25 Jun 2018 15:35:54 -0700 (PDT) In-Reply-To: <2e4d9686-835c-f4be-2647-2344899e3cd4@redhat.com> References: <1529939300-27461-1-git-send-email-crecklin@redhat.com> <2e4d9686-835c-f4be-2647-2344899e3cd4@redhat.com> From: Kees Cook Date: Mon, 25 Jun 2018 15:35:54 -0700 X-Google-Sender-Auth: LOq0IiPjy6dWhPNOko9oDcJiEKo Message-ID: Subject: Re: [PATCH] add param that allows bootline control of hardened usercopy To: Chris von Recklinghausen Cc: Laura Abbott , LKML , Linux-MM 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 Mon, Jun 25, 2018 at 3:29 PM, Christoph von Recklinghausen wrote: > I have a small set of customers that want CONFIG_HARDENED_USERCOPY > enabled, and a large number of customers who would be impacted by its > default behavior (before my change). The desire was to have the smaller > number of users need to change their boot lines to get the behavior they > wanted. Adding CONFIG_HUC_DEFAULT_OFF was an attempt to preserve the > default behavior of existing users of CONFIG_HARDENED_USERCOPY (default > enabled) and allowing that to coexist with the desires of the greater > number of my customers (default disabled). > > If folks think that it's better to have it enabled by default and the > command line option to turn it off I can do that (it is simpler). Does > anyone else have opinions one way or the other? I would prefer to isolate the actual problem case, and fix it if possible. (i.e. try to make the copy fixed-length, etc) Barring that, yes, a kernel command line to disable the protection would be okay. Note that the test needs to be inside __check_object_size() otherwise the inline optimization with __builtin_constant_p() gets broken and makes everyone slower. :) -Kees -- Kees Cook Pixel Security