From: Kees Cook <kees@kernel.org>
To: Andrew Pinski <andrew.pinski@oss.qualcomm.com>
Cc: Qing Zhao <qing.zhao@oracle.com>, Uros Bizjak <ubizjak@gmail.com>,
Joseph Myers <josmyers@redhat.com>,
Richard Biener <rguenther@suse.de>,
Jeff Law <jeffreyalaw@gmail.com>,
Andrew Pinski <pinskia@gmail.com>,
Jakub Jelinek <jakub@redhat.com>,
Martin Uecker <uecker@tugraz.at>,
Peter Zijlstra <peterz@infradead.org>,
Ard Biesheuvel <ardb@kernel.org>, Jan Hubicka <hubicka@ucw.cz>,
Richard Earnshaw <richard.earnshaw@arm.com>,
Richard Sandiford <richard.sandiford@arm.com>,
Marcus Shawcroft <marcus.shawcroft@arm.com>,
Kyrylo Tkachov <kyrylo.tkachov@arm.com>,
Kito Cheng <kito.cheng@gmail.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Andrew Waterman <andrew@sifive.com>,
Jim Wilson <jim.wilson.gcc@gmail.com>,
Dan Li <ashimida.1990@gmail.com>,
Sami Tolvanen <samitolvanen@google.com>,
Ramon de C Valle <rcvalle@google.com>,
Joao Moreira <joao@overdrivepizza.com>,
Nathan Chancellor <nathan@kernel.org>,
Bill Wendling <morbo@google.com>,
"Osterlund, Sebastian" <sebastian.osterlund@intel.com>,
"Constable, Scott D" <scott.d.constable@intel.com>,
gcc-patches@gcc.gnu.org, linux-hardening@vger.kernel.org
Subject: Re: [PATCH v9 1/7] typeinfo: Introduce KCFI typeinfo mangling API
Date: Fri, 12 Dec 2025 17:43:15 -0800 [thread overview]
Message-ID: <202512121741.5583E7D@keescook> (raw)
In-Reply-To: <CALvbMcBYSzi=fb0XmGrgh_aP=rR9H+f-7PbX7cnvTm_T+vZynw@mail.gmail.com>
On Fri, Dec 12, 2025 at 05:29:43PM -0800, Andrew Pinski wrote:
> On Fri, Dec 12, 2025 at 5:24 PM Kees Cook <kees@kernel.org> wrote:
> >
> > On Fri, Dec 12, 2025 at 03:07:51PM -0800, Andrew Pinski wrote:
> > > On Tue, Dec 9, 2025 at 6:27 PM Kees Cook <kees@kernel.org> wrote:
> > > [...]
> > > > +uint32_t
> > > > +typeinfo_get_hash (tree type)
> > > > +{
> > > > + gcc_assert (type != NULL_TREE);
> > > > + uint32_t hash_state = 2166136261U; /* FNV-1a 32-bit offset basis. */
> > > > +
> > > > + mangle_type (type, nullptr, &hash_state);
> > > > + return hash_state;
> > > > +}
> > >
> > > It might make sense to do a few self_test here instead of (in addition
> > > to) having a testcase.
> > > This way the testing is done earlier.
> >
> > I tried to do this back in v2 and could not make it work. See [1] for
> > more details on what I found, but basically I don't have access to the
> > parser itself in the selftests, so I couldn't build end-to-end testing
> > of arbitrary C (testing node types isn't really a sufficient test in my
> > view). I could to basic type tests, but it would be redundant to what
> > I ended up with in dg, and I didn't want to split up the testing.
>
> I am asking for self-tests of the API and not depending on the C
> parser. So generating some FUNCTION_TYPE types and then getting back
> the hash and/or name.
>
> > (testing node types isn't really a sufficient test in my view)
> It might not be a fully sufficient test in itself; it does not mean it
> is NOT a useful test to have. This is why I mentioned in addition to.
> Testing the API outside of the end-to-end testing is a good thing and
> can find bugs early on. GCC does not have enough self-tests really
> and folks don't use it as much as we should.
Okay, yeah, if doing this kind of "manual" construction is viewed as
meaningful, I'll give it a shot to augment the existing tests.
-Kees
--
Kees Cook
next prev parent reply other threads:[~2025-12-13 1:43 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-10 2:20 [PATCH v9 0/7] Introduce Kernel Control Flow Integrity ABI [PR107048] Kees Cook
2025-12-10 2:20 ` [PATCH v9 1/7] typeinfo: Introduce KCFI typeinfo mangling API Kees Cook
2025-12-12 23:07 ` Andrew Pinski
2025-12-13 1:24 ` Kees Cook
2025-12-13 1:29 ` Andrew Pinski
2025-12-13 1:43 ` Kees Cook [this message]
2025-12-10 2:20 ` [PATCH v9 2/7] kcfi: Add core Kernel Control Flow Integrity infrastructure Kees Cook
2025-12-10 4:00 ` Andrew Pinski
2025-12-13 2:30 ` Kees Cook
2025-12-10 2:20 ` [PATCH v9 3/7] kcfi: Add regression test suite Kees Cook
2025-12-10 2:20 ` [PATCH v9 4/7] x86: Add x86_64 Kernel Control Flow Integrity implementation Kees Cook
2025-12-10 2:20 ` [PATCH v9 5/7] aarch64: Add AArch64 " Kees Cook
2025-12-10 3:48 ` Andrew Pinski
2025-12-12 22:47 ` Andrew Pinski
2025-12-13 1:40 ` Kees Cook
2025-12-10 2:20 ` [PATCH v9 6/7] arm: Add ARM 32-bit " Kees Cook
2025-12-10 2:20 ` [PATCH v9 7/7] riscv: Add RISC-V " Kees Cook
2025-12-10 18:55 ` [PATCH v9 0/7] Introduce Kernel Control Flow Integrity ABI [PR107048] Sam James
2025-12-11 0:07 ` Kees Cook
2026-01-01 22:42 ` Andrew Pinski
2026-01-02 3:42 ` Kees Cook
2026-01-09 5:48 ` Andrew Pinski
2026-01-09 18:22 ` Kees Cook
2026-01-09 18:43 ` Jeffrey Law
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=202512121741.5583E7D@keescook \
--to=kees@kernel.org \
--cc=andrew.pinski@oss.qualcomm.com \
--cc=andrew@sifive.com \
--cc=ardb@kernel.org \
--cc=ashimida.1990@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=hubicka@ucw.cz \
--cc=jakub@redhat.com \
--cc=jeffreyalaw@gmail.com \
--cc=jim.wilson.gcc@gmail.com \
--cc=joao@overdrivepizza.com \
--cc=josmyers@redhat.com \
--cc=kito.cheng@gmail.com \
--cc=kyrylo.tkachov@arm.com \
--cc=linux-hardening@vger.kernel.org \
--cc=marcus.shawcroft@arm.com \
--cc=morbo@google.com \
--cc=nathan@kernel.org \
--cc=palmer@dabbelt.com \
--cc=peterz@infradead.org \
--cc=pinskia@gmail.com \
--cc=qing.zhao@oracle.com \
--cc=rcvalle@google.com \
--cc=rguenther@suse.de \
--cc=richard.earnshaw@arm.com \
--cc=richard.sandiford@arm.com \
--cc=samitolvanen@google.com \
--cc=scott.d.constable@intel.com \
--cc=sebastian.osterlund@intel.com \
--cc=ubizjak@gmail.com \
--cc=uecker@tugraz.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox