public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: Mike Hommey <mh@glandium.org>
Cc: Adhemerval Zanella <adhemerval.zanella@linaro.org>,
	libc-alpha@sourceware.org
Subject: Re: [RFC 3/5] elf: Add support to memory sealing
Date: Fri, 28 Jun 2024 07:51:05 +0200	[thread overview]
Message-ID: <87a5j5ehti.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <20240627230004.voprvs2ddrdep27k@glandium.org> (Mike Hommey's message of "Fri, 28 Jun 2024 08:00:04 +0900")

* Mike Hommey:

> I just realized this can't work. For some reason I had the impression
> the mseal was applied to the RELRO segment, but it's over the entire
> library, which makes sense, in hindsight. The problem is that if we
> remove RELRO, then... we can't even reapply it afterwards because of the
> mseal, leaving us with a writable data section.
> But if we disable mseal, we only get to disable it for everything, not
> only our libs! (and only if we re-exec with GLIBC_TUNABLES set?)

We can introduce a flag in a dynamic tag at the same time we implement
mseal.  The flag would isntruct the dynamic linker to skip mseal.  It's
going to be some time until link editors know about the flag, but that
doesn't matter in your case because you have a custom linker anyway,
more or less.

Thanks,
Florian


  reply	other threads:[~2024-06-28  5:51 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-11 15:27 [RFC 0/5] Add support for " Adhemerval Zanella
2024-06-11 15:27 ` [RFC 1/5] linux: Remove __stack_prot Adhemerval Zanella
2024-06-11 19:15   ` Florian Weimer
2024-06-11 15:27 ` [RFC 2/5] linux: Add mseal syscall support Adhemerval Zanella
2024-06-11 15:27 ` [RFC 3/5] elf: Add support to memory sealing Adhemerval Zanella
2024-06-11 20:47   ` Jonathan Corbet
2024-06-11 21:03     ` Adhemerval Zanella
2024-06-21  5:09   ` Mike Hommey
2024-06-25 21:07     ` Adhemerval Zanella Netto
2024-06-25 23:18       ` Mike Hommey
2024-06-26 11:58         ` Adhemerval Zanella Netto
2024-06-26 19:58           ` Mike Hommey
2024-06-26 21:20             ` Adhemerval Zanella Netto
2024-06-26 21:39               ` Mike Hommey
2024-06-26 21:56                 ` Adhemerval Zanella Netto
2024-06-27 23:00     ` Mike Hommey
2024-06-28  5:51       ` Florian Weimer [this message]
2024-06-28  5:58         ` Mike Hommey
2024-06-28  6:06           ` Florian Weimer
2024-06-28  7:39             ` Mike Hommey
2024-07-01 21:08               ` Adhemerval Zanella Netto
2024-06-11 15:27 ` [RFC 4/5] elf: Enable RTLD_NODELETE on __libc_unwind_link_get Adhemerval Zanella
2024-06-12  9:54   ` Florian Weimer
2024-06-12 17:16     ` Adhemerval Zanella Netto
2024-06-12 17:50       ` Florian Weimer
2024-06-12 17:55         ` Adhemerval Zanella Netto
2024-06-11 15:27 ` [RFC 5/5] elf: Add support to memory sealing for audit modules Adhemerval Zanella

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=87a5j5ehti.fsf@oldenburg.str.redhat.com \
    --to=fweimer@redhat.com \
    --cc=adhemerval.zanella@linaro.org \
    --cc=libc-alpha@sourceware.org \
    --cc=mh@glandium.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).