All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alejandro Colomar <alx.manpages@gmail.com>
To: rppt@kernel.org, mtk.manpages@gmail.com
Cc: Mike Rapoport <rppt@linux.ibm.com>,
	akpm@linux-foundation.org, arnd@arndb.de, bp@alien8.de,
	catalin.marinas@arm.com, cl@linux.com, colomar.6.4.3@gmail.com,
	dave.hansen@linux.intel.com, david@redhat.com,
	elena.reshetova@intel.com, hpa@zytor.com, idan.yaniv@ibm.com,
	jejb@linux.ibm.com, kirill@shutemov.name,
	linux-api@vger.kernel.org, linux-arch@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-kselftest@vger.kernel.org, linux-man@vger.kernel.org,
	linux-mm@kvack.org, linux-nvdimm@lists.01.org,
	linux-riscv@lists.infradead.org, luto@kernel.org,
	mark.rutland@arm.com, mingo@redhat.com, palmer@dabbelt.com,
	paul.walmsley@sifive.com, peterz@infradead.org, shuah@kernel.org,
	tglx@linutronix.de, tycho@tycho.ws, viro@zeniv.linux.org.uk,
	will@kernel.org, willy@infradead.org, x86@kernel.org,
	Alejandro Colomar <alx.manpages@gmail.com>
Subject: [PATCH v2] memfd_secret.2: New page describing memfd_secret() system call
Date: Mon, 16 Nov 2020 22:01:37 +0100	[thread overview]
Message-ID: <20201116210136.12390-1-alx.manpages@gmail.com> (raw)
In-Reply-To: <20201005073242.GA4251@kernel.org>

From: Mike Rapoport <rppt@linux.ibm.com>

Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
Cowritten-by: Alejandro Colomar <alx.manpages@gmail.com>
Acked-by: Alejandro Colomar <alx.manpages@gmail.com>
Signed-off-by: Alejandro Colomar <alx.manpages@gmail.com>
---

Hi Mike,

I added that note about not having a wrapper,
fixed a few minor formatting and wording issues,
and sorted ERRORS alphabetically.

Cheers,

Alex

 man2/memfd_secret.2 | 178 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 178 insertions(+)
 create mode 100644 man2/memfd_secret.2

diff --git a/man2/memfd_secret.2 b/man2/memfd_secret.2
new file mode 100644
index 000000000..4e617aa0e
--- /dev/null
+++ b/man2/memfd_secret.2
@@ -0,0 +1,178 @@
+.\" Copyright (c) 2020, IBM Corporation.
+.\" Written by Mike Rapoport <rppt@linux.ibm.com>
+.\"
+.\" Based on memfd_create(2) man page
+.\" Copyright (C) 2014 Michael Kerrisk <mtk.manpages@gmail.com>
+.\" and Copyright (C) 2014 David Herrmann <dh.herrmann@gmail.com>
+.\"
+.\" %%%LICENSE_START(GPLv2+)
+.\"
+.\" This program is free software; you can redistribute it and/or modify
+.\" it under the terms of the GNU General Public License as published by
+.\" the Free Software Foundation; either version 2 of the License, or
+.\" (at your option) any later version.
+.\"
+.\" This program is distributed in the hope that it will be useful,
+.\" but WITHOUT ANY WARRANTY; without even the implied warranty of
+.\" MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+.\" GNU General Public License for more details.
+.\"
+.\" You should have received a copy of the GNU General Public
+.\" License along with this manual; if not, see
+.\" <http://www.gnu.org/licenses/>.
+.\" %%%LICENSE_END
+.\"
+.TH MEMFD_SECRET 2 2020-08-02 Linux "Linux Programmer's Manual"
+.SH NAME
+memfd_secret \- create an anonymous file to map secret memory regions
+.SH SYNOPSIS
+.nf
+.B #include <linux/secretmem.h>
+.PP
+.BI "int memfd_secret(unsigned long " flags ");"
+.fi
+.PP
+.IR Note :
+There is no glibc wrapper for this system call; see NOTES.
+.SH DESCRIPTION
+.BR memfd_secret ()
+creates an anonymous file and returns a file descriptor that refers to it.
+The file can only be memory-mapped;
+the memory in such mapping
+will have stronger protection than usual memory mapped files,
+and so it can be used to store application secrets.
+Unlike a regular file, a file created with
+.BR memfd_secret ()
+lives in RAM and has a volatile backing storage.
+Once all references to the file are dropped, it is automatically released.
+The initial size of the file is set to 0.
+Following the call, the file size should be set using
+.BR ftruncate (2).
+.PP
+The memory areas obtained with
+.BR mmap (2)
+from the file descriptor are exclusive to the owning context.
+These areas are removed from the kernel page tables
+and only the page table of the process holding the file descriptor
+maps the corresponding physical memory.
+.PP
+The following values may be bitwise ORed in
+.IR flags
+to control the behavior of
+.BR memfd_secret (2):
+.TP
+.BR FD_CLOEXEC
+Set the close-on-exec flag on the new file descriptor.
+See the description of the
+.B O_CLOEXEC
+flag in
+.BR open (2)
+for reasons why this may be useful.
+.PP
+.TP
+.BR SECRETMEM_UNCACHED
+In addition to excluding memory areas from the kernel page tables,
+mark the memory mappings uncached in the page table of the owning process.
+Such mappings can be used to prevent speculative loads
+and cache-based side channels.
+This mode of
+.BR memfd_secret ()
+is not supported on all architectures.
+.PP
+See also NOTES below.
+.PP
+As its return value,
+.BR memfd_secret ()
+returns a new file descriptor that can be used to refer to an anonymous file.
+This file descriptor is opened for both reading and writing
+.RB ( O_RDWR )
+and
+.B O_LARGEFILE
+is set for the file descriptor.
+.PP
+With respect to
+.BR fork (2)
+and
+.BR execve (2),
+the usual semantics apply for the file descriptor created by
+.BR memfd_secret ().
+A copy of the file descriptor is inherited by the child produced by
+.BR fork (2)
+and refers to the same file.
+The file descriptor is preserved across
+.BR execve (2),
+unless the close-on-exec flag has been set.
+.PP
+The memory regions backed with
+.BR memfd_secret ()
+are locked in the same way as
+.BR mlock (2),
+however the implementation will not try to
+populate the whole range during the
+.BR mmap ()
+call.
+The amount of memory allowed for memory mappings
+of the file descriptor obeys the same rules as
+.BR mlock (2)
+and cannot exceed
+.BR RLIMIT_MEMLOCK .
+.SH RETURN VALUE
+On success,
+.BR memfd_secret ()
+returns a new file descriptor.
+On error, \-1 is returned and
+.I errno
+is set to indicate the error.
+.SH ERRORS
+.TP
+.B EINVAL
+.I flags
+included unknown bits.
+.TP
+.B EMFILE
+The per-process limit on the number of open file descriptors has been reached.
+.TP
+.B EMFILE
+The system-wide limit on the total number of open files has been reached.
+.TP
+.B ENOMEM
+There was insufficient memory to create a new anonymous file.
+.TP
+.B ENOSYS
+.BR memfd_secret ()
+is not implemented on this architecture.
+.SH VERSIONS
+The
+.BR memfd_secret (2)
+system call first appeared in Linux 5.X;
+.SH CONFORMING TO
+The
+.BR memfd_secret (2)
+system call is Linux-specific.
+.SH NOTES
+The
+.BR memfd_secret (2)
+system call provides an ability to hide information
+from the operating system.
+Normally Linux userspace mappings are protected from other users,
+but they are visible to privileged code.
+The mappings created using
+.BR memfd_secret ()
+are hidden from the kernel as well.
+.PP
+If an architecture supports
+.BR SECRETMEM_UNCACHED ,
+the mappings also have protection from speculative execution vulnerabilties,
+at the expense of increased memory access latency.
+Care should be taken when using
+.B SECRETMEM_UNCACHED
+to avoid degrading application performance.
+.PP
+Glibc does not provide a wrapper for this system call; call it using
+.BR syscall (2).
+.SH SEE ALSO
+.BR fcntl (2),
+.BR ftruncate (2),
+.BR mlock (2),
+.BR mmap (2),
+.BR setrlimit (2)
-- 
2.29.2
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org

