[PATCH] libxl: fix build on rather old systems

[PATCH] libxl: fix build on rather old systems

[Jan Beulich]

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>
---
Considering how old "old" here really means, I could understand if
this was rejected, in which case I'd carry a simplified version locally.
I don't run such old kernels together with modern Xen, but I do
occasionally build on such old systems.

--- a/tools/libxl/libxl_linux.c
+++ b/tools/libxl/libxl_linux.c
@@ -334,12 +334,24 @@ int libxl__local_dm_preexec_restrict(lib
     unsigned i;
 
     /* Unshare mount and IPC namespaces.  These are unused by QEMU. */
-    r = unshare(CLONE_NEWNS | CLONE_NEWIPC);
+    r = unshare(CLONE_NEWNS);
     if (r) {
-        LOGE(ERROR, "libxl: Mount and IPC namespace unfailed");
+        LOGE(ERROR, "libxl: Mount namespace unshare failed");
         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;





_______________________________________________
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

[Wei Liu]

On Fri, Jan 11, 2019 at 03:09:35AM -0700, 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>
> ---
> Considering how old "old" here really means, I could understand if
> this was rejected, in which case I'd carry a simplified version locally.
> I don't run such old kernels together with modern Xen, but I do
> occasionally build on such old systems.
> 
> --- a/tools/libxl/libxl_linux.c
> +++ b/tools/libxl/libxl_linux.c
> @@ -334,12 +334,24 @@ int libxl__local_dm_preexec_restrict(lib
>      unsigned i;
>  
>      /* Unshare mount and IPC namespaces.  These are unused by QEMU. */
> -    r = unshare(CLONE_NEWNS | CLONE_NEWIPC);
> +    r = unshare(CLONE_NEWNS);
>      if (r) {
> -        LOGE(ERROR, "libxl: Mount and IPC namespace unfailed");
> +        LOGE(ERROR, "libxl: Mount namespace unshare failed");
>          return ERROR_FAIL;
>      }
>  
> +#ifndef CLONE_NEWIPC /* Available as of Linux 2.6.19 / glibc 2.8 */
> +# define CLONE_NEWIPC 0x08000000

I have no problem making it build with this.

> +#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");

But I guess whether it should be allowed to continue or not is another
question. Do we consider this IPC namespace "must-have"?

CC George as well.

Wei.

> +    }
> +
>      /* Set various "easy" rlimits */
>      for (i = 0; rlimits[i].resource != RLIMIT_NLIMITS; i++) {
>          struct rlimit rlim;
> 
> 
> 
> 

_______________________________________________
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

[Jan Beulich]

>>> On 11.01.19 at 12:18, <wei.liu2@citrix.com> wrote:
> On Fri, Jan 11, 2019 at 03:09:35AM -0700, 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>
>> ---
>> Considering how old "old" here really means, I could understand if
>> this was rejected, in which case I'd carry a simplified version locally.
>> I don't run such old kernels together with modern Xen, but I do
>> occasionally build on such old systems.
>> 
>> --- a/tools/libxl/libxl_linux.c
>> +++ b/tools/libxl/libxl_linux.c
>> @@ -334,12 +334,24 @@ int libxl__local_dm_preexec_restrict(lib
>>      unsigned i;
>>  
>>      /* Unshare mount and IPC namespaces.  These are unused by QEMU. */
>> -    r = unshare(CLONE_NEWNS | CLONE_NEWIPC);
>> +    r = unshare(CLONE_NEWNS);
>>      if (r) {
>> -        LOGE(ERROR, "libxl: Mount and IPC namespace unfailed");
>> +        LOGE(ERROR, "libxl: Mount namespace unshare failed");
>>          return ERROR_FAIL;
>>      }
>>  
>> +#ifndef CLONE_NEWIPC /* Available as of Linux 2.6.19 / glibc 2.8 */
>> +# define CLONE_NEWIPC 0x08000000
> 
> I have no problem making it build with this.
> 
>> +#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");
> 
> But I guess whether it should be allowed to continue or not is another
> question. Do we consider this IPC namespace "must-have"?

Well, there simply can't be different namespaces to switch between
when the kernel doesn't understand the flag.

Jan



_______________________________________________
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

[Wei Liu]

On Fri, Jan 11, 2019 at 04:24:35AM -0700, Jan Beulich wrote:
[...]
> > 
> >> +#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");
> > 
> > But I guess whether it should be allowed to continue or not is another
> > question. Do we consider this IPC namespace "must-have"?
> 
> Well, there simply can't be different namespaces to switch between
> when the kernel doesn't understand the flag.
> 

... which means the isolation property is weaken by the lack of IPC
namespace.

If we don't want to weaken isolation, not allowing it to continue is the
right thing to do -- that means the hunk to split IPC namespace to
separate call is not necessary. If we would rather lower the isolation
guarantee provided, then this hunk needs to stay.

Wei.

> Jan
> 
> 

_______________________________________________
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

[George Dunlap]

> On Jan 11, 2019, at 9:18 PM, Wei Liu <wei.liu2@citrix.com> wrote:
> 
> On Fri, Jan 11, 2019 at 03:09:35AM -0700, 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>
>> ---
>> Considering how old "old" here really means, I could understand if
>> this was rejected, in which case I'd carry a simplified version locally.
>> I don't run such old kernels together with modern Xen, but I do
>> occasionally build on such old systems.

But why do you build on it if you don’t run it?

>> 
>> --- a/tools/libxl/libxl_linux.c
>> +++ b/tools/libxl/libxl_linux.c
>> @@ -334,12 +334,24 @@ int libxl__local_dm_preexec_restrict(lib
>>     unsigned i;
>> 
>>     /* Unshare mount and IPC namespaces.  These are unused by QEMU. */
>> -    r = unshare(CLONE_NEWNS | CLONE_NEWIPC);
>> +    r = unshare(CLONE_NEWNS);
>>     if (r) {
>> -        LOGE(ERROR, "libxl: Mount and IPC namespace unfailed");
>> +        LOGE(ERROR, "libxl: Mount namespace unshare failed");
>>         return ERROR_FAIL;
>>     }
>> 
>> +#ifndef CLONE_NEWIPC /* Available as of Linux 2.6.19 / glibc 2.8 */
>> +# define CLONE_NEWIPC 0x08000000
> 
> I have no problem making it build with this.
> 
>> +#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");
> 
> But I guess whether it should be allowed to continue or not is another
> question. Do we consider this IPC namespace "must-have”?

On the contrary, the mount and IPC namespaces are “might-as-well” (or perhaps, “why-not-it-cant-hurt”).

I don’t really see any point making something build on a system that you’re not going to run it on; but I don’t feel strongly enough to do more than say so.  I’ll leave it up to the toolstack maintainers.

 -George
_______________________________________________
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

[Wei Liu]

On Fri, Jan 11, 2019 at 12:06:59PM +0000, George Dunlap wrote:
> 
> 
> > On Jan 11, 2019, at 9:18 PM, Wei Liu <wei.liu2@citrix.com> wrote:
> > 
> > On Fri, Jan 11, 2019 at 03:09:35AM -0700, 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>
> >> ---
> >> Considering how old "old" here really means, I could understand if
> >> this was rejected, in which case I'd carry a simplified version locally.
> >> I don't run such old kernels together with modern Xen, but I do
> >> occasionally build on such old systems.
> 
> But why do you build on it if you don’t run it?
> 

It isn't uncommon to have separate build setup. But I guess haven't a
rather old build setup but run the software on a newer setup is
uncommon.

> >> 
> >> --- a/tools/libxl/libxl_linux.c
> >> +++ b/tools/libxl/libxl_linux.c
> >> @@ -334,12 +334,24 @@ int libxl__local_dm_preexec_restrict(lib
> >>     unsigned i;
> >> 
> >>     /* Unshare mount and IPC namespaces.  These are unused by QEMU. */
> >> -    r = unshare(CLONE_NEWNS | CLONE_NEWIPC);
> >> +    r = unshare(CLONE_NEWNS);
> >>     if (r) {
> >> -        LOGE(ERROR, "libxl: Mount and IPC namespace unfailed");
> >> +        LOGE(ERROR, "libxl: Mount namespace unshare failed");
> >>         return ERROR_FAIL;
> >>     }
> >> 
> >> +#ifndef CLONE_NEWIPC /* Available as of Linux 2.6.19 / glibc 2.8 */
> >> +# define CLONE_NEWIPC 0x08000000
> > 
> > I have no problem making it build with this.
> > 
> >> +#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");
> > 
> > But I guess whether it should be allowed to continue or not is another
> > question. Do we consider this IPC namespace "must-have”?
> 
> On the contrary, the mount and IPC namespaces are “might-as-well” (or perhaps, “why-not-it-cant-hurt”).
> 
> I don’t really see any point making something build on a system that you’re not going to run it on; but I don’t feel strongly enough to do more than say so.  I’ll leave it up to the toolstack maintainers.

Fine then. I interpret this as "IPC namespace is not a must-have".
I think Jan's patch is fine. I will have a closer look in the afternoon.

Wei.

> 
>  -George

_______________________________________________
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

[Wei Liu]

On Fri, Jan 11, 2019 at 03:09:35AM -0700, 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>

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] libxl: fix build on rather old systems

[Jan Beulich]

>>> On 11.01.19 at 13:06, <George.Dunlap@citrix.com> wrote:
>> On Jan 11, 2019, at 9:18 PM, Wei Liu <wei.liu2@citrix.com> wrote:
>> On Fri, Jan 11, 2019 at 03:09:35AM -0700, 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>
>>> ---
>>> Considering how old "old" here really means, I could understand if
>>> this was rejected, in which case I'd carry a simplified version locally.
>>> I don't run such old kernels together with modern Xen, but I do
>>> occasionally build on such old systems.
> 
> But why do you build on it if you don’t run it?

I also run it there, just not with as old a kernel as the system headers
represent.

Jan


_______________________________________________
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

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