All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: xen-devel@lists.xenproject.org
Cc: Ross Lagerwall <ross.lagerwall@citrix.com>
Subject: Re: [PATCH v4 3/4] livepatch: refuse to resolve symbols that belong to init sections
Date: Thu, 25 Apr 2024 13:46:38 +0200	[thread overview]
Message-ID: <ZipCnpooVKrRcYbY@macbook> (raw)
In-Reply-To: <20240424081957.34326-4-roger.pau@citrix.com>

On Wed, Apr 24, 2024 at 10:19:56AM +0200, Roger Pau Monne wrote:
> Livepatch payloads containing symbols that belong to init sections can only
> lead to page faults later on, as by the time the livepatch is loaded init
> sections have already been freed.
> 
> Refuse to resolve such symbols and return an error instead.
> 
> Note such resolutions are only relevant for symbols that point to undefined
> sections (SHN_UNDEF), as that implies the symbol is not in the current payload
> and hence must either be a Xen or a different livepatch payload symbol.
> 
> Do not allow to resolve symbols that point to __init_begin, as that address is
> also unmapped.  On the other hand, __init_end is not unmapped, and hence allow
> resolutions against it.
> 
> Since __init_begin can alias other symbols (like _erodata for example)
> allow the force flag to override the check and resolve the symbol anyway.

I've been thinking more about this, and it has further corner cases,
for example with this patch applied attempting to livepatch a function
that contains a rune like:

if ( system_state < SYS_STATE_active )
    call_init_function();

Will now fail as Xen will refuse to resolve the call_init_function
symbol.

I however don't have any better ideas about how to solve this.  Maybe
it's fine to require such patches to use the --force option, as
refusing to resolve init symbols adds a bit more safety to
livepatches.

Thanks, Roger.


  reply	other threads:[~2024-04-25 11:47 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-24  8:19 [PATCH v4 0/4] livepatch: minor bug fixes and improvements Roger Pau Monne
2024-04-24  8:19 ` [PATCH v4 1/4] xen-livepatch: fix parameter name parsing Roger Pau Monne
2024-04-24 15:29   ` Anthony PERARD
2024-04-25 14:33   ` Ross Lagerwall
2024-04-24  8:19 ` [PATCH v4 2/4] livepatch: introduce --force option Roger Pau Monne
2024-04-26  6:41   ` Jan Beulich
2024-04-26  7:15     ` Roger Pau Monné
2024-04-24  8:19 ` [PATCH v4 3/4] livepatch: refuse to resolve symbols that belong to init sections Roger Pau Monne
2024-04-25 11:46   ` Roger Pau Monné [this message]
2024-04-24  8:19 ` [PATCH v4 4/4] x86/livepatch: perform sanity checks on the payload exception table contents Roger Pau Monne

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=ZipCnpooVKrRcYbY@macbook \
    --to=roger.pau@citrix.com \
    --cc=ross.lagerwall@citrix.com \
    --cc=xen-devel@lists.xenproject.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.