WARNING: multiple messages have this Message-ID (diff)
From: Alejandro Colomar <alx.manpages@gmail.com>
To: rppt@kernel.org, mtk.manpages@gmail.com
Cc: Mike Rapoport <rppt@linux.ibm.com>,
	akpm@linux-foundation.org, arnd@arndb.de, bp@alien8.de,
	catalin.marinas@arm.com, cl@linux.com, colomar.6.4.3@gmail.com,
	dan.j.williams@intel.com, dave.hansen@linux.intel.com,
	david@redhat.com, elena.reshetova@intel.com, hpa@zytor.com,
	idan.yaniv@ibm.com, jejb@linux.ibm.com, kirill@shutemov.name,
	linux-api@vger.kernel.org, linux-arch@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-kselftest@vger.kernel.org, linux-man@vger.kernel.org,
	linux-mm@kvack.org, linux-nvdimm@lists.01.org,
	linux-riscv@lists.infradead.org, luto@kernel.org,
	mark.rutland@arm.com, mingo@redhat.com, palmer@dabbelt.com,
	paul.walmsley@sifive.com, peterz@infradead.org, shuah@kernel.org,
	tglx@linutronix.de, tycho@tycho.ws, viro@zeniv.linux.org.uk,
	will@kernel.org, willy@infradead.org, x86@kernel.org,
	Alejandro Colomar <alx.manpages@gmail.com>
Subject: [PATCH v2] memfd_secret.2: New page describing memfd_secret() system call
Date: Mon, 16 Nov 2020 22:01:37 +0100	[thread overview]
Message-ID: <20201116210136.12390-1-alx.manpages@gmail.com> (raw)
In-Reply-To: <20201005073242.GA4251@kernel.org>

From: Mike Rapoport <rppt@linux.ibm.com>

Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
Cowritten-by: Alejandro Colomar <alx.manpages@gmail.com>
Acked-by: Alejandro Colomar <alx.manpages@gmail.com>
Signed-off-by: Alejandro Colomar <alx.manpages@gmail.com>
---

Hi Mike,

I added that note about not having a wrapper,
fixed a few minor formatting and wording issues,
and sorted ERRORS alphabetically.

Cheers,

Alex

 man2/memfd_secret.2 | 178 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 178 insertions(+)
 create mode 100644 man2/memfd_secret.2

diff --git a/man2/memfd_secret.2 b/man2/memfd_secret.2
new file mode 100644
index 000000000..4e617aa0e
--- /dev/null
+++ b/man2/memfd_secret.2
@@ -0,0 +1,178 @@
+.\" Copyright (c) 2020, IBM Corporation.
+.\" Written by Mike Rapoport <rppt@linux.ibm.com>
+.\"
+.\" Based on memfd_create(2) man page
+.\" Copyright (C) 2014 Michael Kerrisk <mtk.manpages@gmail.com>
+.\" and Copyright (C) 2014 David Herrmann <dh.herrmann@gmail.com>
+.\"
+.\" %%%LICENSE_START(GPLv2+)
+.\"
+.\" This program is free software; you can redistribute it and/or modify
+.\" it under the terms of the GNU General Public License as published by
+.\" the Free Software Foundation; either version 2 of the License, or
+.\" (at your option) any later version.
+.\"
+.\" This program is distributed in the hope that it will be useful,
+.\" but WITHOUT ANY WARRANTY; without even the implied warranty of
+.\" MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+.\" GNU General Public License for more details.
+.\"
+.\" You should have received a copy of the GNU General Public
+.\" License along with this manual; if not, see
+.\" <http://www.gnu.org/licenses/>.
+.\" %%%LICENSE_END
+.\"
+.TH MEMFD_SECRET 2 2020-08-02 Linux "Linux Programmer's Manual"
+.SH NAME
+memfd_secret \- create an anonymous file to map secret memory regions
+.SH SYNOPSIS
+.nf
+.B #include <linux/secretmem.h>
+.PP
+.BI "int memfd_secret(unsigned long " flags ");"
+.fi
+.PP
+.IR Note :
+There is no glibc wrapper for this system call; see NOTES.
+.SH DESCRIPTION
+.BR memfd_secret ()
+creates an anonymous file and returns a file descriptor that refers to it.
+The file can only be memory-mapped;
+the memory in such mapping
+will have stronger protection than usual memory mapped files,
+and so it can be used to store application secrets.
+Unlike a regular file, a file created with
+.BR memfd_secret ()
+lives in RAM and has a volatile backing storage.
+Once all references to the file are dropped, it is automatically released.
+The initial size of the file is set to 0.
+Following the call, the file size should be set using
+.BR ftruncate (2).
+.PP
+The memory areas obtained with
+.BR mmap (2)
+from the file descriptor are exclusive to the owning context.
+These areas are removed from the kernel page tables
+and only the page table of the process holding the file descriptor
+maps the corresponding physical memory.
+.PP
+The following values may be bitwise ORed in
+.IR flags
+to control the behavior of
+.BR memfd_secret (2):
+.TP
+.BR FD_CLOEXEC
+Set the close-on-exec flag on the new file descriptor.
+See the description of the
+.B O_CLOEXEC
+flag in
+.BR open (2)
+for reasons why this may be useful.
+.PP
+.TP
+.BR SECRETMEM_UNCACHED
+In addition to excluding memory areas from the kernel page tables,
+mark the memory mappings uncached in the page table of the owning process.
+Such mappings can be used to prevent speculative loads
+and cache-based side channels.
+This mode of
+.BR memfd_secret ()
+is not supported on all architectures.
+.PP
+See also NOTES below.
+.PP
+As its return value,
+.BR memfd_secret ()
+returns a new file descriptor that can be used to refer to an anonymous file.
+This file descriptor is opened for both reading and writing
+.RB ( O_RDWR )
+and
+.B O_LARGEFILE
+is set for the file descriptor.
+.PP
+With respect to
+.BR fork (2)
+and
+.BR execve (2),
+the usual semantics apply for the file descriptor created by
+.BR memfd_secret ().
+A copy of the file descriptor is inherited by the child produced by
+.BR fork (2)
+and refers to the same file.
+The file descriptor is preserved across
+.BR execve (2),
+unless the close-on-exec flag has been set.
+.PP
+The memory regions backed with
+.BR memfd_secret ()
+are locked in the same way as
+.BR mlock (2),
+however the implementation will not try to
+populate the whole range during the
+.BR mmap ()
+call.
+The amount of memory allowed for memory mappings
+of the file descriptor obeys the same rules as
+.BR mlock (2)
+and cannot exceed
+.BR RLIMIT_MEMLOCK .
+.SH RETURN VALUE
+On success,
+.BR memfd_secret ()
+returns a new file descriptor.
+On error, \-1 is returned and
+.I errno
+is set to indicate the error.
+.SH ERRORS
+.TP
+.B EINVAL
+.I flags
+included unknown bits.
+.TP
+.B EMFILE
+The per-process limit on the number of open file descriptors has been reached.
+.TP
+.B EMFILE
+The system-wide limit on the total number of open files has been reached.
+.TP
+.B ENOMEM
+There was insufficient memory to create a new anonymous file.
+.TP
+.B ENOSYS
+.BR memfd_secret ()
+is not implemented on this architecture.
+.SH VERSIONS
+The
+.BR memfd_secret (2)
+system call first appeared in Linux 5.X;
+.SH CONFORMING TO
+The
+.BR memfd_secret (2)
+system call is Linux-specific.
+.SH NOTES
+The
+.BR memfd_secret (2)
+system call provides an ability to hide information
+from the operating system.
+Normally Linux userspace mappings are protected from other users,
+but they are visible to privileged code.
+The mappings created using
+.BR memfd_secret ()
+are hidden from the kernel as well.
+.PP
+If an architecture supports
+.BR SECRETMEM_UNCACHED ,
+the mappings also have protection from speculative execution vulnerabilties,
+at the expense of increased memory access latency.
+Care should be taken when using
+.B SECRETMEM_UNCACHED
+to avoid degrading application performance.
+.PP
+Glibc does not provide a wrapper for this system call; call it using
+.BR syscall (2).
+.SH SEE ALSO
+.BR fcntl (2),
+.BR ftruncate (2),
+.BR mlock (2),
+.BR mmap (2),
+.BR setrlimit (2)
-- 
2.29.2


WARNING: multiple messages have this Message-ID (diff)
From: Alejandro Colomar <alx.manpages@gmail.com>
To: rppt@kernel.org, mtk.manpages@gmail.com
Cc: mark.rutland@arm.com, linux-man@vger.kernel.org,
	tglx@linutronix.de, david@redhat.com, peterz@infradead.org,
	catalin.marinas@arm.com,
	Alejandro Colomar <alx.manpages@gmail.com>,
	dave.hansen@linux.intel.com, linux-mm@kvack.org, will@kernel.org,
	linux-kselftest@vger.kernel.org, hpa@zytor.com, cl@linux.com,
	idan.yaniv@ibm.com, linux-riscv@lists.infradead.org,
	elena.reshetova@intel.com, linux-arch@vger.kernel.org,
	tycho@tycho.ws, linux-nvdimm@lists.01.org,
	colomar.6.4.3@gmail.com, shuah@kernel.org, x86@kernel.org,
	willy@infradead.org, Mike Rapoport <rppt@linux.ibm.com>,
	mingo@redhat.com, arnd@arndb.de, jejb@linux.ibm.com,
	bp@alien8.de, viro@zeniv.linux.org.uk, luto@kernel.org,
	paul.walmsley@sifive.com, kirill@shutemov.name,
	dan.j.williams@intel.com, linux-arm-kernel@lists.infradead.org,
	linux-api@vger.kernel.org, linux-kernel@vger.kernel.org,
	palmer@dabbelt.com, linux-fsdevel@vger.kernel.org,
	akpm@linux-foundation.org
Subject: [PATCH v2] memfd_secret.2: New page describing memfd_secret() system call
Date: Mon, 16 Nov 2020 22:01:37 +0100	[thread overview]
Message-ID: <20201116210136.12390-1-alx.manpages@gmail.com> (raw)
In-Reply-To: <20201005073242.GA4251@kernel.org>

From: Mike Rapoport <rppt@linux.ibm.com>

Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
Cowritten-by: Alejandro Colomar <alx.manpages@gmail.com>
Acked-by: Alejandro Colomar <alx.manpages@gmail.com>
Signed-off-by: Alejandro Colomar <alx.manpages@gmail.com>
---

Hi Mike,

I added that note about not having a wrapper,
fixed a few minor formatting and wording issues,
and sorted ERRORS alphabetically.

Cheers,

Alex

 man2/memfd_secret.2 | 178 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 178 insertions(+)
 create mode 100644 man2/memfd_secret.2

diff --git a/man2/memfd_secret.2 b/man2/memfd_secret.2
new file mode 100644
index 000000000..4e617aa0e
--- /dev/null
+++ b/man2/memfd_secret.2
@@ -0,0 +1,178 @@
+.\" Copyright (c) 2020, IBM Corporation.
+.\" Written by Mike Rapoport <rppt@linux.ibm.com>
+.\"
+.\" Based on memfd_create(2) man page
+.\" Copyright (C) 2014 Michael Kerrisk <mtk.manpages@gmail.com>
+.\" and Copyright (C) 2014 David Herrmann <dh.herrmann@gmail.com>
+.\"
+.\" %%%LICENSE_START(GPLv2+)
+.\"
+.\" This program is free software; you can redistribute it and/or modify
+.\" it under the terms of the GNU General Public License as published by
+.\" the Free Software Foundation; either version 2 of the License, or
+.\" (at your option) any later version.
+.\"
+.\" This program is distributed in the hope that it will be useful,
+.\" but WITHOUT ANY WARRANTY; without even the implied warranty of
+.\" MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+.\" GNU General Public License for more details.
+.\"
+.\" You should have received a copy of the GNU General Public
+.\" License along with this manual; if not, see
+.\" <http://www.gnu.org/licenses/>.
+.\" %%%LICENSE_END
+.\"
+.TH MEMFD_SECRET 2 2020-08-02 Linux "Linux Programmer's Manual"
+.SH NAME
+memfd_secret \- create an anonymous file to map secret memory regions
+.SH SYNOPSIS
+.nf
+.B #include <linux/secretmem.h>
+.PP
+.BI "int memfd_secret(unsigned long " flags ");"
+.fi
+.PP
+.IR Note :
+There is no glibc wrapper for this system call; see NOTES.
+.SH DESCRIPTION
+.BR memfd_secret ()
+creates an anonymous file and returns a file descriptor that refers to it.
+The file can only be memory-mapped;
+the memory in such mapping
+will have stronger protection than usual memory mapped files,
+and so it can be used to store application secrets.
+Unlike a regular file, a file created with
+.BR memfd_secret ()
+lives in RAM and has a volatile backing storage.
+Once all references to the file are dropped, it is automatically released.
+The initial size of the file is set to 0.
+Following the call, the file size should be set using
+.BR ftruncate (2).
+.PP
+The memory areas obtained with
+.BR mmap (2)
+from the file descriptor are exclusive to the owning context.
+These areas are removed from the kernel page tables
+and only the page table of the process holding the file descriptor
+maps the corresponding physical memory.
+.PP
+The following values may be bitwise ORed in
+.IR flags
+to control the behavior of
+.BR memfd_secret (2):
+.TP
+.BR FD_CLOEXEC
+Set the close-on-exec flag on the new file descriptor.
+See the description of the
+.B O_CLOEXEC
+flag in
+.BR open (2)
+for reasons why this may be useful.
+.PP
+.TP
+.BR SECRETMEM_UNCACHED
+In addition to excluding memory areas from the kernel page tables,
+mark the memory mappings uncached in the page table of the owning process.
+Such mappings can be used to prevent speculative loads
+and cache-based side channels.
+This mode of
+.BR memfd_secret ()
+is not supported on all architectures.
+.PP
+See also NOTES below.
+.PP
+As its return value,
+.BR memfd_secret ()
+returns a new file descriptor that can be used to refer to an anonymous file.
+This file descriptor is opened for both reading and writing
+.RB ( O_RDWR )
+and
+.B O_LARGEFILE
+is set for the file descriptor.
+.PP
+With respect to
+.BR fork (2)
+and
+.BR execve (2),
+the usual semantics apply for the file descriptor created by
+.BR memfd_secret ().
+A copy of the file descriptor is inherited by the child produced by
+.BR fork (2)
+and refers to the same file.
+The file descriptor is preserved across
+.BR execve (2),
+unless the close-on-exec flag has been set.
+.PP
+The memory regions backed with
+.BR memfd_secret ()
+are locked in the same way as
+.BR mlock (2),
+however the implementation will not try to
+populate the whole range during the
+.BR mmap ()
+call.
+The amount of memory allowed for memory mappings
+of the file descriptor obeys the same rules as
+.BR mlock (2)
+and cannot exceed
+.BR RLIMIT_MEMLOCK .
+.SH RETURN VALUE
+On success,
+.BR memfd_secret ()
+returns a new file descriptor.
+On error, \-1 is returned and
+.I errno
+is set to indicate the error.
+.SH ERRORS
+.TP
+.B EINVAL
+.I flags
+included unknown bits.
+.TP
+.B EMFILE
+The per-process limit on the number of open file descriptors has been reached.
+.TP
+.B EMFILE
+The system-wide limit on the total number of open files has been reached.
+.TP
+.B ENOMEM
+There was insufficient memory to create a new anonymous file.
+.TP
+.B ENOSYS
+.BR memfd_secret ()
+is not implemented on this architecture.
+.SH VERSIONS
+The
+.BR memfd_secret (2)
+system call first appeared in Linux 5.X;
+.SH CONFORMING TO
+The
+.BR memfd_secret (2)
+system call is Linux-specific.
+.SH NOTES
+The
+.BR memfd_secret (2)
+system call provides an ability to hide information
+from the operating system.
+Normally Linux userspace mappings are protected from other users,
+but they are visible to privileged code.
+The mappings created using
+.BR memfd_secret ()
+are hidden from the kernel as well.
+.PP
+If an architecture supports
+.BR SECRETMEM_UNCACHED ,
+the mappings also have protection from speculative execution vulnerabilties,
+at the expense of increased memory access latency.
+Care should be taken when using
+.B SECRETMEM_UNCACHED
+to avoid degrading application performance.
+.PP
+Glibc does not provide a wrapper for this system call; call it using
+.BR syscall (2).
+.SH SEE ALSO
+.BR fcntl (2),
+.BR ftruncate (2),
+.BR mlock (2),
+.BR mmap (2),
+.BR setrlimit (2)
-- 
2.29.2


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

WARNING: multiple messages have this Message-ID (diff)
From: Alejandro Colomar <alx.manpages@gmail.com>
To: rppt@kernel.org, mtk.manpages@gmail.com
Cc: mark.rutland@arm.com, linux-man@vger.kernel.org,
	tglx@linutronix.de, david@redhat.com, peterz@infradead.org,
	catalin.marinas@arm.com,
	Alejandro Colomar <alx.manpages@gmail.com>,
	dave.hansen@linux.intel.com, linux-mm@kvack.org, will@kernel.org,
	linux-kselftest@vger.kernel.org, hpa@zytor.com, cl@linux.com,
	idan.yaniv@ibm.com, linux-riscv@lists.infradead.org,
	elena.reshetova@intel.com, linux-arch@vger.kernel.org,
	tycho@tycho.ws, linux-nvdimm@lists.01.org,
	colomar.6.4.3@gmail.com, shuah@kernel.org, x86@kernel.org,
	willy@infradead.org, Mike Rapoport <rppt@linux.ibm.com>,
	mingo@redhat.com, arnd@arndb.de, jejb@linux.ibm.com,
	bp@alien8.de, viro@zeniv.linux.org.uk, luto@kernel.org,
	paul.walmsley@sifive.com, kirill@shutemov.name,
	dan.j.williams@intel.com, linux-arm-kernel@lists.infradead.org,
	linux-api@vger.kernel.org, linux-kernel@vger.kernel.org,
	palmer@dabbelt.com, linux-fsdevel@vger.kernel.org,
	akpm@linux-foundation.org
Subject: [PATCH v2] memfd_secret.2: New page describing memfd_secret() system call
Date: Mon, 16 Nov 2020 22:01:37 +0100	[thread overview]
Message-ID: <20201116210136.12390-1-alx.manpages@gmail.com> (raw)
In-Reply-To: <20201005073242.GA4251@kernel.org>

From: Mike Rapoport <rppt@linux.ibm.com>

Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
Cowritten-by: Alejandro Colomar <alx.manpages@gmail.com>
Acked-by: Alejandro Colomar <alx.manpages@gmail.com>
Signed-off-by: Alejandro Colomar <alx.manpages@gmail.com>
---

Hi Mike,

I added that note about not having a wrapper,
fixed a few minor formatting and wording issues,
and sorted ERRORS alphabetically.

Cheers,

Alex

 man2/memfd_secret.2 | 178 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 178 insertions(+)
 create mode 100644 man2/memfd_secret.2

