Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp3200317ybc; Thu, 21 Nov 2019 04:59:53 -0800 (PST) X-Google-Smtp-Source: APXvYqyG82Rl1QPO6ChpRkwl2kENEF4CoKoO6XzHUzul9frA8qvj2XfBjJeF4olsgDlJwKiwT5KL X-Received: by 2002:a17:906:d795:: with SMTP id pj21mr14232574ejb.44.1574341193032; Thu, 21 Nov 2019 04:59:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574341193; cv=none; d=google.com; s=arc-20160816; b=Amp3D7w6cZ2tb1U/lqr1KGkZdCh7kH7L8zrwo88StU+QI/Q80S0RdrAU3i8Uq/uiSo a3arcEPfHrBLqvwLE0zjFKbUF7n4pI0RJ8U6+n2OewJEejDVkjx2boJlPLNhMklAQZnc e0TUBSRDshM7KJfAj/QBaUZpHV8YyeJ74VUlP7Irf5prGUvvNPULzm/fGiqQn4E3/KgC UckUex9r6+YWxJhrfNsTCd6yGgnEND9Q5nyBKK3EofZN2W8Tvk0XiVvGKdVlGusN0yfI qHmI+OA3WC2hXz81qOUNw4BdOOe3mSZ/6KSeMtK0SkDnj3BWyS09nAJm63sRqp66Bz1Y z8DQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=VPFKLImHu5NoSeLCImxI/llSaCN5K5GOt05o/lt/Wio=; b=evEmvfSxDotSSLa70bynTdvySQ4pfMPf5r4GLEJSLZVQvM2qrDu/58ZEEdl/qEqTeO 8MMwbj/mpro/6veQkBo9RKlzq+j+dNL2IzFbYm4gkhkYGodH25QERpbDx880u4u6OhGm fl1tUaHcUpQnLnXndl0aG3eZUcoDhwXccsQculh+vP7OrbAyGHAZGvlzIpi4fGfgrPtC lUJVyobuR3n+yOvmhVHrIlbOJ3xEpkjxcpK2YxQ+wVrRkrMWUPBfohTelob8bJgRl9Dd QVOCyHs4ni3dozHkQYGjNAdYuImfmx/fX6Bn56iBbFwED318H7bhYRJ9QXze0asfl+bx Dq0w== ARC-Authentication-Results: i=1; mx.google.com; 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=virtuozzo.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m15si1581843ejk.320.2019.11.21.04.59.28; Thu, 21 Nov 2019 04:59:53 -0800 (PST) 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; 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=virtuozzo.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726775AbfKUMzA (ORCPT + 99 others); Thu, 21 Nov 2019 07:55:00 -0500 Received: from relay.sw.ru ([185.231.240.75]:51644 "EHLO relay.sw.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726293AbfKUMy7 (ORCPT ); Thu, 21 Nov 2019 07:54:59 -0500 Received: from dhcp-172-16-25-5.sw.ru ([172.16.25.5]) by relay.sw.ru with esmtp (Exim 4.92.3) (envelope-from ) id 1iXlz7-00025W-30; Thu, 21 Nov 2019 15:54:57 +0300 Subject: Re: [PATCH 2/3] ubsan: Split "bounds" checker from other options To: Kees Cook Cc: Elena Petrova , Alexander Potapenko , Dmitry Vyukov , Linus Torvalds , Dan Carpenter , "Gustavo A. R. Silva" , Arnd Bergmann , Ard Biesheuvel , Andrew Morton , kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org, kernel-hardening@lists.openwall.com References: <20191120010636.27368-1-keescook@chromium.org> <20191120010636.27368-3-keescook@chromium.org> From: Andrey Ryabinin Message-ID: <06a84afd-bc97-d2b5-3129-d23473f7acb5@virtuozzo.com> Date: Thu, 21 Nov 2019 15:54:44 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <20191120010636.27368-3-keescook@chromium.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/20/19 4:06 AM, Kees Cook wrote: > In order to do kernel builds with the bounds checker individually > available, introduce CONFIG_UBSAN_BOUNDS, with the remaining options > under CONFIG_UBSAN_MISC. > > For example, using this, we can start to expand the coverage syzkaller is > providing. Right now, all of UBSan is disabled for syzbot builds because > taken as a whole, it is too noisy. This will let us focus on one feature > at a time. > > For the bounds checker specifically, this provides a mechanism to > eliminate an entire class of array overflows with close to zero > performance overhead (I cannot measure a difference). In my (mostly) > defconfig, enabling bounds checking adds ~4200 checks to the kernel. > Performance changes are in the noise, likely due to the branch predictors > optimizing for the non-fail path. > > Some notes on the bounds checker: > > - it does not instrument {mem,str}*()-family functions, it only > instruments direct indexed accesses (e.g. "foo[i]"). Dealing with > the {mem,str}*()-family functions is a work-in-progress around > CONFIG_FORTIFY_SOURCE[1]. > > - it ignores flexible array members, including the very old single > byte (e.g. "int foo[1];") declarations. (Note that GCC's > implementation appears to ignore _all_ trailing arrays, but Clang only > ignores empty, 0, and 1 byte arrays[2].) > > [1] https://github.com/KSPP/linux/issues/6 > [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92589 > > Suggested-by: Elena Petrova > Signed-off-by: Kees Cook Reviewed-by: Andrey Ryabinin