Re: [PATCH] libxl: fix build on rather old systems

Re: [PATCH] libxl: fix build on rather old systems

[Juergen Gross]

On 11/01/2019 11:09, Jan Beulich wrote:
> CLONE_NEWIPC has been introduced in Linux 2.6.19 only (and into glibc
> at around that time as well). Cope with it being undefined as well as
> with the underlying kernel not knowing of it.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Release-acked-by: Juergen Gross <jgross@suse.com>


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH] libxl: fix build on rather old systems

[Ian Jackson]

Juergen Gross writes ("Re: [PATCH] libxl: fix build on rather old systems"):
> On 11/01/2019 11:09, Jan Beulich wrote:
> > CLONE_NEWIPC has been introduced in Linux 2.6.19 only (and into glibc
> > at around that time as well). Cope with it being undefined as well as
> > with the underlying kernel not knowing of it.
> > 
> > Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> Release-acked-by: Juergen Gross <jgross@suse.com>

I know I am too slow with this, but for the record:

Nacked-by: Ian Jackson <ian.jackson@eu.citrix.com>

On two grounds:

 1. This situation should be handled by disabling the dm restrict
    feature, not silently falling back to lower protection.

 2. Style, #ifdeffery.

I don't agree that the unshare of the IPC namespace is a `nice to
have'.  Without it, a rogue qemu might be able to do a number of bad
things.

Background: AIUI in kernels without CLONE_NEWIPC, the IPC namespace is
shared with the network namespace.  But of course what matters is what
the *runtime* kernel supports, not the build-time kernel.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH 1/2] Revert "libxl: fix build on rather old systems"

[Ian Jackson]

This reverts commit 1bce5f9baf0f4a4e50722f32b44afe4fdefc6b35.

This situation should be handled by disabling the dm restrict
feature, not silently falling back to lower protection.

Also this #ifdeffery is bad style.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_linux.c | 16 ++--------------
 1 file changed, 2 insertions(+), 14 deletions(-)

diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c
index a4c2f28dbf..6475cca64b 100644
--- a/tools/libxl/libxl_linux.c
+++ b/tools/libxl/libxl_linux.c
@@ -334,24 +334,12 @@ int libxl__local_dm_preexec_restrict(libxl__gc *gc)
     unsigned i;
 
     /* Unshare mount and IPC namespaces.  These are unused by QEMU. */
-    r = unshare(CLONE_NEWNS);
+    r = unshare(CLONE_NEWNS | CLONE_NEWIPC);
     if (r) {
-        LOGE(ERROR, "libxl: Mount namespace unshare failed");
+        LOGE(ERROR, "libxl: Mount and IPC namespace unfailed");
         return ERROR_FAIL;
     }
 
-#ifndef CLONE_NEWIPC /* Available as of Linux 2.6.19 / glibc 2.8 */
-# define CLONE_NEWIPC 0x08000000
-#endif
-    r = unshare(CLONE_NEWIPC);
-    if (r) {
-        if (r && errno != EINVAL) {
-            LOGE(ERROR, "libxl: IPC namespace unshare failed");
-            return ERROR_FAIL;
-        }
-        LOG(WARN, "libxl: IPC namespace unshare unavailable");
-    }
-
     /* Set various "easy" rlimits */
     for (i = 0; rlimits[i].resource != RLIMIT_NLIMITS; i++) {
         struct rlimit rlim;
-- 
2.11.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH 2/2] libxl: fix build (missing CLONE_NEWIPC) on astonishingly old systems

[Ian Jackson]

CLONE_NEWIPC was introduced in Linux 2.6.19, on the 29th of November
2006, which was 12 years, 1 month, and 14 days ago.

Nevertheless apparently some people are trying to build Xen on systems
whose kernel headers are that old.  Placate these people by providing
a fallback #define for CLONE_NEWIPC.