diff --git a/man2/memfd_secret.2 b/man2/memfd_secret.2
new file mode 100644
index 000000000..4e617aa0e
--- /dev/null
+++ b/man2/memfd_secret.2
@@ -0,0 +1,178 @@
+.\" Copyright (c) 2020, IBM Corporation.
+.\" Written by Mike Rapoport <rppt@linux.ibm.com>
+.\"
+.\" Based on memfd_create(2) man page
+.\" Copyright (C) 2014 Michael Kerrisk <mtk.manpages@gmail.com>
+.\" and Copyright (C) 2014 David Herrmann <dh.herrmann@gmail.com>
+.\"
+.\" %%%LICENSE_START(GPLv2+)
+.\"
+.\" This program is free software; you can redistribute it and/or modify
+.\" it under the terms of the GNU General Public License as published by
+.\" the Free Software Foundation; either version 2 of the License, or
+.\" (at your option) any later version.
+.\"
+.\" This program is distributed in the hope that it will be useful,
+.\" but WITHOUT ANY WARRANTY; without even the implied warranty of
+.\" MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+.\" GNU General Public License for more details.
+.\"
+.\" You should have received a copy of the GNU General Public
+.\" License along with this manual; if not, see
+.\" <http://www.gnu.org/licenses/>.
+.\" %%%LICENSE_END
+.\"
+.TH MEMFD_SECRET 2 2020-08-02 Linux "Linux Programmer's Manual"
+.SH NAME
+memfd_secret \- create an anonymous file to map secret memory regions
+.SH SYNOPSIS
+.nf
+.B #include <linux/secretmem.h>
+.PP
+.BI "int memfd_secret(unsigned long " flags ");"
+.fi
+.PP
+.IR Note :
+There is no glibc wrapper for this system call; see NOTES.
+.SH DESCRIPTION
+.BR memfd_secret ()
+creates an anonymous file and returns a file descriptor that refers to it.
+The file can only be memory-mapped;
+the memory in such mapping
+will have stronger protection than usual memory mapped files,
+and so it can be used to store application secrets.
+Unlike a regular file, a file created with
+.BR memfd_secret ()
+lives in RAM and has a volatile backing storage.
+Once all references to the file are dropped, it is automatically released.
+The initial size of the file is set to 0.
+Following the call, the file size should be set using
+.BR ftruncate (2).
+.PP
+The memory areas obtained with
+.BR mmap (2)
+from the file descriptor are exclusive to the owning context.
+These areas are removed from the kernel page tables
+and only the page table of the process holding the file descriptor
+maps the corresponding physical memory.
+.PP
+The following values may be bitwise ORed in
+.IR flags
+to control the behavior of
+.BR memfd_secret (2):
+.TP
+.BR FD_CLOEXEC
+Set the close-on-exec flag on the new file descriptor.
+See the description of the
+.B O_CLOEXEC
+flag in
+.BR open (2)
+for reasons why this may be useful.
+.PP
+.TP
+.BR SECRETMEM_UNCACHED
+In addition to excluding memory areas from the kernel page tables,
+mark the memory mappings uncached in the page table of the owning process.
+Such mappings can be used to prevent speculative loads
+and cache-based side channels.
+This mode of
+.BR memfd_secret ()
+is not supported on all architectures.
+.PP
+See also NOTES below.
+.PP
+As its return value,
+.BR memfd_secret ()
+returns a new file descriptor that can be used to refer to an anonymous file.
+This file descriptor is opened for both reading and writing
+.RB ( O_RDWR )
+and
+.B O_LARGEFILE
+is set for the file descriptor.
+.PP
+With respect to
+.BR fork (2)
+and
+.BR execve (2),
+the usual semantics apply for the file descriptor created by
+.BR memfd_secret ().
+A copy of the file descriptor is inherited by the child produced by
+.BR fork (2)
+and refers to the same file.
+The file descriptor is preserved across
+.BR execve (2),
+unless the close-on-exec flag has been set.
+.PP
+The memory regions backed with
+.BR memfd_secret ()
+are locked in the same way as
+.BR mlock (2),
+however the implementation will not try to
+populate the whole range during the
+.BR mmap ()
+call.
+The amount of memory allowed for memory mappings
+of the file descriptor obeys the same rules as
+.BR mlock (2)
+and cannot exceed
+.BR RLIMIT_MEMLOCK .
+.SH RETURN VALUE
+On success,
+.BR memfd_secret ()
+returns a new file descriptor.
+On error, \-1 is returned and
+.I errno
+is set to indicate the error.
+.SH ERRORS
+.TP
+.B EINVAL
+.I flags
+included unknown bits.
+.TP
+.B EMFILE
+The per-process limit on the number of open file descriptors has been reached.
+.TP
+.B EMFILE
+The system-wide limit on the total number of open files has been reached.
+.TP
+.B ENOMEM
+There was insufficient memory to create a new anonymous file.
+.TP
+.B ENOSYS
+.BR memfd_secret ()
+is not implemented on this architecture.
+.SH VERSIONS
+The
+.BR memfd_secret (2)
+system call first appeared in Linux 5.X;
+.SH CONFORMING TO
+The
+.BR memfd_secret (2)
+system call is Linux-specific.
+.SH NOTES
+The
+.BR memfd_secret (2)
+system call provides an ability to hide information
+from the operating system.
+Normally Linux userspace mappings are protected from other users,
+but they are visible to privileged code.
+The mappings created using
+.BR memfd_secret ()
+are hidden from the kernel as well.
+.PP
+If an architecture supports
+.BR SECRETMEM_UNCACHED ,
+the mappings also have protection from speculative execution vulnerabilties,
+at the expense of increased memory access latency.
+Care should be taken when using
+.B SECRETMEM_UNCACHED
+to avoid degrading application performance.
+.PP
+Glibc does not provide a wrapper for this system call; call it using
+.BR syscall (2).
+.SH SEE ALSO
+.BR fcntl (2),
+.BR ftruncate (2),
+.BR mlock (2),
+.BR mmap (2),
+.BR setrlimit (2)
-- 
2.29.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-11-16 21:03 UTC|newest]

