public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Richard Earnshaw <rearnsha@arm.com>
To: libc-alpha@sourceware.org
Cc: Richard Earnshaw <rearnsha@arm.com>,
	dj@redhat.com, szabolcs.nagy@arm.com
Subject: [PATCH v4 2/6] elf: Add a tunable to control use of tagged memory
Date: Fri, 18 Dec 2020 19:29:53 +0000	[thread overview]
Message-ID: <20201218192957.11035-3-rearnsha@arm.com> (raw)
In-Reply-To: <20201218192957.11035-1-rearnsha@arm.com>

[-- Attachment #1: Type: text/plain, Size: 539 bytes --]


Add a new glibc tunable: mem.tagging.  This is a decimal constant in
the range 0-255 but used as a bit-field.

Bit 0 enables use of tagged memory in the malloc family of functions.
Bit 1 enables precise faulting of tag failure on platforms where this
can be controlled.
Other bits are currently unused, but if set will cause memory tag
checking for the current process to be enabled in the kernel.
---
 elf/dl-tunables.list |  9 +++++++++
 manual/tunables.texi | 35 +++++++++++++++++++++++++++++++++++
 2 files changed, 44 insertions(+)


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: v4-0002-elf-Add-a-tunable-to-control-use-of-tagged-memory.patch --]
[-- Type: text/x-patch; name="v4-0002-elf-Add-a-tunable-to-control-use-of-tagged-memory.patch", Size: 2114 bytes --]

diff --git a/elf/dl-tunables.list b/elf/dl-tunables.list
index e1d8225128..4c44ead715 100644
--- a/elf/dl-tunables.list
+++ b/elf/dl-tunables.list
@@ -141,4 +141,13 @@ glibc {
       default: 512
     }
   }
+
+  mem {
+    tagging {
+      type: INT_32
+      minval: 0
+      maxval: 255
+      security_level: SXID_IGNORE
+    }
+  }
 }
diff --git a/manual/tunables.texi b/manual/tunables.texi
index d72d7a5ec0..1bbdc88281 100644
--- a/manual/tunables.texi
+++ b/manual/tunables.texi
@@ -36,6 +36,8 @@ their own namespace.
 * POSIX Thread Tunables:: Tunables in the POSIX thread subsystem
 * Hardware Capability Tunables::  Tunables that modify the hardware
 				  capabilities seen by @theglibc{}
+* Memory Related Tunables::  Tunables that control the use of memory by
+			     @theglibc{}.
 @end menu
 
 @node Tunable names
@@ -484,3 +486,36 @@ instead.
 
 This tunable is specific to i386 and x86-64.
 @end deftp
+
+@node Memory Related Tunables
+@section Memory Related Tunables
+@cindex memory related tunables
+
+@deftp {Tunable namespace} glibc.mem
+This tunable namespace supports operations that affect the way @theglibc{}
+and the process manage memory.
+@end deftp
+
+@deftp Tunable glibc.mem.tagging
+If the hardware supports memory tagging, this tunable can be used to
+control the way @theglibc{} uses this feature.  At present this is only
+supported on AArch64 systems with the MTE extention; it is ignored for
+all other systems.
+
+This tunable takes a value between 0 and 255 and acts as a bitmask
+that enables various capabilities.
+
+Bit 0 (the least significant bit) causes the malloc subsystem to allocate
+tagged memory, with each allocation being assigned a random tag.
+
+Bit 1 enables precise faulting mode for tag violations on systems that
+support deferred tag violation reporting.  This may cause programs
+to run more slowly.
+
+Other bits are currently reserved.
+
+@Theglibc{} startup code will automatically enable memory tagging
+support in the kernel if this tunable has any non-zero value.
+
+The default value is @samp{0}, which disables all memory tagging.
+@end deftp

  parent reply	other threads:[~2020-12-18 19:30 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-18 19:29 [PATCH v4 0/6] Memory tagging support Richard Earnshaw
2020-12-18 19:29 ` [PATCH v4 1/6] config: Allow memory tagging to be enabled when configuring glibc Richard Earnshaw
2020-12-21 12:40   ` Siddhesh Poyarekar
2020-12-18 19:29 ` Richard Earnshaw [this message]
2020-12-21 12:42   ` [PATCH v4 2/6] elf: Add a tunable to control use of tagged memory Siddhesh Poyarekar
2020-12-18 19:29 ` [PATCH v4 3/6] malloc: Basic support for memory tagging in the malloc() family Richard Earnshaw
2020-12-21 13:27   ` Siddhesh Poyarekar
2020-12-21 13:46   ` Florian Weimer
2020-12-21 14:31     ` Richard Earnshaw
2020-12-21 14:31     ` Szabolcs Nagy
2020-12-18 19:29 ` [PATCH v4 4/6] linux: Add compatibility definitions to sys/prctl.h for MTE Richard Earnshaw
2020-12-21 13:32   ` Siddhesh Poyarekar
2020-12-21 13:34     ` Richard Earnshaw
2020-12-21 13:38       ` Siddhesh Poyarekar
2020-12-21 13:39     ` Florian Weimer
2020-12-21 13:41       ` Siddhesh Poyarekar
2020-12-18 19:29 ` [PATCH v4 5/6] aarch64: Add sysv specific enabling code for memory tagging Richard Earnshaw
2020-12-21 12:27   ` Szabolcs Nagy
2020-12-21 13:36   ` Siddhesh Poyarekar
2020-12-18 19:29 ` [PATCH v4 6/6] aarch64: Add aarch64-specific files for memory tagging support Richard Earnshaw
2020-12-21 12:44   ` Szabolcs Nagy
2020-12-21 12:50     ` Richard Earnshaw
2020-12-18 20:18 ` [PATCH v4 0/6] Memory " H.J. Lu
2020-12-21 12:28 ` Siddhesh Poyarekar
2020-12-21 13:44   ` Siddhesh Poyarekar

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=20201218192957.11035-3-rearnsha@arm.com \
    --to=rearnsha@arm.com \
    --cc=dj@redhat.com \
    --cc=libc-alpha@sourceware.org \
    --cc=szabolcs.nagy@arm.com \
    /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).