The actual binary value will of course remain constant, because of the
kernel API promise, so this is and will be correct on all platforms
where the CLONE_NEWIPC is supported.  (Even if for some reason we miss
the right #includes.)

Of course at runtime this value will not work on older kernels.  It
will be rejected as unknown.  However on those kernels we do not want
to support dm_restrict, and an attempt to use it will fail.  It is OK
for the failure to be a messy EINVAL syscall failure.  (The IPC
namespace unshare is necessary to avoid a suborned deprivileged qemu
from causing trouble with shm, sem, etc.)

CC: Wei Liu <wei.liu2@citrix.com>
CC: Juergen Gross <jgross@suse.com>
CC: Jan Beulich <JBeulich@suse.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_linux.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c
index 6475cca64b..51539ade20 100644
--- a/tools/libxl/libxl_linux.c
+++ b/tools/libxl/libxl_linux.c
@@ -18,6 +18,14 @@
 #include <sys/resource.h>
 #include "libxl_internal.h"
 
+
+/* Workarounds for Linux-specific lacks can go here: */
+
+#ifndef CLONE_XNEWIPC /* Available as of Linux 2.6.19 / glibc 2.8 */
+# define CLONE_NEWIPC 0x08000000
+#endif
+
+
 int libxl__try_phy_backend(mode_t st_mode)
 {
     if (S_ISBLK(st_mode) || S_ISREG(st_mode)) {
-- 
2.11.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 2/2] libxl: fix build (missing CLONE_NEWIPC) on astonishingly old systems

[Anthony PERARD]

On Fri, Jan 11, 2019 at 06:12:11PM +0000, Ian Jackson wrote:
> +#ifndef CLONE_XNEWIPC /* Available as of Linux 2.6.19 / glibc 2.8 */

There's a strange X here, but not below.

> +# define CLONE_NEWIPC 0x08000000

-- 
Anthony PERARD

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 2/2] libxl: fix build (missing CLONE_NEWIPC) on astonishingly old systems

[Ian Jackson]

Anthony PERARD writes ("Re: [Xen-devel] [PATCH 2/2] libxl: fix build (missing CLONE_NEWIPC) on astonishingly old systems"):
> On Fri, Jan 11, 2019 at 06:12:11PM +0000, Ian Jackson wrote:
> > +#ifndef CLONE_XNEWIPC /* Available as of Linux 2.6.19 / glibc 2.8 */
> 
> There's a strange X here, but not below.

Erk, that's wrong.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH v2 2/2] libxl: fix build (missing CLONE_NEWIPC) on astonishingly old systems

[Ian Jackson]

CLONE_NEWIPC was introduced in Linux 2.6.19, on the 29th of November
2006, which was 12 years, 1 month, and 14 days ago.

Nevertheless apparently some people are trying to build Xen on systems
whose kernel headers are that old.  Placate these people by providing
a fallback #define for CLONE_NEWIPC.

The actual binary value will of course remain constant, because of the
kernel API promise, so this is and will be correct on all platforms
where the CLONE_NEWIPC is supported.  (Even if for some reason we miss
the right #includes.)

Of course at runtime this value will not work on older kernels.  It
will be rejected as unknown.  However on those kernels we do not want
to support dm_restrict, and an attempt to use it will fail.  It is OK
for the failure to be a messy EINVAL syscall failure.  (The IPC
namespace unshare is necessary to avoid a suborned deprivileged qemu
from causing trouble with shm, sem, etc.)

CC: Wei Liu <wei.liu2@citrix.com>
CC: Juergen Gross <jgross@suse.com>
CC: Jan Beulich <JBeulich@suse.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

---
v2: Get rid of spurious X
---
 tools/libxl/libxl_linux.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c
index 6475cca64b..59dd945bc1 100644
--- a/tools/libxl/libxl_linux.c
+++ b/tools/libxl/libxl_linux.c
@@ -18,6 +18,14 @@
 #include <sys/resource.h>
 #include "libxl_internal.h"
 
+
+/* Workarounds for Linux-specific lacks can go here: */
+
+#ifndef CLONE_NEWIPC /* Available as of Linux 2.6.19 / glibc 2.8 */
+# define CLONE_NEWIPC 0x08000000
+#endif
+
+
 int libxl__try_phy_backend(mode_t st_mode)
 {
     if (S_ISBLK(st_mode) || S_ISREG(st_mode)) {
-- 
2.11.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v2 2/2] libxl: fix build (missing CLONE_NEWIPC) on astonishingly old systems

[Jan Beulich]

>>> On 11.01.19 at 20:23, <ian.jackson@eu.citrix.com> wrote:
> CLONE_NEWIPC was introduced in Linux 2.6.19, on the 29th of November
> 2006, which was 12 years, 1 month, and 14 days ago.

Thanks for the very precise counting, the latter part which will be
wrong - even if just slightly - by the time you commit it ;-)

> Nevertheless apparently some people are trying to build Xen on systems
> whose kernel headers are that old.  Placate these people by providing
> a fallback #define for CLONE_NEWIPC.
> 
> The actual binary value will of course remain constant, because of the
> kernel API promise, so this is and will be correct on all platforms
> where the CLONE_NEWIPC is supported.  (Even if for some reason we miss
> the right #includes.)
> 
> Of course at runtime this value will not work on older kernels.  It
> will be rejected as unknown.

Sadly the situation is more complicated: The check to disallow
unknown flags was introduced only in 2.6.17 [1], and apparently
never backported to 2.6.16 or older stable trees despite the
description talking about it going into 2.6.16. Since it didn't
matter in my variant of the workaround, I didn't mention this.

Of course a pretty reasonable position to take would be to
consider the 2.6.18-based XenoLinux tree a "baseline", beyond
which we don't care about undesirable behavior here.

Jan

[1] 06f9d4f94a unshare: Error if passed unsupported flags



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v2 2/2] libxl: fix build (missing CLONE_NEWIPC) on astonishingly old systems

[Wei Liu]

On Mon, Jan 14, 2019 at 02:47:58AM -0700, Jan Beulich wrote:
> >>> On 11.01.19 at 20:23, <ian.jackson@eu.citrix.com> wrote:
> > CLONE_NEWIPC was introduced in Linux 2.6.19, on the 29th of November
> > 2006, which was 12 years, 1 month, and 14 days ago.
> 
> Thanks for the very precise counting, the latter part which will be
> wrong - even if just slightly - by the time you commit it ;-)
> 
> > Nevertheless apparently some people are trying to build Xen on systems
> > whose kernel headers are that old.  Placate these people by providing
> > a fallback #define for CLONE_NEWIPC.
> > 
> > The actual binary value will of course remain constant, because of the
> > kernel API promise, so this is and will be correct on all platforms
> > where the CLONE_NEWIPC is supported.  (Even if for some reason we miss
> > the right #includes.)
> > 
> > Of course at runtime this value will not work on older kernels.  It
> > will be rejected as unknown.
> 
> Sadly the situation is more complicated: The check to disallow
> unknown flags was introduced only in 2.6.17 [1], and apparently
> never backported to 2.6.16 or older stable trees despite the
> description talking about it going into 2.6.16. Since it didn't
> matter in my variant of the workaround, I didn't mention this.
> 
> Of course a pretty reasonable position to take would be to
> consider the 2.6.18-based XenoLinux tree a "baseline", beyond
> which we don't care about undesirable behavior here.

I think using 2.6.18 as baseline is very reasonable. 

Wei.

> 
> Jan
> 
> [1] 06f9d4f94a unshare: Error if passed unsupported flags
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v2 2/2] libxl: fix build (missing CLONE_NEWIPC) on astonishingly old systems

[Ian Jackson]

Wei Liu writes ("Re: [PATCH v2 2/2] libxl: fix build (missing CLONE_NEWIPC) on astonishingly old systems"):
> On Mon, Jan 14, 2019 at 02:47:58AM -0700, Jan Beulich wrote:
> > On 11.01.19 at 20:23, <ian.jackson@eu.citrix.com> wrote:
> > > CLONE_NEWIPC was introduced in Linux 2.6.19, on the 29th of November
> > > 2006, which was 12 years, 1 month, and 14 days ago.
> > 
> > Thanks for the very precise counting, the latter part which will be
> > wrong - even if just slightly - by the time you commit it ;-)
...
> > Sadly the situation is more complicated: The check to disallow
> > unknown flags was introduced only in 2.6.17 [1], and apparently
> > never backported to 2.6.16 or older stable trees despite the
> > description talking about it going into 2.6.16. Since it didn't
> > matter in my variant of the workaround, I didn't mention this.

