From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f74.google.com (mail-wr1-f74.google.com [209.85.221.74]) (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 0E0DF10E3 for ; Tue, 9 Dec 2025 00:05:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.74 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765238729; cv=none; b=JHkMZ94sOOd3DaSILXrq12qabsjv8XWfj9z1MaO2g/DVD+twLCS4pmE303spw3XfHdFdBvMgwucaFkvQ/5OPxBZqqYc0byeiNCNcUSFIOZvTbVcxnMygCnqsqyiN734BVEqB6RnAmux5m1A54kTuYPioLwm0Bppd4JjSI0Bvo0s= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765238729; c=relaxed/simple; bh=1XIiRaaPt8/6UYN474hNgkfknQoJfosVer31qlAg4Qo=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=CxH4OB2nuZZQv1arIg/USrLneJjPlxqp97JSqP44ZUf3Dj/zfCmo86mYcHdVc0ZObEE6gFRyKV6/VBgqN6WJHjc1m1iHWguqNA8GN4uJkVz1pMdmUYrxYPMvIWqEAj5Er6zNV3F6Qq9MTqov/nl1Iv8AqC3K0VIqSNCzXvy7tSs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--jackmanb.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=bwvteXeh; arc=none smtp.client-ip=209.85.221.74 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--jackmanb.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="bwvteXeh" Received: by mail-wr1-f74.google.com with SMTP id ffacd0b85a97d-42f9ff2913aso15359f8f.3 for ; Mon, 08 Dec 2025 16:05:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1765238726; x=1765843526; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=aamW1NV6H/hkABqRJX47BwzLA3vkBm1Xi/NkYiS8C9Q=; b=bwvteXehfpmeyp1PVi4/33xbtE0uFA38vLuWF5Tymm0gaI3l9ESRDSwN5jmSAHg/P7 StOUL6kp87oje9YjcO9jbz289p6EGXWXS/OL2+xbSJiL5O8HNfHSRTvMYh2e+UzYd8XF QU9RD0/m8NJJqAniD0yG5hviWZ7fWki8k0OTQXrrxGPuk11bG8HzfAbrYPkZYZ6IYIhB L0TLpWEa+yotO6AcxPlYEI8PXFSikZUVnu70vMiFvht2O5jmHlDGhOBlZe+QwYS2CeDo 7uye2OQtjs7PIIik+GqtNqrRFoxF4rU0CIV9yJr2pAGmjLNOTUuVMps3ycTzIjbRFvfx wESQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765238726; x=1765843526; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=aamW1NV6H/hkABqRJX47BwzLA3vkBm1Xi/NkYiS8C9Q=; b=F1+6x7MTvNQEZvRQWnnVioT7lLvsIrQ7lNI14kolyA94Y0vCI9VU5Aa9Civfg8mQPO 6xC3L+qw2QIbTszJYe31Dcm+W+WfNL9vUlYbXXh5kqErVTHhCtB8GheyI3iJTRPU3Rmw Po2/GuDxS4b+oaP4qd9TqgZMM/m02+1s0Y3UPzE8zU5apBZz1BZNuP09gVyffZvmO3/U TudU5bDeXUMvH26xcYEEV/jz0bdaAnX7YFV43JrgfRESVi1eIEhrIFo3/nLmty01ECe1 sj14xwrE8eiLBCQWN1Ac+bN0tIoWmrhusxSvYTFpm9hUtSUW9wS5V0LS1/1R46Agh/he 7hxA== X-Forwarded-Encrypted: i=1; AJvYcCXppxYhEaaxKnQebGQHZpGdXUA00FYiwD2JjiVivWw3nYQ46FXWF+S4PZkDFwsr9ZkgO7eoW18uPOTkutE=@vger.kernel.org X-Gm-Message-State: AOJu0Yzb0dz0nDXpqwUbiv06RurHvP5s8fEgktbRmec2prL3efMDKoiz khZ7R/rLP33J7ES7a90eqfI6snhhljUC7FUTv8LLlKLTQC8hUCn4Ietri+eD0jS9titX9BpK+pH VtyHo+4v9uIhbRQ== X-Google-Smtp-Source: AGHT+IF6GdzLNHjKIagmL+vLpr2xyE+I/3Eweaer/8Y5xIi4Wm29YdB1MSBZoikNvE075Wuwf7s9clcUkinpPA== X-Received: from wmqi18.prod.google.com ([2002:a05:600c:3552:b0:477:76e1:9b4e]) (user=jackmanb job=prod-delivery.src-stubby-dispatcher) by 2002:a05:600c:1e28:b0:477:7a53:f493 with SMTP id 5b1f17b1804b1-47939e38284mr98433785e9.23.1765238726444; Mon, 08 Dec 2025 16:05:26 -0800 (PST) Date: Tue, 09 Dec 2025 00:05:25 +0000 In-Reply-To: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20251208-gcov-inline-noinstr-v1-0-623c48ca5714@google.com> X-Mailer: aerc 0.21.0 Message-ID: Subject: Re: [PATCH 0/2] Noinstr fixes for K[CA]SAN with GCOV From: Brendan Jackman To: Marco Elver , Brendan Jackman Cc: Andrey Ryabinin , Alexander Potapenko , Andrey Konovalov , Dmitry Vyukov , Vincenzo Frascino , Ard Biesheuvel , , Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon Dec 8, 2025 at 11:12 AM UTC, Marco Elver wrote: > On Mon, 8 Dec 2025 at 10:37, Marco Elver wrote: >> >> On Mon, 8 Dec 2025 at 02:35, Brendan Jackman wrote= : >> > >> > Details: >> > >> > - =E2=9D=AF=E2=9D=AF clang --version >> > Debian clang version 19.1.7 (3+build5) >> > Target: x86_64-pc-linux-gnu >> > Thread model: posix >> > InstalledDir: /usr/lib/llvm-19/bin >> > >> > - Kernel config: >> > >> > https://gist.githubusercontent.com/bjackman/bbfdf4ec2e1dfd0e1865717= 4f0537e2c/raw/a88dcc6567d14c69445e7928a7d5dfc23ca9f619/gistfile0.txt >> > >> > Note I also get this error: >> > >> > vmlinux.o: warning: objtool: set_ftrace_ops_ro+0x3b: relocation to !EN= DBR: machine_kexec_prepare+0x810 >> > >> > That one's a total mystery to me. I guess it's better to "fix" the SEV >> > one independently rather than waiting until I know how to fix them bot= h. >> > >> > Note I also mentioned other similar errors in [0]. Those errors don't >> > exist in Linus' master and I didn't note down where I saw them. Either >> > they have since been fixed, or I observed them in Google's internal >> > codebase where they were instroduced downstream. >> > >> > This is a successor to [1] but I haven't called it a v2 because it's a >> > totally different solution. Thanks to Ard for the guidance and >> > corrections. >> > >> > [0] https://lore.kernel.org/all/DERNCQGNRITE.139O331ACPKZ9@google.com/ >> > >> > [1] https://lore.kernel.org/all/20251117-b4-sev-gcov-objtool-v1-1-54f7= 790d54df@google.com/ >> >> Why is [1] not the right solution? >> The problem is we have lots of "inline" functions, and any one of them >> could cause problems in future. > > Perhaps I should qualify: lots of *small* inline functions, including > those stubs. > >> I don't mind turning "inline" into "__always_inline", but it seems >> we're playing whack-a-mole here, and just disabling GCOV entirely >> would make this noinstr.c file more robust. > > To elaborate: `UBSAN_SANITIZE_noinstr.o :=3D n` and > `K{A,C}SAN_SANITIZE_noinstr.o :=3D n` is already set on this file. > Perhaps adding __always_inline to the stub functions here will be > enough today, but might no longer be in future.=20 Well you can also see it the other way around: disabling GCOV_PROFILE might be enough today, but as soon as some other noinstr disables=20 __SANITIZE_ADDRESS__ and expects to be able to call instrumented helpers, that code will be broken too.=20 I don't think we can avoid whack-a-mole here. In fact I think the whole noinstr thing is an inevitable game of whack-a-mole unless we can get a static anlyzer to find violations at the source level. I suspect there are loads of violations in the tree that only show up in objtool if you build in weird configs on a full moon. One argument in favour of `GCOV_PROFILE_noinstr.o :=3D n` would be: "this is non-instrumentable code, the issue here is that it is getting instrumented, so the fix is surely to stop instrumenting it". But, I don't think that's really true, the issue is not with the instrumentation but with the out-of-lining. Which highlights another point: a sufficiently annoying compiler could out-of-line these stub functions even without GCOV, right? Still, despite my long-winded arguments I'm not gonna die on this hill, I would be OK with both ways. > If you look at > , we also have KMSAN. The KMSAN explicit > instrumentation doesn't appear to be invoked on that file today, but > given it shouldn't, we might consider: > > KMSAN_SANITIZE_noinstr.o :=3D n > GCOV_PROFILE_noinstr.o :=3D n This would make sense to me, although as I hinted above I think it's sorta orthogonal and we should __always_inline the k[ca]san stubs regardless. > The alternative is to audit the various sanitizer stub functions, and > mark all these "inline" stub functions as "__always_inline". The > changes made in this series are sufficient for the noinstr.c case, but > not complete. Oh, yeah I should have done __kcsan_{en,di}able_current() too I think. Are there other stubs you are thinking of? I think we only care about the !__SANITIZE_*__ stubs - we don't need this for !CONFIG_* stubs, right? Anything else I'm forgetting?