linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Theo de Raadt" <deraadt@openbsd.org>
To: Jeff Xu <jeffxu@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Jeff Xu <jeffxu@chromium.org>,
	"Liam R. Howlett" <Liam.Howlett@oracle.com>,
	Jonathan Corbet <corbet@lwn.net>,
	akpm@linux-foundation.org, keescook@chromium.org,
	jannh@google.com, sroettger@google.com, willy@infradead.org,
	gregkh@linuxfoundation.org, usama.anjum@collabora.com,
	rdunlap@infradead.org, jorgelo@chromium.org, groeck@chromium.org,
	linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
	linux-mm@kvack.org, pedro.falcato@gmail.com,
	dave.hansen@intel.com, linux-hardening@vger.kernel.org
Subject: Re: [PATCH v8 0/4] Introduce mseal
Date: Thu, 01 Feb 2024 21:05:10 -0700	[thread overview]
Message-ID: <8744.1706846710@cvs.openbsd.org> (raw)
In-Reply-To: <CALmYWFtqcixi3p3Ab44wENJr+n2k2SNaCJEofNm_awnNdJZnDQ@mail.gmail.com>

Jeff Xu <jeffxu@google.com> wrote:

> To me, the most important thing is to deliver a feature that's easy to
> use and works well. I don't want users to mess things up, so if I'm
> the one giving them the tools, I'm going to make sure they have all
> the information they need and that there are safeguards in place.
> 
> e.g. considering the following user case:
> 1> a security sensitive data is allocated from heap, using malloc,
> from the software component A, and filled with information.
> 2> software component B then uses mprotect to change it to RO, and
> seal it using mseal().

  p = malloc(80);
  mprotect(p & ~4095, 4096, PROT_NONE);
  free(p);

Will you save such a developer also?  No.

Since the same problem you describe already exists with mprotect() what
does mseal() even have to do with your proposal?

What about this?

  p = malloc(80);
  munmap(p & ~4095, 4096);
  free(p);

And since it is not sealed, how about madvise operations on a proper
non-malloc memory allocation?  Well, the process smashes it's own
memory.  And why is it not sealed?  You make it harder to seal memory!

How about this?

  p = malloc(80);
  bzero(p, 100000;

Yes it is a buffer overflow.  But this is all the same class of software
problem:

Memory belongs to processes, which belongs to the program, which is coded
by the programmer, who has to learn to be careful and handle the memory correctly.

mseal() / mimmutable() add *no new expectation* to a careful programmer,
because they expected to only use it on memory that they *promise will never
be de-allocated or re-permissioned*.

What you are proposing is not a "mitigation", it entirely cripples the
proposed subsystem because you are afraid of it; because you have cloned a
memory subsystem primitive you don't fully understand; and this is because
you've not seen a complete operating system using it.

When was the last time you developed outside of Chrome?

This is systems programming.  The kernel supports all the programs, not
just the one holy program from god.


  reply	other threads:[~2024-02-02  4:05 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-31 17:50 jeffxu
2024-01-31 17:50 ` [PATCH v8 1/4] mseal: Wire up mseal syscall jeffxu
2024-01-31 17:50 ` [PATCH v8 2/4] mseal: add " jeffxu
2024-02-01 23:11   ` Eric Biggers
2024-02-02  3:30     ` Jeff Xu
2024-02-02  3:54       ` Theo de Raadt
2024-02-02  4:03         ` Jeff Xu
2024-02-02  4:10           ` Theo de Raadt
2024-02-02  4:22             ` Jeff Xu
2024-01-31 17:50 ` [PATCH v8 3/4] selftest mm/mseal memory sealing jeffxu
2024-01-31 17:50 ` [PATCH v8 4/4] mseal:add documentation jeffxu
     [not found] ` <20240131193411.opisg5yoyxkwoyil@revolver>
     [not found]   ` <CABi2SkXOX4SRMs0y8FYccoj+XrEiPCJk2seqT+sgO7Na7NWwLg@mail.gmail.com>
2024-02-01  1:46     ` [PATCH v8 0/4] Introduce mseal Theo de Raadt
2024-02-01 16:56       ` Bird, Tim
2024-02-01  1:55     ` Theo de Raadt
     [not found]     ` <20240201204512.ht3e33yj77kkxi4q@revolver>
2024-02-01 22:24       ` Theo de Raadt
2024-02-02  1:06         ` Greg KH
2024-02-02  3:24           ` Jeff Xu
2024-02-02  3:29             ` Linus Torvalds
2024-02-02  3:46               ` Jeff Xu
2024-02-02 15:18             ` Greg KH
2024-02-01 22:37       ` Jeff Xu
2024-02-01 22:54         ` Theo de Raadt
2024-02-01 23:15           ` Linus Torvalds
2024-02-01 23:43             ` Theo de Raadt
2024-02-02  0:26             ` Theo de Raadt
2024-02-02  3:20             ` Jeff Xu
2024-02-02  4:05               ` Theo de Raadt [this message]
2024-02-02  4:54                 ` Jeff Xu
2024-02-02  5:00                   ` Theo de Raadt
2024-02-02 17:58                     ` Jeff Xu
2024-02-02 18:51                       ` Pedro Falcato
2024-02-02 21:20                         ` Jeff Xu
2024-02-04 19:39                         ` David Laight
2024-02-02 17:05             ` Theo de Raadt
2024-02-02 21:02               ` Jeff Xu
2024-02-02  3:14       ` Jeff Xu
2024-02-02 15:13         ` Liam R. Howlett
2024-02-02 17:24           ` Jeff Xu
2024-02-02 19:21             ` Liam R. Howlett
2024-02-02 19:32               ` Theo de Raadt
2024-02-02 20:36                 ` Linus Torvalds
2024-02-02 20:57                   ` Jeff Xu
2024-02-02 21:18                   ` Liam R. Howlett
2024-02-02 23:36                     ` Linus Torvalds
2024-02-03  4:45                       ` Liam R. Howlett
2024-02-05 22:13                         ` Suren Baghdasaryan
2024-02-02 20:14               ` Jeff Xu

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=8744.1706846710@cvs.openbsd.org \
    --to=deraadt@openbsd.org \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=corbet@lwn.net \
    --cc=dave.hansen@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=groeck@chromium.org \
    --cc=jannh@google.com \
    --cc=jeffxu@chromium.org \
    --cc=jeffxu@google.com \
    --cc=jorgelo@chromium.org \
    --cc=keescook@chromium.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=pedro.falcato@gmail.com \
    --cc=rdunlap@infradead.org \
    --cc=sroettger@google.com \
    --cc=torvalds@linux-foundation.org \
    --cc=usama.anjum@collabora.com \
    --cc=willy@infradead.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