Thread overview: 236+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-24 13:28 [PATCH v6 0/6] mm: introduce memfd_secret system call to create "secret" memory areas Mike Rapoport
2020-09-24 13:28 ` Mike Rapoport
2020-09-24 13:28 ` Mike Rapoport
2020-09-24 13:28 ` Mike Rapoport
2020-09-24 13:28 ` [PATCH v6 1/6] mm: add definition of PMD_PAGE_ORDER Mike Rapoport
2020-09-24 13:28   ` Mike Rapoport
2020-09-24 13:28   ` Mike Rapoport
2020-09-24 13:28   ` Mike Rapoport
2020-09-24 13:29 ` [PATCH v6 2/6] mmap: make mlock_future_check() global Mike Rapoport
2020-09-24 13:29   ` Mike Rapoport
2020-09-24 13:29   ` Mike Rapoport
2020-09-24 13:29   ` Mike Rapoport
2020-09-24 13:29 ` [PATCH v6 3/6] mm: introduce memfd_secret system call to create "secret" memory areas Mike Rapoport
2020-09-24 13:29   ` Mike Rapoport
2020-09-24 13:29   ` Mike Rapoport
2020-09-24 13:29   ` Mike Rapoport
2020-09-29  4:58   ` Edgecombe, Rick P
2020-09-29  4:58     ` Edgecombe, Rick P
2020-09-29  4:58     ` Edgecombe, Rick P
2020-09-29  4:58     ` Edgecombe, Rick P
2020-09-29  4:58     ` Edgecombe, Rick P
2020-09-29 13:06     ` Mike Rapoport
2020-09-29 13:06       ` Mike Rapoport
2020-09-29 13:06       ` Mike Rapoport
2020-09-29 13:06       ` Mike Rapoport
2020-09-29 13:06       ` Mike Rapoport
2020-09-29 20:06       ` Edgecombe, Rick P
2020-09-29 20:06         ` Edgecombe, Rick P
2020-09-29 20:06         ` Edgecombe, Rick P
2020-09-29 20:06         ` Edgecombe, Rick P
2020-09-29 20:06         ` Edgecombe, Rick P
2020-09-30 10:35         ` Mike Rapoport
2020-09-30 10:35           ` Mike Rapoport
2020-09-30 10:35           ` Mike Rapoport
2020-09-30 10:35           ` Mike Rapoport
2020-09-30 10:35           ` Mike Rapoport
2020-09-30 20:11           ` Edgecombe, Rick P
2020-09-30 20:11             ` Edgecombe, Rick P
2020-09-30 20:11             ` Edgecombe, Rick P
2020-09-30 20:11             ` Edgecombe, Rick P
2020-09-30 20:11             ` Edgecombe, Rick P
2020-10-11  9:42             ` Mike Rapoport
2020-10-11  9:42               ` Mike Rapoport
2020-10-11  9:42               ` Mike Rapoport
2020-10-11  9:42               ` Mike Rapoport
2020-10-11  9:42               ` Mike Rapoport
2020-09-24 13:29 ` [PATCH v6 4/6] arch, mm: wire up memfd_secret system call were relevant Mike Rapoport
2020-09-24 13:29   ` Mike Rapoport
2020-09-24 13:29   ` Mike Rapoport
2020-09-24 13:29   ` Mike Rapoport
2020-09-24 13:29 ` [PATCH v6 5/6] mm: secretmem: use PMD-size pages to amortize direct map fragmentation Mike Rapoport
2020-09-24 13:29   ` Mike Rapoport
2020-09-24 13:29   ` Mike Rapoport
2020-09-24 13:29   ` Mike Rapoport
2020-09-25  7:41   ` Peter Zijlstra
2020-09-25  7:41     ` Peter Zijlstra
2020-09-25  7:41     ` Peter Zijlstra
2020-09-25  7:41     ` Peter Zijlstra
2020-09-25  9:00     ` David Hildenbrand
2020-09-25  9:00       ` David Hildenbrand
2020-09-25  9:00       ` David Hildenbrand
2020-09-25  9:00       ` David Hildenbrand
2020-09-25  9:50       ` Peter Zijlstra
2020-09-25  9:50         ` Peter Zijlstra
2020-09-25  9:50         ` Peter Zijlstra
2020-09-25  9:50         ` Peter Zijlstra
2020-09-25 10:31         ` Mark Rutland
2020-09-25 10:31           ` Mark Rutland
2020-09-25 10:31           ` Mark Rutland
2020-09-25 10:31           ` Mark Rutland
2020-09-25 14:57           ` Tycho Andersen
2020-09-25 14:57             ` Tycho Andersen
2020-09-25 14:57             ` Tycho Andersen
2020-09-25 14:57             ` Tycho Andersen
2020-09-29 14:04           ` Mike Rapoport
2020-09-29 14:04             ` Mike Rapoport
2020-09-29 14:04             ` Mike Rapoport
2020-09-29 14:04             ` Mike Rapoport
2020-09-29 13:07         ` Mike Rapoport
2020-09-29 13:07           ` Mike Rapoport
2020-09-29 13:07           ` Mike Rapoport
2020-09-29 13:07           ` Mike Rapoport
2020-09-29 13:06       ` Mike Rapoport
2020-09-29 13:06         ` Mike Rapoport
2020-09-29 13:06         ` Mike Rapoport
2020-09-29 13:06         ` Mike Rapoport
2020-09-29 13:05     ` Mike Rapoport
2020-09-29 13:05       ` Mike Rapoport
2020-09-29 13:05       ` Mike Rapoport
2020-09-29 13:05       ` Mike Rapoport
2020-09-29 14:12       ` Peter Zijlstra
2020-09-29 14:12         ` Peter Zijlstra
2020-09-29 14:12         ` Peter Zijlstra
2020-09-29 14:12         ` Peter Zijlstra
2020-09-29 14:31         ` Dave Hansen
2020-09-29 14:31           ` Dave Hansen
2020-09-29 14:31           ` Dave Hansen
2020-09-29 14:31           ` Dave Hansen
2020-09-29 14:58         ` Mike Rapoport
2020-09-29 14:58           ` Mike Rapoport
2020-09-29 14:58           ` Mike Rapoport
2020-09-29 14:58           ` Mike Rapoport
2020-09-29 15:15           ` Peter Zijlstra
2020-09-29 15:15             ` Peter Zijlstra
2020-09-29 15:15             ` Peter Zijlstra
2020-09-29 15:15             ` Peter Zijlstra
2020-09-30 10:27             ` Mike Rapoport
2020-09-30 10:27               ` Mike Rapoport
2020-09-30 10:27               ` Mike Rapoport
2020-09-30 10:27               ` Mike Rapoport
2020-09-30 14:39               ` James Bottomley
2020-09-30 14:39                 ` James Bottomley
2020-09-30 14:39                 ` James Bottomley
2020-09-30 14:39                 ` James Bottomley
2020-09-30 14:45                 ` David Hildenbrand
2020-09-30 14:45                   ` David Hildenbrand
2020-09-30 14:45                   ` David Hildenbrand
2020-09-30 14:45                   ` David Hildenbrand
2020-09-30 15:17                   ` James Bottomley
2020-09-30 15:17                     ` James Bottomley
2020-09-30 15:17                     ` James Bottomley
2020-09-30 15:17                     ` James Bottomley
2020-09-30 15:25                     ` David Hildenbrand
2020-09-30 15:25                       ` David Hildenbrand
2020-09-30 15:25                       ` David Hildenbrand
2020-09-30 15:25                       ` David Hildenbrand
2020-09-30 15:09               ` Matthew Wilcox
2020-09-30 15:09                 ` Matthew Wilcox
2020-09-30 15:09                 ` Matthew Wilcox
2020-09-30 15:09                 ` Matthew Wilcox
2020-10-01  8:14                 ` Mike Rapoport
2020-10-01  8:14                   ` Mike Rapoport
2020-10-01  8:14                   ` Mike Rapoport
2020-10-01  8:14                   ` Mike Rapoport
2020-09-29 15:03         ` James Bottomley
2020-09-29 15:03           ` James Bottomley
2020-09-29 15:03           ` James Bottomley
2020-09-29 15:03           ` James Bottomley
2020-09-30 10:20         ` Mike Rapoport
2020-09-30 10:20           ` Mike Rapoport
2020-09-30 10:20           ` Mike Rapoport
2020-09-30 10:20           ` Mike Rapoport
2020-09-30 10:43           ` Peter Zijlstra
2020-09-30 10:43             ` Peter Zijlstra
2020-09-30 10:43             ` Peter Zijlstra
2020-09-30 10:43             ` Peter Zijlstra
2020-09-24 13:29 ` [PATCH v6 6/6] secretmem: test: add basic selftest for memfd_secret(2) Mike Rapoport
2020-09-24 13:29   ` Mike Rapoport
2020-09-24 13:29   ` Mike Rapoport
2020-09-24 13:29   ` Mike Rapoport
2020-09-24 13:35 ` [PATCH] man2: new page describing memfd_secret() system call Mike Rapoport
2020-09-24 13:35   ` Mike Rapoport
2020-09-24 13:35   ` Mike Rapoport
2020-09-24 13:35   ` Mike Rapoport
2020-09-24 14:55   ` Alejandro Colomar
2020-09-24 14:55     ` Alejandro Colomar
2020-09-24 14:55     ` Alejandro Colomar
2020-09-24 14:55     ` Alejandro Colomar
2020-10-03  9:32     ` Alejandro Colomar
2020-10-03  9:32       ` Alejandro Colomar
2020-10-03  9:32       ` Alejandro Colomar
2020-10-03  9:32       ` Alejandro Colomar
2020-10-05  7:32       ` Mike Rapoport
2020-10-05  7:32         ` Mike Rapoport
2020-10-05  7:32         ` Mike Rapoport
2020-10-05  7:32         ` Mike Rapoport
2020-11-16 21:01         ` Alejandro Colomar [this message]
2020-11-16 21:01           ` [PATCH v2] memfd_secret.2: New " Alejandro Colomar
2020-11-16 21:01           ` Alejandro Colomar
2020-11-16 21:01           ` Alejandro Colomar
2020-11-17  6:26           ` Mike Rapoport
2020-11-17  6:26             ` Mike Rapoport
2020-11-17  6:26             ` Mike Rapoport
2020-11-17  6:26             ` Mike Rapoport
2020-11-21 21:46             ` Alejandro Colomar (man-pages)
2020-11-22  7:03               ` Mike Rapoport
2020-09-25  2:34 ` [PATCH v6 0/6] mm: introduce memfd_secret system call to create "secret" memory areas Andrew Morton
2020-09-25  2:34   ` Andrew Morton
2020-09-25  2:34   ` Andrew Morton
2020-09-25  2:34   ` Andrew Morton
2020-09-25  6:42   ` Mike Rapoport
2020-09-25  6:42     ` Mike Rapoport
2020-09-25  6:42     ` Mike Rapoport
2020-09-25  6:42     ` Mike Rapoport
2020-11-01 11:09 ` Hagen Paul Pfeifer
2020-11-01 11:09   ` Hagen Paul Pfeifer
2020-11-01 11:09   ` Hagen Paul Pfeifer
2020-11-01 11:09   ` Hagen Paul Pfeifer
2020-11-02 15:40   ` Mike Rapoport
2020-11-02 15:40     ` Mike Rapoport
2020-11-02 15:40     ` Mike Rapoport
2020-11-02 15:40     ` Mike Rapoport
2020-11-03 13:52     ` Hagen Paul Pfeifer
2020-11-03 13:52       ` Hagen Paul Pfeifer
2020-11-03 13:52       ` Hagen Paul Pfeifer
2020-11-03 13:52       ` Hagen Paul Pfeifer
2020-11-03 16:30       ` Mike Rapoport
2020-11-03 16:30         ` Mike Rapoport
2020-11-03 16:30         ` Mike Rapoport
2020-11-03 16:30         ` Mike Rapoport
2020-11-04 11:39         ` Hagen Paul Pfeifer
2020-11-04 11:39           ` Hagen Paul Pfeifer
2020-11-04 11:39           ` Hagen Paul Pfeifer
2020-11-04 11:39           ` Hagen Paul Pfeifer
2020-11-04 17:02           ` Mike Rapoport
2020-11-04 17:02             ` Mike Rapoport
2020-11-04 17:02             ` Mike Rapoport
2020-11-04 17:02             ` Mike Rapoport
2020-11-09 10:41             ` Hagen Paul Pfeifer
2020-11-09 10:41               ` Hagen Paul Pfeifer
2020-11-09 10:41               ` Hagen Paul Pfeifer
2020-11-09 10:41               ` Hagen Paul Pfeifer
2020-11-02  9:11 ` David Hildenbrand
2020-11-02  9:11   ` David Hildenbrand
2020-11-02  9:11   ` David Hildenbrand
2020-11-02  9:11   ` David Hildenbrand
2020-11-02  9:31   ` David Hildenbrand
2020-11-02  9:31     ` David Hildenbrand
2020-11-02  9:31     ` David Hildenbrand
2020-11-02  9:31     ` David Hildenbrand
2020-11-02 17:43   ` Mike Rapoport
2020-11-02 17:43     ` Mike Rapoport
2020-11-02 17:43     ` Mike Rapoport
2020-11-02 17:43     ` Mike Rapoport
2020-11-02 17:51     ` David Hildenbrand
2020-11-02 17:51       ` David Hildenbrand
2020-11-02 17:51       ` David Hildenbrand
2020-11-02 17:51       ` David Hildenbrand
2020-11-03  9:52       ` Mike Rapoport
2020-11-03  9:52         ` Mike Rapoport
2020-11-03  9:52         ` Mike Rapoport
2020-11-03  9:52         ` Mike Rapoport
2020-11-03 10:11         ` David Hildenbrand
2020-11-03 10:11           ` David Hildenbrand
2020-11-03 10:11           ` David Hildenbrand
2020-11-03 10:11           ` David Hildenbrand

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=20201116210136.12390-1-alx.manpages@gmail.com \
    --to=alx.manpages@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=bp@alien8.de \
    --cc=catalin.marinas@arm.com \
    --cc=cl@linux.com \
    --cc=colomar.6.4.3@gmail.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=david@redhat.com \
    --cc=elena.reshetova@intel.com \
    --cc=hpa@zytor.com \
    --cc=idan.yaniv@ibm.com \
    --cc=jejb@linux.ibm.com \
    --cc=kirill@shutemov.name \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-man@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-nvdimm@lists.01.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=luto@kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=mtk.manpages@gmail.com \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=peterz@infradead.org \
    --cc=rppt@kernel.org \
    --cc=rppt@linux.ibm.com \
    --cc=shuah@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=tycho@tycho.ws \
    --cc=viro@zeniv.linux.org.uk \
    --cc=will@kernel.org \
    --cc=willy@infradead.org \
    --cc=x86@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.