Good grief.

> > Of course a pretty reasonable position to take would be to
> > consider the 2.6.18-based XenoLinux tree a "baseline", beyond
> > which we don't care about undesirable behavior here.
> 
> I think using 2.6.18 as baseline is very reasonable. 

I guess we need to write this in the SUPPORT.md statement for
dm_restrict.

TBH how about writing somewhere general in SUPPORT.md that "all bets
are off if you use Linux before 2.6.18" ?  Do we even have a limit
anywhere for security supported Linux versions ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v2 2/2] libxl: fix build (missing CLONE_NEWIPC) on astonishingly old systems

[Jan Beulich]

>>> On 14.01.19 at 15:22, <ian.jackson@citrix.com> wrote:
> Wei Liu writes ("Re: [PATCH v2 2/2] libxl: fix build (missing CLONE_NEWIPC) 
> on astonishingly old systems"):
>> On Mon, Jan 14, 2019 at 02:47:58AM -0700, Jan Beulich wrote:
>> > On 11.01.19 at 20:23, <ian.jackson@eu.citrix.com> wrote:
>> > > CLONE_NEWIPC was introduced in Linux 2.6.19, on the 29th of November
>> > > 2006, which was 12 years, 1 month, and 14 days ago.
>> > 
>> > Thanks for the very precise counting, the latter part which will be
>> > wrong - even if just slightly - by the time you commit it ;-)
> ...
>> > Sadly the situation is more complicated: The check to disallow
>> > unknown flags was introduced only in 2.6.17 [1], and apparently
>> > never backported to 2.6.16 or older stable trees despite the
>> > description talking about it going into 2.6.16. Since it didn't
>> > matter in my variant of the workaround, I didn't mention this.
> 
> Good grief.
> 
>> > Of course a pretty reasonable position to take would be to
>> > consider the 2.6.18-based XenoLinux tree a "baseline", beyond
>> > which we don't care about undesirable behavior here.
>> 
>> I think using 2.6.18 as baseline is very reasonable. 
> 
> I guess we need to write this in the SUPPORT.md statement for
> dm_restrict.

Ah yes, we should.

> TBH how about writing somewhere general in SUPPORT.md that "all bets
> are off if you use Linux before 2.6.18" ?  Do we even have a limit
> anywhere for security supported Linux versions ?

I don't think so, and leaving this specific case aside it's also
unclear to me why we should.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH v3 1/3] docs/features/qemu-deprivilege.pandoc: No support with Linux <2.6.18

[Ian Jackson]

Some early kernesl are known not to reject unknown flags to
unshare().  There may be other problems.

CC: Jan Beulich <JBeulich@suse.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
v3: New in this version of the series.
---
 docs/features/qemu-deprivilege.pandoc | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/docs/features/qemu-deprivilege.pandoc b/docs/features/qemu-deprivilege.pandoc
index eb05981a83..20d6ac2189 100644
--- a/docs/features/qemu-deprivilege.pandoc
+++ b/docs/features/qemu-deprivilege.pandoc
@@ -112,6 +112,9 @@ The following features still need to be implemented:
  * Inserting a new cdrom while the guest is running (xl cdrom-insert)
  * Migration / save / restore
 
+dm_restrict is totally unsupported and may have unexpected security
+problems if used with a dom0 Linux kernel earlier than 2.6.18.
+
 Additionally, getting PCI passthrough to work securely would require a
 significant rework of how passthrough works at the moment.  It may be
 implemented at some point but is not a near-term priority.
-- 
2.11.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH v3 2/3] Revert "libxl: fix build on rather old systems"

[Ian Jackson]

This reverts commit 1bce5f9baf0f4a4e50722f32b44afe4fdefc6b35.

This situation should be handled by disabling the dm restrict
feature, not silently falling back to lower protection.

Also this #ifdeffery is bad style.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
---
 tools/libxl/libxl_linux.c | 16 ++--------------
 1 file changed, 2 insertions(+), 14 deletions(-)

diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c
index a4c2f28dbf..6475cca64b 100644
--- a/tools/libxl/libxl_linux.c
+++ b/tools/libxl/libxl_linux.c
@@ -334,24 +334,12 @@ int libxl__local_dm_preexec_restrict(libxl__gc *gc)
     unsigned i;
 
     /* Unshare mount and IPC namespaces.  These are unused by QEMU. */
-    r = unshare(CLONE_NEWNS);
+    r = unshare(CLONE_NEWNS | CLONE_NEWIPC);
     if (r) {
-        LOGE(ERROR, "libxl: Mount namespace unshare failed");
+        LOGE(ERROR, "libxl: Mount and IPC namespace unfailed");
         return ERROR_FAIL;
     }
 
-#ifndef CLONE_NEWIPC /* Available as of Linux 2.6.19 / glibc 2.8 */
-# define CLONE_NEWIPC 0x08000000
-#endif
-    r = unshare(CLONE_NEWIPC);
-    if (r) {
-        if (r && errno != EINVAL) {
-            LOGE(ERROR, "libxl: IPC namespace unshare failed");
-            return ERROR_FAIL;
-        }
-        LOG(WARN, "libxl: IPC namespace unshare unavailable");
-    }
-
     /* Set various "easy" rlimits */
     for (i = 0; rlimits[i].resource != RLIMIT_NLIMITS; i++) {
         struct rlimit rlim;
-- 
2.11.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH v3 3/3] libxl: fix build (missing CLONE_NEWIPC) on astonishingly old systems

[Ian Jackson]

CLONE_NEWIPC was introduced in Linux 2.6.19, on the 29th of November
2006, which was 12 years, 1 month, and 14 days ago.

Nevertheless apparently some people are trying to build Xen on systems
whose kernel headers are that old.  Placate these people by providing
a fallback #define for CLONE_NEWIPC.

The actual binary value will of course remain constant, because of the
kernel API promise, so this is and will be correct on all platforms
where the CLONE_NEWIPC is supported.  (Even if for some reason we miss
the right #includes.)

Of course at runtime this value will not work on older kernels.  It
will be rejected as unknown by anything except some pre-2.6.18
kernels.  On those kernels we do not want to support dm_restrict, and
an attempt to use it will fail.  It is OK for the failure to be a
messy EINVAL syscall failure.  (The IPC namespace unshare is necessary
to avoid a suborned deprivileged qemu from causing trouble with shm,
sem, etc.)

On the very old kernels, the feature is totally out of scope.
(We are only interested, here, in making the build work, to avoid
blocking people who aren't using this feature.)

CC: Wei Liu <wei.liu2@citrix.com>
CC: Juergen Gross <jgross@suse.com>
CC: Jan Beulich <JBeulich@suse.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

---
v3: Adjust commit message with facts about some even older kernels
v2: Get rid of spurious X
---
 tools/libxl/libxl_linux.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/tools/libxl/libxl_linux.c b/tools/libxl/libxl_linux.c
index 6475cca64b..59dd945bc1 100644
--- a/tools/libxl/libxl_linux.c
+++ b/tools/libxl/libxl_linux.c
@@ -18,6 +18,14 @@
 #include <sys/resource.h>
 #include "libxl_internal.h"
 
+
+/* Workarounds for Linux-specific lacks can go here: */
+
+#ifndef CLONE_NEWIPC /* Available as of Linux 2.6.19 / glibc 2.8 */
+# define CLONE_NEWIPC 0x08000000
+#endif
+
+
 int libxl__try_phy_backend(mode_t st_mode)
 {
     if (S_ISBLK(st_mode) || S_ISREG(st_mode)) {
-- 
2.11.0


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v3 1/3] docs/features/qemu-deprivilege.pandoc: No support with Linux <2.6.18

[Wei Liu]

On Mon, Jan 14, 2019 at 02:59:35PM +0000, Ian Jackson wrote:
> Some early kernesl are known not to reject unknown flags to
> unshare().  There may be other problems.
> 
> CC: Jan Beulich <JBeulich@suse.com>
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

Acked-by: Wei Liu <wei.liu2@citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v3 2/3] Revert "libxl: fix build on rather old systems"

[Wei Liu]

On Mon, Jan 14, 2019 at 02:59:36PM +0000, Ian Jackson wrote:
> This reverts commit 1bce5f9baf0f4a4e50722f32b44afe4fdefc6b35.
> 
> This situation should be handled by disabling the dm restrict
> feature, not silently falling back to lower protection.
> 
> Also this #ifdeffery is bad style.
> 
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>


Acked-by: Wei Liu <wei.liu2@citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v3 3/3] libxl: fix build (missing CLONE_NEWIPC) on astonishingly old systems

[Wei Liu]

On Mon, Jan 14, 2019 at 02:59:37PM +0000, Ian Jackson wrote:
> CLONE_NEWIPC was introduced in Linux 2.6.19, on the 29th of November
> 2006, which was 12 years, 1 month, and 14 days ago.
> 
> Nevertheless apparently some people are trying to build Xen on systems
> whose kernel headers are that old.  Placate these people by providing
> a fallback #define for CLONE_NEWIPC.
> 
> The actual binary value will of course remain constant, because of the
> kernel API promise, so this is and will be correct on all platforms
> where the CLONE_NEWIPC is supported.  (Even if for some reason we miss
> the right #includes.)
> 
> Of course at runtime this value will not work on older kernels.  It
> will be rejected as unknown by anything except some pre-2.6.18
> kernels.  On those kernels we do not want to support dm_restrict, and
> an attempt to use it will fail.  It is OK for the failure to be a
> messy EINVAL syscall failure.  (The IPC namespace unshare is necessary
> to avoid a suborned deprivileged qemu from causing trouble with shm,
> sem, etc.)
> 
> On the very old kernels, the feature is totally out of scope.
> (We are only interested, here, in making the build work, to avoid
> blocking people who aren't using this feature.)
> 
> CC: Wei Liu <wei.liu2@citrix.com>
> CC: Juergen Gross <jgross@suse.com>
> CC: Jan Beulich <JBeulich@suse.com>
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 

Acked-by: Wei Liu <wei.liu2@citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH v3 1/3] docs/features/qemu-deprivilege.pandoc: No support with Linux <2.6.18

[Juergen Gross]

On 14/01/2019 15:59, Ian Jackson wrote:
> Some early kernesl are known not to reject unknown flags to

s/kernesl/kernels/

> unshare().  There may be other problems.
> 
> CC: Jan Beulich <JBeulich@suse.com>
> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

For the series:

Release-acked-by: Juergen Gross <jgross@suse.com>


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel