All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dylan Hatch <dylanbhatch@google.com>
To: misono.tomohiro@fujitsu.com
Cc: broonie@kernel.org, catalin.marinas@arm.com,
	chenzhongjin@huawei.com, jamorris@linux.microsoft.com,
	jpoimboe@redhat.com, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, live-patching@vger.kernel.org,
	madvenka@linux.microsoft.com, mark.rutland@arm.com,
	nobuta.keiya@fujitsu.com, peterz@infradead.org, pmladek@suse.com,
	sjitindarsingh@gmail.com, will@kernel.org
Subject: RE: [RFC PATCH v3 00/22] arm64: livepatch: Use ORC for dynamic frame pointer validation
Date: Mon, 3 Apr 2023 15:26:41 -0700	[thread overview]
Message-ID: <CADBMgpxQ+oM_TrtKRiREcZoZSk=AfenV_bqOk_Vt-Ov5FPHMvw@mail.gmail.com> (raw)

> Then, I noticed that invoke_syscall generates instructions to add random offset
> in sp when RANDOMIZE_KSTACK_OFFSET=y, which is true in the above case.

I'm also seeing this behavior when compiling with
RANDOMIZE_KSTACK_OFFSET=y. I wonder if a special hint type
could/should be added to allow for skipping the reliability check for
stack frames with this randomized offset? Forgive me if this is a
naive suggestion.

Thanks,
Dylan

             reply	other threads:[~2023-04-03 22:26 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-03 22:26 Dylan Hatch [this message]
2023-04-08  3:41 ` [RFC PATCH v3 00/22] arm64: livepatch: Use ORC for dynamic frame pointer validation Madhavan T. Venkataraman
2023-04-08  3:41   ` Madhavan T. Venkataraman
     [not found] <0337266cf19f4c98388e3f6d09f590d9de258dc7>
2023-02-02  7:40 ` madvenka
2023-02-02  7:40   ` madvenka
2023-03-01  3:12   ` Tomohiro Misono (Fujitsu)
2023-03-01  3:12     ` Tomohiro Misono (Fujitsu)
2023-03-02 16:23     ` Petr Mladek
2023-03-02 16:23       ` Petr Mladek
2023-03-03  9:40       ` Tomohiro Misono (Fujitsu)
2023-03-03  9:40         ` Tomohiro Misono (Fujitsu)
2023-03-06 16:58       ` Madhavan T. Venkataraman
2023-03-06 16:58         ` Madhavan T. Venkataraman
2023-03-06 16:57     ` Madhavan T. Venkataraman
2023-03-06 16:57       ` Madhavan T. Venkataraman
2023-03-23 17:17   ` Mark Rutland
2023-03-23 17:17     ` Mark Rutland
2023-04-08  3:40     ` Madhavan T. Venkataraman
2023-04-08  3:40       ` Madhavan T. Venkataraman
2023-04-11 13:25       ` Mark Rutland
2023-04-11 13:25         ` Mark Rutland
2023-04-12  4:17         ` Josh Poimboeuf
2023-04-12  4:17           ` Josh Poimboeuf
2023-04-12  4:48           ` Madhavan T. Venkataraman
2023-04-12  4:48             ` Madhavan T. Venkataraman
2023-04-12  4:50             ` Madhavan T. Venkataraman
2023-04-12  4:50               ` Madhavan T. Venkataraman
2023-04-12  5:01             ` Josh Poimboeuf
2023-04-12  5:01               ` Josh Poimboeuf
2023-04-12 14:50               ` Madhavan T. Venkataraman
2023-04-12 14:50                 ` Madhavan T. Venkataraman
2023-04-12 15:52                 ` Josh Poimboeuf
2023-04-12 15:52                   ` Josh Poimboeuf
2023-04-13 14:59                   ` Madhavan T. Venkataraman
2023-04-13 14:59                     ` Madhavan T. Venkataraman
2023-04-13 16:30                     ` Josh Poimboeuf
2023-04-13 16:30                       ` Josh Poimboeuf
2023-04-15  4:27                       ` Madhavan T. Venkataraman
2023-04-15  4:27                         ` Madhavan T. Venkataraman
2023-04-15  5:05                         ` Josh Poimboeuf
2023-04-15  5:05                           ` Josh Poimboeuf
2023-04-15 16:15                           ` Madhavan T. Venkataraman
2023-04-15 16:15                             ` Madhavan T. Venkataraman
2023-04-16  8:21                       ` Indu Bhagat
2023-04-16  8:21                         ` Indu Bhagat
2023-04-13 17:04     ` Nick Desaulniers
2023-04-13 17:04       ` Nick Desaulniers
2023-04-13 18:15       ` Jose E. Marchesi
2023-04-13 18:15         ` Jose E. Marchesi
2023-04-15  4:14         ` Madhavan T. Venkataraman
2023-04-15  4:14           ` Madhavan T. Venkataraman

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='CADBMgpxQ+oM_TrtKRiREcZoZSk=AfenV_bqOk_Vt-Ov5FPHMvw@mail.gmail.com' \
    --to=dylanbhatch@google.com \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=chenzhongjin@huawei.com \
    --cc=jamorris@linux.microsoft.com \
    --cc=jpoimboe@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=madvenka@linux.microsoft.com \
    --cc=mark.rutland@arm.com \
    --cc=misono.tomohiro@fujitsu.com \
    --cc=nobuta.keiya@fujitsu.com \
    --cc=peterz@infradead.org \
    --cc=pmladek@suse.com \
    --cc=sjitindarsingh@gmail.com \
    --cc=will@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.