Message ID | 20240223165942.work.950-kees@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-78768-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:a81b:b0:108:e6aa:91d0 with SMTP id bq27csp727260dyb; Fri, 23 Feb 2024 09:20:47 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCXEgbXUpmaenUtKWsgpSqvBlh2jzHxCnZfXaryB3w03BmCFLCp/ZDwvz2mQnuUTMMt22EzBwcQq50miay33uJywPEJpzg== X-Google-Smtp-Source: AGHT+IESbBK0kWi3juYk4LqWc3o8KtWlojlPcHGd+tqppg4EOTybz2B35utatz6Fea08jKkZBgwx X-Received: by 2002:a05:6a00:6caa:b0:6e3:806f:1ef2 with SMTP id jc42-20020a056a006caa00b006e3806f1ef2mr473510pfb.25.1708708847205; Fri, 23 Feb 2024 09:20:47 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1708708847; cv=pass; d=google.com; s=arc-20160816; b=LybH6KRuM2I8eog+WV9i4xO3EY1quKlux5FWEZ0jLPIPtxBZkFpWEyF/K/NBzFThBi JrXzgivx8ywlD/AXm9+hQlBDGiLEPSk8s6+tntTPlpEvLU/62bQWYxfBMBUsXPlqSokL pQhgIDQGCmfCWTM3L9cUfuxVsK0BRHu35C1ufqGqu2H1wD9kbCFYi+mmZe+D5OzKCHXu XWBdcDYZQu/Ys/O0g+cPJASaAk0+lJdnB5lzQ/9d8zEhha4wdQJkrwN6/fiVa4UpRdIc R0cYU+CpFPZ+hbzX6TK5bX6FnuTTYEMkwu1qtbLSl480RvhYXJENCa+9ASvyFVDZvX9v JhSw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=FDMzDk/lBMFwiZnh7jtuEycU3dW7wec2i4CrQjkGJo4=; fh=iBh9Lv2rDD3hvsUkGKgDnTxnYp74I9X0NBvs67ezjQ4=; b=WhQIKINmq3qYBvWTaK9wZvCfBMU4+uK+L1RwHDZq/Wrqkgt+mRqg6Ofp1P0QLFfv0O D8BfYuuULjxqjyGSwJirhM6+njAXTvybTv2zZUKebxyuG+bBRg1ujw+bq2a2OEZzVDYj d+Z7jizKnBwciw8gEV7FynudDRhQKPTB76bq6Ga0oDyMjhTaX+oglVbr81DKAa34CrlX 4SDRDeyEVZtqvswZ9dow3MQOc7QYgbEzYyfqAJEa/T8+vsSon/2V2HyzhufZVSmrS6kK mTfj65LfJ5jCDYfUxrqI6vALphpwZijWdvjSPuLALSuv1Gf9AGF/cjqoLcEufBqE1HXH E/YA==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=nitAuW0n; arc=pass (i=1 spf=pass spfdomain=chromium.org dkim=pass dkdomain=chromium.org dmarc=pass fromdomain=chromium.org); spf=pass (google.com: domain of linux-kernel+bounces-78768-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-78768-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [2604:1380:40f1:3f00::1]) by mx.google.com with ESMTPS id fd24-20020a056a002e9800b006e0949b2543si12930997pfb.342.2024.02.23.09.20.46 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 23 Feb 2024 09:20:47 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-78768-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=nitAuW0n; arc=pass (i=1 spf=pass spfdomain=chromium.org dkim=pass dkdomain=chromium.org dmarc=pass fromdomain=chromium.org); spf=pass (google.com: domain of linux-kernel+bounces-78768-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-78768-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id 70970B22277 for <ouuuleilei@gmail.com>; Fri, 23 Feb 2024 17:00:06 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id E3F4012B168; Fri, 23 Feb 2024 16:59:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="nitAuW0n" Received: from mail-pf1-f179.google.com (mail-pf1-f179.google.com [209.85.210.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CBAB9128397 for <linux-kernel@vger.kernel.org>; Fri, 23 Feb 2024 16:59:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.179 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708707590; cv=none; b=j/L7fiD+j9CACOO5mFr1GyTdAyTHbs7XzMqcCh38ZDh17XfZVp0cbDAuJuSMx1Guid3mtbQMTsBU/zpYzZMIhSOqPQtpm0K1a94ErL8mRH51kzN8lkK9QukL1qz0MmyuAFSsdztjRYB4s5EQmVP0wfh0/KZsO7r6t3PPzsVT3sk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708707590; c=relaxed/simple; bh=GFnd+uRgcZ5JE6+yaYSUeEigjBZZ5ehiRJbCdQFjMSg=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=ozekoIdvCTY2azSc2/ucZPKKWjmewyAOwP6c0RJ53waWnFutXRPQDkCiOLDFwaCSlFrKzI0IWHG2WQQEyj0eJbtpu3Sl2SFE6rNfnHB6ufIv9muiBoZPo8M9BtqfmFWD2l7Y7MY+hGpbxM+u0OAljmklIQvWisKF09T5xyJV4W4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org; spf=pass smtp.mailfrom=chromium.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b=nitAuW0n; arc=none smtp.client-ip=209.85.210.179 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=chromium.org Received: by mail-pf1-f179.google.com with SMTP id d2e1a72fcca58-6e4ca46ab04so363461b3a.3 for <linux-kernel@vger.kernel.org>; Fri, 23 Feb 2024 08:59:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1708707588; x=1709312388; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=FDMzDk/lBMFwiZnh7jtuEycU3dW7wec2i4CrQjkGJo4=; b=nitAuW0nEJXqcuwrvok8CkVkbfn2pnfOCTGqhqgni0qOUhvTAhltyrpkmRwSRrbh0B 98mW8FxQhTkRddbNuvjY1OlR4EehYdeL0eARCJG8gW0y3gsHiuUVmVyOiDl/jLh1TF5D j58bfHK882zi2L5G6JAhTPLzgzIjkBqHE0PuQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708707588; x=1709312388; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=FDMzDk/lBMFwiZnh7jtuEycU3dW7wec2i4CrQjkGJo4=; b=evv99R0qFf5590B6m7HlF2L8yvJIqLPNzOphe7lyp1BKAsUKuRLvtIYei9UWOa3e0a DlRbCTtrsPoVk22VLe0TNpvY17uj79Ta49NV72UKsObXcW2c66Wog8FjTWuUgxfQO59V 7ljc18t8xwf+CS5x736ZIPDVYv/zghGeE4u19svlJ2RL4gulPexsfb1Gcuc0pRRP3jFO fJ+WMiLAr+WhcvegbkYIXTEaNYsd76ntRwO2YyrzIQAF4A4oA9EZ6yBDovMfzfJ42ABR gC96UAPdb15EcZLmBMpuXVk4EobqfdFU2F5I0C+alVz1s3DnndAN6bUwJavA1qaeQA2I g5Jg== X-Forwarded-Encrypted: i=1; AJvYcCXqHc2CeWiGX+skA72TRQ19pdYX5vf4uG3iAtgMghtd+fsYBW+D4hv9zAerxxGGMTophApGVQTm0ONmglNe+BCOzIHUKaQk4FBbi+8M X-Gm-Message-State: AOJu0YzAc3Q8JiJJTtRO/zeiCoxqrthbxcRq0ct+1riGgELEKQCS9P6H yGKLrDmBPU/iGxk7LKR2W9A26kI/Zf8l9b4PBCMBIgjOTcPME+P1N7nkSgrAzA== X-Received: by 2002:aa7:9d82:0:b0:6e3:636b:dd99 with SMTP id f2-20020aa79d82000000b006e3636bdd99mr331864pfq.24.1708707588228; Fri, 23 Feb 2024 08:59:48 -0800 (PST) Received: from www.outflux.net ([198.0.35.241]) by smtp.gmail.com with ESMTPSA id o74-20020a62cd4d000000b006e3f09fd6a7sm11865200pfg.85.2024.02.23.08.59.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 23 Feb 2024 08:59:47 -0800 (PST) From: Kees Cook <keescook@chromium.org> To: "David S. Miller" <davem@davemloft.net> Cc: Kees Cook <keescook@chromium.org>, Andreas Larsson <andreas@gaisler.com>, Masahiro Yamada <masahiroy@kernel.org>, Sam Ravnborg <sam@ravnborg.org>, Helge Deller <deller@gmx.de>, Guo Ren <guoren@kernel.org>, sparclinux@vger.kernel.org, Catalin Marinas <catalin.marinas@arm.com>, "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk>, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org Subject: [PATCH] sparc: vdso: Disable UBSAN instrumentation Date: Fri, 23 Feb 2024 08:59:45 -0800 Message-Id: <20240223165942.work.950-kees@kernel.org> X-Mailer: git-send-email 2.34.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=997; i=keescook@chromium.org; h=from:subject:message-id; bh=GFnd+uRgcZ5JE6+yaYSUeEigjBZZ5ehiRJbCdQFjMSg=; b=owEBbQKS/ZANAwAKAYly9N/cbcAmAcsmYgBl2M8BVTkPTYzeAtIdjSlijqw9uZvhDwrdnLvn9 blIHXwVpeGJAjMEAAEKAB0WIQSlw/aPIp3WD3I+bhOJcvTf3G3AJgUCZdjPAQAKCRCJcvTf3G3A JoCwEACKVFAmUO4no0Qaxq8qbED2OYobHjEx8UJ+OGsvTvGLxdH8D7zH1Jm07MIB5qteNWszAPW mmeZi2C8ojqf8QZCcqjRXQJWlCBUm6nET1lK20B7bHNNenRsAU3f+oq4vdh143ne09ThQL0vycD GkDx6xhb0cdwF/fuoUugrYKfxI242MeUa/lIkLQMoxXyJ+uQvBLKYtshUKKs/AdBkdZ56fsAR6W WK/+Q26n6BKUSxtMnNvhGt+AiOe0ElsbAbAPLSAf/+ACWu34JMXSe6b3o6WbemF7w6zZSFfxx3L aiWCjVpYB49at5XwwkPh4ZiViM11V4RJIIV8Wq2Lj3Wn2SfL+xAfohSXysGvuiAxtXG7wgnWXCl YkaEHux6vs5pt1/gsv6WKr+/UpXZvWQJkqpYBmRJY502AnAbYg00exgRnJoCpHC2bgyAS+cb9Zu YqnvktgImg3XSAhBvOhxXMf/40ggBFstPwm6YOucNM1IdW4aKRktYWll8E0i3M54hNRCm8eREdF 7CUN7Wo3pISsoJ5iWpsP3QdnuKVtUTXyu7XI5CcS33ZzxMMFpWTwMH1yZcEwM7e5+h4a4tSFsuK jSEdGEu1KEwGh3gepDThUCJTuVkHMRQLz80mbbn4/SrwStrx23fql2KEfgBMP0h30pfMsV78289 Q67U30eW 2zupgVA== X-Developer-Key: i=keescook@chromium.org; a=openpgp; fpr=A5C3F68F229DD60F723E6E138972F4DFDC6DC026 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1791711088348920574 X-GMAIL-MSGID: 1791711088348920574 |
Series |
sparc: vdso: Disable UBSAN instrumentation
|
|
Commit Message
Kees Cook
Feb. 23, 2024, 4:59 p.m. UTC
The UBSAN instrumentation cannot work in the vDSO since it is executing
in userspace, so disable it in the Makefile. Fixes the build failures
such as:
arch/sparc/vdso/vclock_gettime.c:217: undefined reference to `__ubsan_handle_shift_out_of_bounds'
Signed-off-by: Kees Cook <keescook@chromium.org>
---
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Andreas Larsson <andreas@gaisler.com>
Cc: Masahiro Yamada <masahiroy@kernel.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Helge Deller <deller@gmx.de>
Cc: Guo Ren <guoren@kernel.org>
Cc: sparclinux@vger.kernel.org
---
arch/sparc/vdso/Makefile | 1 +
1 file changed, 1 insertion(+)
Comments
Hi Kees, On Fri, Feb 23, 2024 at 08:59:45AM -0800, Kees Cook wrote: > The UBSAN instrumentation cannot work in the vDSO since it is executing > in userspace, so disable it in the Makefile. Fixes the build failures > such as: > > arch/sparc/vdso/vclock_gettime.c:217: undefined reference to `__ubsan_handle_shift_out_of_bounds' > > Signed-off-by: Kees Cook <keescook@chromium.org> > --- > Cc: "David S. Miller" <davem@davemloft.net> > Cc: Andreas Larsson <andreas@gaisler.com> > Cc: Masahiro Yamada <masahiroy@kernel.org> > Cc: Sam Ravnborg <sam@ravnborg.org> > Cc: Helge Deller <deller@gmx.de> > Cc: Guo Ren <guoren@kernel.org> > Cc: sparclinux@vger.kernel.org > --- > arch/sparc/vdso/Makefile | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/sparc/vdso/Makefile b/arch/sparc/vdso/Makefile > index 7f5eedf1f5e0..e8aef2c8ae99 100644 > --- a/arch/sparc/vdso/Makefile > +++ b/arch/sparc/vdso/Makefile > @@ -2,6 +2,7 @@ > # > # Building vDSO images for sparc. > # > +UBSAN_SANITIZE := n When I read: config UBSAN_SANITIZE_ALL bool "Enable instrumentation for the entire kernel" depends on ARCH_HAS_UBSAN_SANITIZE_ALL default y help This option activates instrumentation for the entire kernel. If you don't enable this option, you have to explicitly specify UBSAN_SANITIZE := y for the files/directories you want to check for UB. Enabling this option will get kernel image size increased significantly. I am left with the understanding that only arch's that selects ARCH_HAS_UBSAN_SANITIZE_ALL would need to turn off UBSAN_SANITIZE. Are this fix papering over some other bug where we enable UBSAN_SANITIZE_ALL for arch's that should not have it, or something else that enable it? Sam
On Fri, Feb 23, 2024 at 07:26:46PM +0100, Sam Ravnborg wrote: > Hi Kees, > > On Fri, Feb 23, 2024 at 08:59:45AM -0800, Kees Cook wrote: > > The UBSAN instrumentation cannot work in the vDSO since it is executing > > in userspace, so disable it in the Makefile. Fixes the build failures > > such as: > > > > arch/sparc/vdso/vclock_gettime.c:217: undefined reference to `__ubsan_handle_shift_out_of_bounds' > > > > Signed-off-by: Kees Cook <keescook@chromium.org> > > --- > > Cc: "David S. Miller" <davem@davemloft.net> > > Cc: Andreas Larsson <andreas@gaisler.com> > > Cc: Masahiro Yamada <masahiroy@kernel.org> > > Cc: Sam Ravnborg <sam@ravnborg.org> > > Cc: Helge Deller <deller@gmx.de> > > Cc: Guo Ren <guoren@kernel.org> > > Cc: sparclinux@vger.kernel.org > > --- > > arch/sparc/vdso/Makefile | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/arch/sparc/vdso/Makefile b/arch/sparc/vdso/Makefile > > index 7f5eedf1f5e0..e8aef2c8ae99 100644 > > --- a/arch/sparc/vdso/Makefile > > +++ b/arch/sparc/vdso/Makefile > > @@ -2,6 +2,7 @@ > > # > > # Building vDSO images for sparc. > > # > > +UBSAN_SANITIZE := n > > When I read: > > config UBSAN_SANITIZE_ALL > bool "Enable instrumentation for the entire kernel" > depends on ARCH_HAS_UBSAN_SANITIZE_ALL > default y > help > This option activates instrumentation for the entire kernel. > If you don't enable this option, you have to explicitly specify > UBSAN_SANITIZE := y for the files/directories you want to check for UB. > Enabling this option will get kernel image size increased > significantly. > > > I am left with the understanding that only arch's that > selects ARCH_HAS_UBSAN_SANITIZE_ALL would need to turn off > UBSAN_SANITIZE. Ah, right. So, I removed[1] UBSAN_SANITIZE_ALL in -next (it was the only sanitizer using this logic) and this appears to be one of the impacts. :) I sent similar fixes for sh[2] and LoongArch[3]. > Are this fix papering over some other bug where we enable > UBSAN_SANITIZE_ALL for arch's that should not have it, > or something else that enable it? It's possible we should implement HAVE_ARCH_UBSAN, but in my testing everything built fine with it, so I didn't opt to do that (it looked like just additional configs for no real benefit). What do you think? -Kees [1] https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/commit/?h=for-next/kspp&id=918327e9b7ffb45321cbb4b9b86b58ec555fe6b3 [2] https://lore.kernel.org/lkml/20240130232717.work.088-kees@kernel.org/ [3] https://lore.kernel.org/lkml/20240130233140.work.887-kees@kernel.org/
Hi Kees, On Fri, Feb 23, 2024 at 03:32:37PM -0800, Kees Cook wrote: > On Fri, Feb 23, 2024 at 07:26:46PM +0100, Sam Ravnborg wrote: > > Hi Kees, > > > > On Fri, Feb 23, 2024 at 08:59:45AM -0800, Kees Cook wrote: > > > The UBSAN instrumentation cannot work in the vDSO since it is executing > > > in userspace, so disable it in the Makefile. Fixes the build failures > > > such as: > > > > > > arch/sparc/vdso/vclock_gettime.c:217: undefined reference to `__ubsan_handle_shift_out_of_bounds' > > > > > > Signed-off-by: Kees Cook <keescook@chromium.org> > > > --- > > > Cc: "David S. Miller" <davem@davemloft.net> > > > Cc: Andreas Larsson <andreas@gaisler.com> > > > Cc: Masahiro Yamada <masahiroy@kernel.org> > > > Cc: Sam Ravnborg <sam@ravnborg.org> > > > Cc: Helge Deller <deller@gmx.de> > > > Cc: Guo Ren <guoren@kernel.org> > > > Cc: sparclinux@vger.kernel.org > > > --- > > > arch/sparc/vdso/Makefile | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/arch/sparc/vdso/Makefile b/arch/sparc/vdso/Makefile > > > index 7f5eedf1f5e0..e8aef2c8ae99 100644 > > > --- a/arch/sparc/vdso/Makefile > > > +++ b/arch/sparc/vdso/Makefile > > > @@ -2,6 +2,7 @@ > > > # > > > # Building vDSO images for sparc. > > > # > > > +UBSAN_SANITIZE := n > > > > When I read: > > > > config UBSAN_SANITIZE_ALL > > bool "Enable instrumentation for the entire kernel" > > depends on ARCH_HAS_UBSAN_SANITIZE_ALL > > default y > > help > > This option activates instrumentation for the entire kernel. > > If you don't enable this option, you have to explicitly specify > > UBSAN_SANITIZE := y for the files/directories you want to check for UB. > > Enabling this option will get kernel image size increased > > significantly. > > > > > > I am left with the understanding that only arch's that > > selects ARCH_HAS_UBSAN_SANITIZE_ALL would need to turn off > > UBSAN_SANITIZE. > > Ah, right. So, I removed[1] UBSAN_SANITIZE_ALL in -next (it was the only > sanitizer using this logic) and this appears to be one of the impacts. :) > I sent similar fixes for sh[2] and LoongArch[3]. > > > Are this fix papering over some other bug where we enable > > UBSAN_SANITIZE_ALL for arch's that should not have it, > > or something else that enable it? > > It's possible we should implement HAVE_ARCH_UBSAN, but in my testing > everything built fine with it, so I didn't opt to do that (it looked > like just additional configs for no real benefit). What do you think? Coffee has not yet kicked in, but... > [1] https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/commit/?h=for-next/kspp&id=918327e9b7ffb45321cbb4b9b86b58ec555fe6b3 OK, I did not have this patch in my tree so it explain the need for the patch in this mail. Looking at the linked patch the ARCH_HAS_UBSAN symbol is selected by some architecture but I see no use of it. Maybe that is a later patch and then all is good. In general I am not fan of naked config symbols (no help / comment) like this: config ARCH_HAS_UBSAN bool The reader is left only with the symbol name trying to understand the purpose of a symbol that is selected by some architectures. But that is a different matter for another day. As you now put the patch in this mail in context it makes sense and it has my: Acked-by: Sam Ravnborg <sam@ravnborg.org> Sam
On Fri, Feb 23, 2024 at 08:59:45AM -0800, Kees Cook wrote: > The UBSAN instrumentation cannot work in the vDSO since it is executing > in userspace, so disable it in the Makefile. Fixes the build failures > such as: > > arch/sparc/vdso/vclock_gettime.c:217: undefined reference to `__ubsan_handle_shift_out_of_bounds' > > Signed-off-by: Kees Cook <keescook@chromium.org> > --- > Cc: "David S. Miller" <davem@davemloft.net> > Cc: Andreas Larsson <andreas@gaisler.com> > Cc: Masahiro Yamada <masahiroy@kernel.org> > Cc: Sam Ravnborg <sam@ravnborg.org> > Cc: Helge Deller <deller@gmx.de> > Cc: Guo Ren <guoren@kernel.org> > Cc: sparclinux@vger.kernel.org I dunno how you applied patches, but these Cc seems to appear in a few commits in your hardening branch. I formatted patch from 9fd54b08040669, checked out the new branch just before this commit and run `git am 0001-...`. I don't see them.
On Thu, Feb 29, 2024 at 10:00:38PM +0200, Andy Shevchenko wrote: > On Fri, Feb 23, 2024 at 08:59:45AM -0800, Kees Cook wrote: > > The UBSAN instrumentation cannot work in the vDSO since it is executing > > in userspace, so disable it in the Makefile. Fixes the build failures > > such as: > > > > arch/sparc/vdso/vclock_gettime.c:217: undefined reference to `__ubsan_handle_shift_out_of_bounds' > > > > Signed-off-by: Kees Cook <keescook@chromium.org> > > --- > > Cc: "David S. Miller" <davem@davemloft.net> > > Cc: Andreas Larsson <andreas@gaisler.com> > > Cc: Masahiro Yamada <masahiroy@kernel.org> > > Cc: Sam Ravnborg <sam@ravnborg.org> > > Cc: Helge Deller <deller@gmx.de> > > Cc: Guo Ren <guoren@kernel.org> > > Cc: sparclinux@vger.kernel.org > > I dunno how you applied patches, but these Cc seems to appear in a few commits > in your hardening branch. > > I formatted patch from 9fd54b08040669, checked out the new branch just before > this commit and run `git am 0001-...`. I don't see them. Ah, hm, yes, I'll need to split up my trees a bit to get the right results. Thanks for pointing that out!
diff --git a/arch/sparc/vdso/Makefile b/arch/sparc/vdso/Makefile index 7f5eedf1f5e0..e8aef2c8ae99 100644 --- a/arch/sparc/vdso/Makefile +++ b/arch/sparc/vdso/Makefile @@ -2,6 +2,7 @@ # # Building vDSO images for sparc. # +UBSAN_SANITIZE := n # files to link into the vdso vobjs-y := vdso-note.o vclock_gettime.o