* [PATCH] memfd_secret.2: add NOTES section ...
@ 2021-09-02 7:50 Mike Rapoport
2021-09-10 13:12 ` Alejandro Colomar (man-pages)
0 siblings, 1 reply; 3+ messages in thread
From: Mike Rapoport @ 2021-09-02 7:50 UTC (permalink / raw)
To: Michael Kerrisk
Cc: Alejandro Colomar, Mike Rapoport, Mike Rapoport, linux-man
From: Mike Rapoport <rppt@linux.ibm.com>
... that explains the rationale for the system call
Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
---
man2/memfd_secret.2 | 61 +++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 61 insertions(+)
diff --git a/man2/memfd_secret.2 b/man2/memfd_secret.2
index f3380818e..869480b48 100644
--- a/man2/memfd_secret.2
+++ b/man2/memfd_secret.2
@@ -147,6 +147,67 @@ system call first appeared in Linux 5.14.
The
.BR memfd_secret ()
system call is Linux-specific.
+.SH NOTES
+.PP
+The
+.BR memfd_secret ()
+system call is designed to allow a user-space process
+to create a range of memory that is inaccessible to anybody else -
+kernel included.
+There is no 100% guarantee that kernel won't be able to access
+memory ranges backed by
+.BR memfd_secret ()
+in any circumstances, but nevertheless,
+it is much harder to exfiltrate data from these regions.
+.PP
+The
+.BR memfd_secret ()
+provides the following protections:
+.IP \(bu 3
+Enhanced protection
+(in conjunction with all the other in-kernel attack prevention systems)
+against ROP attacks.
+Absence of any in-kernel primitive for accessing memory backed by
+.BR memfd_secret ()
+means that one-gadget ROP attack
+can't work to perform data exfiltration.
+The attacker would need to find enough ROP gadgets
+to reconstruct the missing page table entries,
+which significantly increases difficulty of the attack,
+especially when other protections like the kernel stack size limit
+and address space layout randomization are in place.
+.IP \(bu
+Prevent cross-process userspace memory exposures.
+Once a region for a
+.BR memfd_secret ()
+memory mapping is allocated,
+the user can't accidentally pass it into the kernel
+to be transmitted somewhere.
+The memory pages in this region cannot be accessed via the direct map
+and they are disallowed in get_user_pages.
+.IP \(bu
+Harden against exploited kernel flaws.
+In order to access memory areas backed by
+.BR memfd_secret(),
+a kernel-side attack would need to
+either walk the page tables and create new ones,
+or spawn a new privileged userspace process to perform
+secrets exfiltration using
+.BR ptrace (2).
+.PP
+The way
+.BR memfd_secret ()
+allocates and locks the memory may impact overall system performance,
+therefore the system call is disabled by default and only available
+if the system administrator turned it on using
+"secretmem.enable=y" kernel parameter.
+.PP
+To prevent potiential data leaks of memory regions backed by
+.BR memfd_secret()
+from a hybernation image,
+hybernation is prevented when there are active
+.BR memfd_secret ()
+users.
.SH SEE ALSO
.BR fcntl (2),
.BR ftruncate (2),
--
2.31.1
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH] memfd_secret.2: add NOTES section ...
2021-09-02 7:50 [PATCH] memfd_secret.2: add NOTES section Mike Rapoport
@ 2021-09-10 13:12 ` Alejandro Colomar (man-pages)
2021-09-12 5:11 ` Mike Rapoport
0 siblings, 1 reply; 3+ messages in thread
From: Alejandro Colomar (man-pages) @ 2021-09-10 13:12 UTC (permalink / raw)
To: Mike Rapoport, Michael Kerrisk; +Cc: Mike Rapoport, linux-man
Hi Mike,
On 9/2/21 9:50 AM, Mike Rapoport wrote:
> From: Mike Rapoport <rppt@linux.ibm.com>
>
> ... that explains the rationale for the system call
>
> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
I found a few formatting/wording issues (see below; but I fixed them
myself, so you don't need to worry about them).
In general, I understood the rationale for the system call,
so I applied the patch to my tree. However, there are some parts that I
didn't understand well, mostly related to kernel internals, but since
Michael knows more about those, I expect him to review those again when
I send him the patch.
Thanks!
Alex
> ---
> man2/memfd_secret.2 | 61 +++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 61 insertions(+)
>
> diff --git a/man2/memfd_secret.2 b/man2/memfd_secret.2
> index f3380818e..869480b48 100644
> --- a/man2/memfd_secret.2
> +++ b/man2/memfd_secret.2
> @@ -147,6 +147,67 @@ system call first appeared in Linux 5.14.
> The
> .BR memfd_secret ()
> system call is Linux-specific.
> +.SH NOTES
> +.PP
Unnecessary .PP after .SH or .SS
> +The
> +.BR memfd_secret ()
> +system call is designed to allow a user-space process
> +to create a range of memory that is inaccessible to anybody else -
> +kernel included.
> +There is no 100% guarantee that kernel won't be able to access
> +memory ranges backed by
> +.BR memfd_secret ()
> +in any circumstances, but nevertheless,
> +it is much harder to exfiltrate data from these regions.
> +.PP
> +The
/The/d
> +.BR memfd_secret ()
> +provides the following protections:
> +.IP \(bu 3
> +Enhanced protection
> +(in conjunction with all the other in-kernel attack prevention systems)
> +against ROP attacks.
> +Absence of any in-kernel primitive for accessing memory backed by
> +.BR memfd_secret ()
> +means that one-gadget ROP attack
> +can't work to perform data exfiltration.
> +The attacker would need to find enough ROP gadgets
> +to reconstruct the missing page table entries,
> +which significantly increases difficulty of the attack,
> +especially when other protections like the kernel stack size limit
> +and address space layout randomization are in place.
> +.IP \(bu
> +Prevent cross-process userspace memory exposures.
s/userspace/user-space/
> +Once a region for a
> +.BR memfd_secret ()
> +memory mapping is allocated,
> +the user can't accidentally pass it into the kernel
> +to be transmitted somewhere.
> +The memory pages in this region cannot be accessed via the direct map
> +and they are disallowed in get_user_pages.
> +.IP \(bu
> +Harden against exploited kernel flaws.
> +In order to access memory areas backed by
> +.BR memfd_secret(),
> +a kernel-side attack would need to
> +either walk the page tables and create new ones,
> +or spawn a new privileged userspace process to perform
s/userspace/user-space/
> +secrets exfiltration using
> +.BR ptrace (2).
> +.PP
> +The way
> +.BR memfd_secret ()
> +allocates and locks the memory may impact overall system performance,
> +therefore the system call is disabled by default and only available
> +if the system administrator turned it on using
> +"secretmem.enable=y" kernel parameter.
> +.PP
> +To prevent potiential data leaks of memory regions backed by
> +.BR memfd_secret()
> +from a hybernation image,
> +hybernation is prevented when there are active
> +.BR memfd_secret ()
> +users.
> .SH SEE ALSO
> .BR fcntl (2),
> .BR ftruncate (2),
>
--
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] memfd_secret.2: add NOTES section ...
2021-09-10 13:12 ` Alejandro Colomar (man-pages)
@ 2021-09-12 5:11 ` Mike Rapoport
0 siblings, 0 replies; 3+ messages in thread
From: Mike Rapoport @ 2021-09-12 5:11 UTC (permalink / raw)
To: Alejandro Colomar (man-pages); +Cc: Mike Rapoport, Michael Kerrisk, linux-man
Hi Alex,
On Fri, Sep 10, 2021 at 03:12:37PM +0200, Alejandro Colomar (man-pages) wrote:
> Hi Mike,
>
> On 9/2/21 9:50 AM, Mike Rapoport wrote:
> > From: Mike Rapoport <rppt@linux.ibm.com>
> >
> > ... that explains the rationale for the system call
> >
> > Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
>
> I found a few formatting/wording issues (see below; but I fixed them myself,
> so you don't need to worry about them).
Thanks a lot!
> In general, I understood the rationale for the system call,
> so I applied the patch to my tree. However, there are some parts that I
> didn't understand well, mostly related to kernel internals, but since
> Michael knows more about those, I expect him to review those again when I
> send him the patch.
> Thanks!
>
> Alex
>
> > ---
> > man2/memfd_secret.2 | 61 +++++++++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 61 insertions(+)
> >
> > diff --git a/man2/memfd_secret.2 b/man2/memfd_secret.2
> > index f3380818e..869480b48 100644
> > --- a/man2/memfd_secret.2
> > +++ b/man2/memfd_secret.2
> > @@ -147,6 +147,67 @@ system call first appeared in Linux 5.14.
> > The
> > .BR memfd_secret ()
> > system call is Linux-specific.
> > +.SH NOTES
> > +.PP
>
> Unnecessary .PP after .SH or .SS
>
> > +The
> > +.BR memfd_secret ()
> > +system call is designed to allow a user-space process
> > +to create a range of memory that is inaccessible to anybody else -
> > +kernel included.
> > +There is no 100% guarantee that kernel won't be able to access
> > +memory ranges backed by
> > +.BR memfd_secret ()
> > +in any circumstances, but nevertheless,
> > +it is much harder to exfiltrate data from these regions.
> > +.PP
> > +The
>
> /The/d
>
> > +.BR memfd_secret ()
> > +provides the following protections:
> > +.IP \(bu 3
> > +Enhanced protection
> > +(in conjunction with all the other in-kernel attack prevention systems)
> > +against ROP attacks.
> > +Absence of any in-kernel primitive for accessing memory backed by
> > +.BR memfd_secret ()
> > +means that one-gadget ROP attack
> > +can't work to perform data exfiltration.
> > +The attacker would need to find enough ROP gadgets
> > +to reconstruct the missing page table entries,
> > +which significantly increases difficulty of the attack,
> > +especially when other protections like the kernel stack size limit
> > +and address space layout randomization are in place.
> > +.IP \(bu
> > +Prevent cross-process userspace memory exposures.
>
> s/userspace/user-space/
>
> > +Once a region for a
> > +.BR memfd_secret ()
> > +memory mapping is allocated,
> > +the user can't accidentally pass it into the kernel
> > +to be transmitted somewhere.
> > +The memory pages in this region cannot be accessed via the direct map
> > +and they are disallowed in get_user_pages.
> > +.IP \(bu
> > +Harden against exploited kernel flaws.
> > +In order to access memory areas backed by
> > +.BR memfd_secret(),
> > +a kernel-side attack would need to
> > +either walk the page tables and create new ones,
> > +or spawn a new privileged userspace process to perform
>
> s/userspace/user-space/
>
> > +secrets exfiltration using
> > +.BR ptrace (2).
> > +.PP
> > +The way
> > +.BR memfd_secret ()
> > +allocates and locks the memory may impact overall system performance,
> > +therefore the system call is disabled by default and only available
> > +if the system administrator turned it on using
> > +"secretmem.enable=y" kernel parameter.
> > +.PP
> > +To prevent potiential data leaks of memory regions backed by
> > +.BR memfd_secret()
> > +from a hybernation image,
> > +hybernation is prevented when there are active
> > +.BR memfd_secret ()
> > +users.
> > .SH SEE ALSO
> > .BR fcntl (2),
> > .BR ftruncate (2),
> >
>
>
> --
> Alejandro Colomar
> Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
> http://www.alejandro-colomar.es/
--
Sincerely yours,
Mike.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2021-09-12 5:11 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-09-02 7:50 [PATCH] memfd_secret.2: add NOTES section Mike Rapoport
2021-09-10 13:12 ` Alejandro Colomar (man-pages)
2021-09-12 5:11 ` Mike Rapoport
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.