All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: David Laight <David.Laight@aculab.com>
Cc: "'Preble, Adam C'" <adam.c.preble@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: How do I force an IBT trap in a demo kernel module?
Date: Sun, 28 May 2023 00:40:35 +0200	[thread overview]
Message-ID: <ZHKG4xQ8vma7lfRQ@localhost> (raw)
In-Reply-To: <82034ea784e44c5b929f519ceac6c4e0@AcuMS.aculab.com>

On Wed 2023-05-24 08:00:36, David Laight wrote:
> From: Preble, Adam C
> > Sent: 23 May 2023 20:29
> > 
> > I am debugging why a kernel module of ours triggers the IBT (Indirect Branch Tracking) trap, and while
> > doing that, I was trying to write a standalone demo that would forcefully trigger it on purpose. This
> > has turned out to be much more difficult than I thought! What can I do to get a module to generate an
> > indirect branch without an endbr64? Creating the indirect branch itself doesn't appear to be hard:
> > 
> > 1. Set up a function call
> > 2. Assign it to a function pointer
> > 3. Call the function pointer
> > 4. ...maybe add a compiler flag so it doesn't optimize the call to a direct branch.
> > 
> > I am primarily building in a Debian environment with gcc (Debian 10.2.1-6) 10.2.1 20210110. By
> > default, the branch does get optimized away. I had to set the -mforce-indirect-call flag. The endbr64
> > instruction would still emit so I added a function attribute to suppress it:
> ...
> > So what do I have to do to tell objtool to allow to me deliberately shoot myself in the foot here?
> 
> You could try adjusting the function pointer by the size of the endbr64 instrauction.
> 
> Oh, put the function pointer variable into static data.
> That should stop it all being optimised away.

volatile will help, too.

Or simply write the code in assembly.
								Pavel

-- 

  reply	other threads:[~2023-05-27 22:40 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-23 19:28 How do I force an IBT trap in a demo kernel module? Preble, Adam C
2023-05-24  8:00 ` David Laight
2023-05-27 22:40   ` Pavel Machek [this message]
2023-05-31 23:02     ` Preble, Adam C
2023-06-01  8:04       ` David Laight

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=ZHKG4xQ8vma7lfRQ@localhost \
    --to=pavel@ucw.cz \
    --cc=David.Laight@aculab.com \
    --cc=adam.c.preble@intel.com \
    --cc=linux-kernel@vger.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.