[PATCH] ipc/shm: disable SHMALL, SHMMAX

[PATCH] ipc/shm: disable SHMALL, SHMMAX

[Manfred Spraul]

Shared memory segment can be abused to trigger out-of-memory conditions and
the standard measures against out-of-memory do not work:

- It is not possible to use setrlimit to limit the size of shm segments.

- Segments can exist without association with any processes, thus
  the oom-killer is unable to free that memory.

Therefore Linux always limited the size of segments by default to 32 MB.
As most systems do not need a protection against malicious user space apps,
a default that forces most admins and distros to change it doesn't make
sense.

The patch disables both limits by setting the limits to ULONG_MAX.

Admins who need a protection against out-of-memory conditions should
reduce the limits again and/or enable shm_rmid_forced.

Davidlohr: What do you think?

I prefer this approach: No need to update the man pages, smaller change
of the code, smaller risk of user space incompatibilities.

Signed-off-by: Manfred Spraul <manfred@colorfullife.com>
---
 include/linux/shm.h      | 2 +-
 include/uapi/linux/shm.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/shm.h b/include/linux/shm.h
index 1e2cd2e..37bf9c6 100644
--- a/include/linux/shm.h
+++ b/include/linux/shm.h
@@ -4,7 +4,7 @@
 #include <asm/page.h>
 #include <uapi/linux/shm.h>
 
