On Wed, Sep 10, 2025 at 08:05:11PM -0700, Kees Cook wrote:
> > > +/* Check if a function needs KCFI preamble generation.
> > > + ALL functions get preambles when -fsanitize=kcfi is enabled,
> > > regardless
> > > + of no_sanitize("kcfi") attribute. */
> >
> > Why no_sanitize(“kcfi”) is not
On Fri, Sep 05, 2025 at 09:19:29AM -0700, Kees Cook wrote:
> On Fri, Sep 05, 2025 at 10:51:03AM +0200, Peter Zijlstra wrote:
> > On Thu, Sep 04, 2025 at 05:24:10PM -0700, Kees Cook wrote:
> > > +- The check-call instruction sequence must be treated a single unit: it
> > &
On Thu, Sep 04, 2025 at 05:24:10PM -0700, Kees Cook wrote:
> +- The check-call instruction sequence must be treated a single unit: it
> + cannot be rearranged or split or optimized. The pattern is that
> + indirect calls, "call *$target", get converted into:
> +
> +mov $target_expression, %ta
On Wed, Sep 03, 2025 at 09:24:22PM -0700, Kees Cook wrote:
> > If the hacker knows these, it should be quite easy for them to come up with
> > a
> > matched typeid, is it?
>
> The hashes aren't considered secret -- they need to be known/match between
> compilation units, and even across languag
On Fri, Aug 22, 2025 at 03:29:11PM -0700, Kees Cook wrote:
> On Fri, Aug 22, 2025 at 08:29:16PM +, Qing Zhao wrote:
> > > On Aug 22, 2025, at 15:02, Kees Cook wrote:
> > > Right, and sometimes we have to explicitly perform a no-op
> > > address-taking to make sure a symbol gets generated:
> >
On Thu, Aug 21, 2025 at 10:15:31PM -0700, Kees Cook wrote:
> On Thu, Aug 21, 2025 at 06:09:08PM +, Qing Zhao wrote:
> > > On Aug 21, 2025, at 10:25, Peter Zijlstra wrote:
> > > kCFI changes every function to have a preamble like (with IBT and
> > > retpoli
On Fri, Aug 22, 2025 at 01:36:43AM -0700, Kees Cook wrote:
> On Fri, Aug 22, 2025 at 10:19:15AM +0200, Peter Zijlstra wrote:
> > Anyway, I might be able to deal with the indirect call not being r11,
> > but it'll take a bit of prodding. Also it will shatter my plans to move
&g
On Fri, Aug 22, 2025 at 09:51:15AM +0200, Peter Zijlstra wrote:
> On Thu, Aug 21, 2025 at 02:22:30AM -0700, Andrew Pinski wrote:
> > On Thu, Aug 21, 2025, 2:13 AM Peter Zijlstra wrote:
> >
> > > On Thu, Aug 21, 2025 at 01:16:56AM -0700, Andrew Pinski wrote:
> > >
On Thu, Aug 21, 2025 at 11:46:17AM -0700, Kees Cook wrote:
> On Thu, Aug 21, 2025 at 11:29:35AM +0200, Peter Zijlstra wrote:
> > The current kernel FineIBT code hard assumes r11 for now.
>
> Oh, it looked like it wasn't always r11. Does clang force the call
> register t
On Thu, Aug 21, 2025 at 02:22:30AM -0700, Andrew Pinski wrote:
> On Thu, Aug 21, 2025, 2:13 AM Peter Zijlstra wrote:
>
> > On Thu, Aug 21, 2025 at 01:16:56AM -0700, Andrew Pinski wrote:
> >
> > > > +/* Compute KCFI type ID for a function declaration or f
On Thu, Aug 21, 2025 at 01:01:37PM +0200, Richard Biener wrote:
> On Thu, 21 Aug 2025, Peter Zijlstra wrote:
>
> > On Thu, Aug 21, 2025 at 01:16:56AM -0700, Andrew Pinski wrote:
> >
> > > > +/* Compute KCFI type ID for a function declaration or function type
> &g
On Thu, Aug 21, 2025 at 12:26:37AM -0700, Kees Cook wrote:
> Implement x86_64-specific KCFI backend:
>
> - Function preamble generation with type IDs positioned at -(4+prefix_nops)
> offset from function entry point.
>
> - 16-byte alignment of KCFI preambles using calculated prefix NOPs:
> al
On Thu, Aug 21, 2025 at 01:16:56AM -0700, Andrew Pinski wrote:
> > +/* Compute KCFI type ID for a function declaration or function type
> > (internal) */
> > +static uint32_t
> > +compute_kcfi_type_id (tree fntype_or_fndecl)
> > +{
> > + if (!fntype_or_fndecl)
> > +return 0;
> > +
> > + cons
On Sat, Mar 25, 2023 at 01:54:16AM -0700, Dan Li wrote:
> In the compiler part[4], most of the content is the same as Sami's
> implementation[3], except for some minor differences, mainly including:
>
> 1. The function typeid is calculated differently and it is difficult
> to be consistent.
This
On Mon, Nov 15, 2021 at 12:33:16PM +0530, Prathamesh Kulkarni wrote:
> On Sun, 14 Nov 2021 at 02:07, David Malcolm via Gcc-patches
> > +/* Handle "returns_zero_on_failure" and "returns_zero_on_success"
> > attributes;
> > + arguments as in struct attribute_spec.handler. */
> > +
> > +static tr
On Sat, Nov 13, 2021 at 03:37:24PM -0500, David Malcolm wrote:
> This approach is much less expressive that the custom addres space
> approach; it would only cover the trust boundary aspect; it wouldn't
> cover any differences between generic pointers and __user, vs __iomem,
> __percpu, and __rcu
16 matches
Mail list logo
