All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <kees@kernel.org>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Jennifer Miller <jmill@asu.edu>,
	Sami Tolvanen <samitolvanen@google.com>,
	Jann Horn <jannh@google.com>,
	Nathan Chancellor <nathan@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	Alexei Starovoitov <ast@kernel.org>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	"Mike Rapoport (Microsoft)" <rppt@kernel.org>,
	Rik van Riel <riel@surriel.com>,
	linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org
Subject: Re: [PATCH] x86/kcfi: Require FRED for FineIBT
Date: Sun, 16 Feb 2025 15:52:40 -0800	[thread overview]
Message-ID: <202502161552.54EA17D@keescook> (raw)
In-Reply-To: <7ae6ee84-b5ae-479b-b963-9e9aefcd3bfa@citrix.com>

On Fri, Feb 14, 2025 at 10:40:28PM +0000, Andrew Cooper wrote:
> On 14/02/2025 9:54 pm, Kees Cook wrote:
> > On Fri, Feb 14, 2025 at 07:39:20PM +0000, Andrew Cooper wrote:
> >> Architecturally, FineIBT without FRED seems to be no improvement over
> >> simple IBT.  (I'd love to find some way of hardening the entrypoints,
> >> but I can't see a robust way of doing so.)
> > If you're just looking at IBT, yes. But kCFI (with or without IBT,
> > but without FineIBT) will do hash checking at the call site, which
> > should make it impossible to reach the entrypoints from an indirect call
> > in the first place, as they have no hash preceding them.
> >
> >> However, micro-architecturally, FineIBT is still far better than simple
> >> IBT for speculation issue, seeing as Intel keep on staunchly refusing to
> >> turn off the indirect predictors by default like AMD do.
> >>
> >> A security conscious user ought to be using FineIBT for this, given a
> >> choice, even if it's not perfect in other regards.
> > A security conscious user should use kCFI without FineIBT. :) But I
> > think we might be thinking about different elements of security. I am
> > focusing on control flow, and I think you're considering speculation?
> 
> True.  The security realist knows they're dammed either way, and gets a
> stiff drink instead.

I don't know how any of our livers survive. :)

-- 
Kees Cook

  reply	other threads:[~2025-02-16 23:52 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-14 19:22 [PATCH] x86/kcfi: Require FRED for FineIBT Kees Cook
2025-02-14 19:39 ` Andrew Cooper
2025-02-14 21:54   ` Kees Cook
2025-02-14 22:40     ` Andrew Cooper
2025-02-16 23:52       ` Kees Cook [this message]
2025-02-21 15:08 ` [tip: x86/cpu] " tip-bot2 for Kees Cook
2025-02-21 19:00   ` Peter Zijlstra
2025-02-21 19:02     ` Peter Zijlstra
2025-02-21 21:15       ` Ingo Molnar

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=202502161552.54EA17D@keescook \
    --to=kees@kernel.org \
    --cc=andrew.cooper3@citrix.com \
    --cc=ast@kernel.org \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=jannh@google.com \
    --cc=jmill@asu.edu \
    --cc=jpoimboe@kernel.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=nathan@kernel.org \
    --cc=peterz@infradead.org \
    --cc=riel@surriel.com \
    --cc=rppt@kernel.org \
    --cc=samitolvanen@google.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.