-#define SHMALL (SHMMAX/PAGE_SIZE*(SHMMNI/16)) /* max shm system wide (pages) */
+#define SHMALL ULONG_MAX /* max shm system wide (pages) */
 #include <asm/shmparam.h>
 struct shmid_kernel /* private to the kernel */
 {	
diff --git a/include/uapi/linux/shm.h b/include/uapi/linux/shm.h
index 78b6941..d9497b7 100644
--- a/include/uapi/linux/shm.h
+++ b/include/uapi/linux/shm.h
@@ -12,7 +12,7 @@
  * be increased by sysctl
  */
 
-#define SHMMAX 0x2000000		 /* max shared seg size (bytes) */
+#define SHMMAX ULONG_MAX		 /* max shared seg size (bytes) */
 #define SHMMIN 1			 /* min shared seg size (bytes) */
 #define SHMMNI 4096			 /* max num of segs system wide */
 #ifndef __KERNEL__
-- 
1.9.0

[PATCH] ipc/shm: disable SHMALL, SHMMAX

[Manfred Spraul]

Shared memory segment can be abused to trigger out-of-memory conditions and
the standard measures against out-of-memory do not work:

- It is not possible to use setrlimit to limit the size of shm segments.

- Segments can exist without association with any processes, thus
  the oom-killer is unable to free that memory.

Therefore Linux always limited the size of segments by default to 32 MB.
As most systems do not need a protection against malicious user space apps,
a default that forces most admins and distros to change it doesn't make
sense.

The patch disables both limits by setting the limits to ULONG_MAX.

Admins who need a protection against out-of-memory conditions should
reduce the limits again and/or enable shm_rmid_forced.

Davidlohr: What do you think?

I prefer this approach: No need to update the man pages, smaller change
of the code, smaller risk of user space incompatibilities.

Signed-off-by: Manfred Spraul <manfred@colorfullife.com>
---
 include/linux/shm.h      | 2 +-
 include/uapi/linux/shm.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/shm.h b/include/linux/shm.h
index 1e2cd2e..37bf9c6 100644
--- a/include/linux/shm.h
+++ b/include/linux/shm.h
@@ -4,7 +4,7 @@
 #include <asm/page.h>
 #include <uapi/linux/shm.h>
 
-#define SHMALL (SHMMAX/PAGE_SIZE*(SHMMNI/16)) /* max shm system wide (pages) */
+#define SHMALL ULONG_MAX /* max shm system wide (pages) */
 #include <asm/shmparam.h>
 struct shmid_kernel /* private to the kernel */
 {	
diff --git a/include/uapi/linux/shm.h b/include/uapi/linux/shm.h
index 78b6941..d9497b7 100644
--- a/include/uapi/linux/shm.h
+++ b/include/uapi/linux/shm.h
@@ -12,7 +12,7 @@
  * be increased by sysctl
  */
 
-#define SHMMAX 0x2000000		 /* max shared seg size (bytes) */
+#define SHMMAX ULONG_MAX		 /* max shared seg size (bytes) */
 #define SHMMIN 1			 /* min shared seg size (bytes) */
 #define SHMMNI 4096			 /* max num of segs system wide */
 #ifndef __KERNEL__
-- 
1.9.0

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] ipc/shm: disable SHMALL, SHMMAX

[Davidlohr Bueso]

On Sat, 2014-04-12 at 13:48 +0200, Manfred Spraul wrote:
> Shared memory segment can be abused to trigger out-of-memory conditions and
> the standard measures against out-of-memory do not work:
> 
> - It is not possible to use setrlimit to limit the size of shm segments.
> 
> - Segments can exist without association with any processes, thus
>   the oom-killer is unable to free that memory.
> 
> Therefore Linux always limited the size of segments by default to 32 MB.
> As most systems do not need a protection against malicious user space apps,
> a default that forces most admins and distros to change it doesn't make
> sense.
> 
> The patch disables both limits by setting the limits to ULONG_MAX.
> 
> Admins who need a protection against out-of-memory conditions should
> reduce the limits again and/or enable shm_rmid_forced.
> 
> Davidlohr: What do you think?
> 
> I prefer this approach: No need to update the man pages, smaller change
> of the code, smaller risk of user space incompatibilities.

As I've mentioned before, both approaches are correct.

I still much prefer using 0 instead of ULONG_MAX, it's far easier to
understand. And considering the v2 which fixes the shmget(key, 0, flg)
usage, I _still_ don't see why it would cause legitimate user
incompatibilities.

Regarding the manpage, regardless the approach we end up taking, it
should still be updated. This is an important change for users, making
their life easier. We should inform them explicitly about them not
really needing to deal with the hassle of shm limits anymore.

Thanks,
Davidlohr

Re: [PATCH] ipc/shm: disable SHMALL, SHMMAX

[Davidlohr Bueso]

On Sat, 2014-04-12 at 13:48 +0200, Manfred Spraul wrote:
> Shared memory segment can be abused to trigger out-of-memory conditions and
> the standard measures against out-of-memory do not work:
> 
> - It is not possible to use setrlimit to limit the size of shm segments.
> 
> - Segments can exist without association with any processes, thus
>   the oom-killer is unable to free that memory.
> 
> Therefore Linux always limited the size of segments by default to 32 MB.
> As most systems do not need a protection against malicious user space apps,
> a default that forces most admins and distros to change it doesn't make
> sense.
> 
> The patch disables both limits by setting the limits to ULONG_MAX.
> 
> Admins who need a protection against out-of-memory conditions should
> reduce the limits again and/or enable shm_rmid_forced.
> 
> Davidlohr: What do you think?
> 
> I prefer this approach: No need to update the man pages, smaller change
> of the code, smaller risk of user space incompatibilities.

As I've mentioned before, both approaches are correct.

I still much prefer using 0 instead of ULONG_MAX, it's far easier to
understand. And considering the v2 which fixes the shmget(key, 0, flg)
usage, I _still_ don't see why it would cause legitimate user
incompatibilities.

Regarding the manpage, regardless the approach we end up taking, it
should still be updated. This is an important change for users, making
their life easier. We should inform them explicitly about them not
really needing to deal with the hassle of shm limits anymore.

Thanks,
Davidlohr

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [PATCH] ipc/shm: disable SHMALL, SHMMAX

[Davidlohr Bueso]

On Sat, 2014-04-12 at 08:39 -0700, Davidlohr Bueso wrote:
> On Sat, 2014-04-12 at 13:48 +0200, Manfred Spraul wrote:
> > Shared memory segment can be abused to trigger out-of-memory conditions and
> > the standard measures against out-of-memory do not work:
> > 
> > - It is not possible to use setrlimit to limit the size of shm segments.
> > 
> > - Segments can exist without association with any processes, thus
> >   the oom-killer is unable to free that memory.
> > 
> > Therefore Linux always limited the size of segments by default to 32 MB.
> > As most systems do not need a protection against malicious user space apps,
> > a default that forces most admins and distros to change it doesn't make
> > sense.
> > 
> > The patch disables both limits by setting the limits to ULONG_MAX.
> > 
> > Admins who need a protection against out-of-memory conditions should
> > reduce the limits again and/or enable shm_rmid_forced.
> > 
> > Davidlohr: What do you think?
> > 
> > I prefer this approach: No need to update the man pages, smaller change
> > of the code, smaller risk of user space incompatibilities.
> 
> As I've mentioned before, both approaches are correct.
> 
> I still much prefer using 0 instead of ULONG_MAX, it's far easier to
> understand. And considering the v2 which fixes the shmget(key, 0, flg)
> usage, I _still_ don't see why it would cause legitimate user
> incompatibilities.

Also, if the user overflows the variable (indicating that he/she wants
to increase it to reflect something 'unlimited') and it ends up being 0,
then it becomes a valid value, not something totally wrong as it is
today.

Re: [PATCH] ipc/shm: disable SHMALL, SHMMAX

[Davidlohr Bueso]

On Sat, 2014-04-12 at 08:39 -0700, Davidlohr Bueso wrote:
> On Sat, 2014-04-12 at 13:48 +0200, Manfred Spraul wrote:
> > Shared memory segment can be abused to trigger out-of-memory conditions and
> > the standard measures against out-of-memory do not work:
> > 
> > - It is not possible to use setrlimit to limit the size of shm segments.
> > 
> > - Segments can exist without association with any processes, thus
> >   the oom-killer is unable to free that memory.
> > 
> > Therefore Linux always limited the size of segments by default to 32 MB.
> > As most systems do not need a protection against malicious user space apps,
> > a default that forces most admins and distros to change it doesn't make
> > sense.
> > 
> > The patch disables both limits by setting the limits to ULONG_MAX.
> > 
> > Admins who need a protection against out-of-memory conditions should
> > reduce the limits again and/or enable shm_rmid_forced.
> > 
> > Davidlohr: What do you think?
> > 
> > I prefer this approach: No need to update the man pages, smaller change
> > of the code, smaller risk of user space incompatibilities.
> 
> As I've mentioned before, both approaches are correct.
> 
> I still much prefer using 0 instead of ULONG_MAX, it's far easier to
> understand. And considering the v2 which fixes the shmget(key, 0, flg)
> usage, I _still_ don't see why it would cause legitimate user
> incompatibilities.

Also, if the user overflows the variable (indicating that he/she wants
to increase it to reflect something 'unlimited') and it ends up being 0,
then it becomes a valid value, not something totally wrong as it is
today.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>