user-mode-linux-user

Re: [uml-user] Could UML run via seccomp traps instead of ptrace?

[Richard W. <ric...@gm...>]

Dan,

On Mon, May 22, 2017 at 12:39 AM, Dan Kaminsky <da...@wh...> wrote:
> The thinking is we'd add another SECCOMP_RET type, such that UML didn't need
> to depend on ptrace.  Ptrace isn't the fastest mechanism, and beyond that,
> if we can avoid it it's a lot easier to syscall firewall UML as a whole (and
> freeze/restore it with CRIU).

Beside of PTRACE_SYSEMU UML also needs ptrace() for ton of other things,
i.e. register read/restore or copy_from/to_user().
So, we won't get rid of ptrace() completely.

I'm not sure whether switching from PTRACE_SYSEMU to seccomp will speed things
up. Do you have some numbers?

-- 
Thanks,
//richard

Re: [uml-user] Could UML run via seccomp traps instead of ptrace?

[Dan K. <da...@wh...>]

The thinking is we'd add another SECCOMP_RET type, such that UML didn't
need to depend on ptrace.  Ptrace isn't the fastest mechanism, and beyond
that, if we can avoid it it's a lot easier to syscall firewall UML as a
whole (and freeze/restore it with CRIU).

On Sat, May 13, 2017 at 3:13 AM, Thomas Meyer <th...@m3...> wrote:

> Hello!
>>
>
> Hi,
>
>    So I've been spending some time in UML (among other virtualization
>> technologies).  There's some interesting security and performance models
>> it
>> possibly allows, even in this era of containers and hypervisors.  Ptrace
>> is
>> being something of a problem though; it's a little hairy and difficult to
>> scope.  It is unfortunately breaking many things I'm trying to do.
>>
>>     So I'm curious.  There is another option -- seccomp-bpf can trap on
>> arbitrary syscalls.  Is there a reason anyone sees why UML couldn't be
>> routed through it?
>>
>
> I had a look at this and I think it could work.
>
> But what mode would you suggest?
>
> a.) SECCOMP_RET_TRAP
> Each usermode process would receive an SIGSYS and forward it to the kernel
> process somehow? and continue afterwards.
>
> b.) SECCOMP_RET_TRACE
> the kernel process would still ptrace each usermode process and intercept
> all syscalls?
> What would be the difference to the current mode of operation? what would
> we gain here?
>
> with kind regards
> thomas
>
>
>
>

Re: [uml-user] [RFC][PATCH] um: Remove proc command from mconsole

[Al V. <vi...@Ze...>]

On Sun, May 21, 2017 at 11:19:03PM +0200, Richard Weinberger wrote:
> This feature is another abuser of set_fs().
> Reading proc files from the host side is a debugging feature
> with no security checks at all. The path is not sanitized, therefore
> any file could be read.

ITYM "any file on procfs"

> Let's get rid of it.

Wait a sec - guest is not protected against anyone with mconsole access
anyway.

> Unless I miss something is feature is not ABI since it was addeded for
> debugging UML only. It is broken wrt. security and abuses set_fs().
> I think we can just remove it.

IDGI.  set_fs() abuses are trivial - just switch to kernel_read() and
be done with that...

[uml-user] [RFC][PATCH] um: Remove proc command from mconsole

[Richard W. <ri...@no...>]

This feature is another abuser of set_fs().
Reading proc files from the host side is a debugging feature
with no security checks at all. The path is not sanitized, therefore
any file could be read.
Let's get rid of it.

Signed-off-by: Richard Weinberger <ri...@no...>
---
Hi!

Unless I miss something is feature is not ABI since it was addeded for
debugging UML only. It is broken wrt. security and abuses set_fs().
I think we can just remove it.

mconsole_proc anyone? ;)

Thanks,
//richard

---

 arch/um/drivers/mconsole_kern.c | 52 -----------------------------------------
 arch/um/drivers/mconsole_user.c |  1 -
 2 files changed, 53 deletions(-)

diff --git a/arch/um/drivers/mconsole_kern.c b/arch/um/drivers/mconsole_kern.c
index af326fb6510d..b7fedf77f9f3 100644
--- a/arch/um/drivers/mconsole_kern.c
+++ b/arch/um/drivers/mconsole_kern.c
@@ -122,57 +122,6 @@ void mconsole_log(struct mc_request *req)
 	mconsole_reply(req, "", 0, 0);
 }
 
-void mconsole_proc(struct mc_request *req)
-{
-	struct vfsmount *mnt = task_active_pid_ns(current)->proc_mnt;
-	char *buf;
-	int len;
-	struct file *file;
-	int first_chunk = 1;
-	char *ptr = req->request.data;
-
-	ptr += strlen("proc");
-	ptr = skip_spaces(ptr);
-
-	file = file_open_root(mnt->mnt_root, mnt, ptr, O_RDONLY, 0);
-	if (IS_ERR(file)) {
-		mconsole_reply(req, "Failed to open file", 1, 0);
-		printk(KERN_ERR "open /proc/%s: %ld\n", ptr, PTR_ERR(file));
-		goto out;
-	}
-
-	buf = kmalloc(PAGE_SIZE, GFP_KERNEL);
-	if (buf == NULL) {
-		mconsole_reply(req, "Failed to allocate buffer", 1, 0);
-		goto out_fput;
-	}
-
-	do {
-		loff_t pos = file->f_pos;
-		mm_segment_t old_fs = get_fs();
-		set_fs(KERNEL_DS);
-		len = vfs_read(file, buf, PAGE_SIZE - 1, &pos);
-		set_fs(old_fs);
-		file->f_pos = pos;
-		if (len < 0) {
-			mconsole_reply(req, "Read of file failed", 1, 0);
-			goto out_free;
-		}
-		/* Begin the file content on his own line. */
-		if (first_chunk) {
-			mconsole_reply(req, "\n", 0, 1);
-			first_chunk = 0;
-		}
-		buf[len] = '\0';
-		mconsole_reply(req, buf, 0, (len > 0));
-	} while (len > 0);
- out_free:
-	kfree(buf);
- out_fput:
-	fput(file);
- out: ;
-}
-
 #define UML_MCONSOLE_HELPTEXT \
 "Commands: \n\
     version - Get kernel version \n\
@@ -188,7 +137,6 @@ void mconsole_proc(struct mc_request *req)
     stop - pause the UML; it will do nothing until it receives a 'go' \n\
     go - continue the UML after a 'stop' \n\
     log <string> - make UML enter <string> into the kernel log\n\
-    proc <file> - returns the contents of the UML's /proc/<file>\n\
     stack <pid> - returns the stack of the specified pid\n\
 "
 
diff --git a/arch/um/drivers/mconsole_user.c b/arch/um/drivers/mconsole_user.c
index 99209826adb1..59d81d7ead58 100644
--- a/arch/um/drivers/mconsole_user.c
+++ b/arch/um/drivers/mconsole_user.c
@@ -30,7 +30,6 @@ static struct mconsole_command commands[] = {
 	{ "stop", mconsole_stop, MCONSOLE_PROC },
 	{ "go", mconsole_go, MCONSOLE_INTR },
 	{ "log", mconsole_log, MCONSOLE_INTR },
-	{ "proc", mconsole_proc, MCONSOLE_PROC },
 	{ "stack", mconsole_stack, MCONSOLE_INTR },
 };
 
-- 
2.7.3

Re: [uml-user] Could UML run via seccomp traps instead of ptrace?

[Thomas M. <th...@m3...>]

> Hello!

Hi,

>    So I've been spending some time in UML (among other virtualization
> technologies).  There's some interesting security and performance models it
> possibly allows, even in this era of containers and hypervisors.  Ptrace is
> being something of a problem though; it's a little hairy and difficult to
> scope.  It is unfortunately breaking many things I'm trying to do.
>
>     So I'm curious.  There is another option -- seccomp-bpf can trap on
> arbitrary syscalls.  Is there a reason anyone sees why UML couldn't be
> routed through it?

I had a look at this and I think it could work.

But what mode would you suggest?

a.) SECCOMP_RET_TRAP
Each usermode process would receive an SIGSYS and forward it to the 
kernel process somehow? and continue afterwards.

b.) SECCOMP_RET_TRACE
the kernel process would still ptrace each usermode process and 
intercept all syscalls?
What would be the difference to the current mode of operation? what 
would we gain here?

with kind regards
thomas

Re: [uml-user] [uml-devel] UML on WSL

[Richard W. <ri...@no...>]

Thomas,

Am 09.05.2017 um 19:25 schrieb Thomas Meyer:
>> IOW we write to 0xdeadbeef, catch the fault and fix it.
> 
> I get this:
> thomas@DESKTOP-DQBDJ0U:/mnt/c/Users/thomas/VmShare$ ./segtest
> SIGSEGV at 0x0, fixing up
> SIGSEGV at 0x0, fixing up
> SIGSEGV at 0x0, fixing up
> SIGSEGV at 0x0, fixing up
> SIGSEGV at 0x0, fixing up
> SIGSEGV at 0x0, fixing up
> SIGSEGV at 0x0, fixing up
> SIGSEGV at 0x0, fixing up
> SIGSEGV at 0x0, fixing up
> SIGSEGV at 0x0, fixing up
> SIGSEGV at 0x0, fixing up
> SIGSEGV at 0x0, fixing up
> SIGSEGV at 0x0, fixing up
> SIGSEGV at 0x0, fixing up

Meh, that's a show-stopper.
WSL does not provide a valid signal machine context...

Thanks,
//richard

Re: [uml-user] [uml-devel] UML on WSL

[Thomas M. <th...@m3...>]

Zitat von Richard Weinberger <ri...@no...>:

> Thomas,
>
> Am 09.05.2017 um 10:15 schrieb Thomas Meyer:
>> attached patch work correctly under Linux. But no change under WSL.  
>> As stated in the relevant GH issue, there seems to be far more road  
>> blockers to make UML work under WSL.
>>
>> With you patch I get under WSL:
>>
>> thomas@DESKTOP-DQBDJ0U:/mnt/c/Users/thomas/VmShare$ ./linux
>> Core dump limits :
>>         soft - NONE
>>         hard - NONE
>> Checking that ptrace can change system call numbers...check_ptrace  
>> : failed to modify system call: Invalid Argument
>
> Okay, now it fails later.
> UML needs to cancel  syscalls on the host side, it does so by  
> turning them into a getpid() which has no side
> effects and, on non-ancient systems, by using PTRACE_SYSEMU.
> Let's figure whether they support PTRACE_SYSEMU, can you test the  
> attached patch?

okay, it now proceeds even more:

thomas@DESKTOP-DQBDJ0U:/mnt/c/Users/thomas/VmShare$ ./linux mem=128m
Core dump limits :
         soft - NONE
         hard - NONE
Checking syscall emulation patch for ptrace...missing
Checking environment variables for a tempdir...none found
Checking if /dev/shm is on tmpfs...OK
Checking PROT_EXEC mmap in /dev/shm...OK
Adding 3665920 bytes to physical memory to account for exec-shield gap
kmsg_dump:
<3>[    2.050000] Slab cache with size 1056 has lost its name
<3>[    2.050000] Slab cache with size 160 has lost its name
<3>[    2.050000] Slab cache with size 1440 has lost its name
<3>[    2.050000] Slab cache with size 168 has lost its name
<3>[    2.050000] Slab cache with size 432 has lost its name
<3>[    2.050000] Slab cache with size 984 has lost its name
<3>[    2.050000] Slab cache with size 320 has lost its name
<3>[    2.050000] Slab cache with size 72 has lost its name
<3>[    2.050000] Slab cache with size 72 has lost its name
<3>[    2.050000] Slab cache with size 112 has lost its name
<3>[    2.050000] Slab cache with size 296 has lost its name
<3>[    2.050000] Slab cache with size 104 has lost its name
<3>[    2.050000] Slab cache with size 56 has lost its name
<3>[    2.050000] Slab cache with size 184 has lost its name
<3>[    2.050000] Slab cache with size 1464 has lost its name
<3>[    2.050000] Slab cache with size 776 has lost its name
<3>[    2.050000] Slab cache with size 1408 has lost its name
<3>[    2.050000] Slab cache with size 2216 has lost its name
<3>[    2.050000] Slab cache with size 6000 has lost its name
<3>[    2.050000] Slab cache with size 80 has lost its name
<3>[    2.050000] Slab cache with size 176 has lost its name
<3>[    2.050000] Slab cache with size 40 has lost its name
<3>[    2.050000] Slab cache with size 88 has lost its name
<3>[    2.050000] Slab cache with size 48 has lost its name
<3>[    2.050000] Slab cache with size 576 has lost its name
<3>[    2.050000] Slab cache with size 616 has lost its name
<3>[    2.050000] Slab cache with size 8192 has lost its name
<3>[    2.050000] Slab cache with size 4096 has lost its name
<3>[    2.050000] Slab cache with size 2048 has lost its name
<3>[    2.050000] Slab cache with size 1024 has lost its name
<3>[    2.050000] Slab cache with size 512 has lost its name
<3>[    2.050000] Slab cache with size 256 has lost its name
<3>[    2.050000] Slab cache with size 192 has lost its name
<3>[    2.050000] Slab cache with size 128 has lost its name
<3>[    2.050000] Slab cache with size 96 has lost its name
<3>[    2.050000] Slab cache with size 64 has lost its name
<3>[    2.050000] Slab cache with size 32 has lost its name
<3>[    2.050000] Slab cache with size 16 has lost its name
<3>[    2.050000] Slab cache with size 8 has lost its name
<3>[    2.050000] Slab cache with size 128 has lost its name
<3>[    2.050000] Slab cache with size 200 has lost its name
<7>[    2.050000] SELinux:  Registering netfilter hooks
<6>[    2.050000] cryptomgr_test (23) used greatest stack depth: 6216  
bytes left
<6>[    2.050000] jitterentropy: Initialization failed with host not  
compliant with requirements: 2
<6>[    2.050000] io scheduler noop registered
<6>[    2.050000] io scheduler deadline registered (default)
<3>[    2.050000] Slab cache with size 1416 has lost its name
<3>[    2.050000] Slab cache with size 1304 has lost its name
<3>[    2.050000] Slab cache with size 464 has lost its name
<3>[    2.050000] Slab cache with size 1344 has lost its name
<3>[    2.050000] Slab cache with size 1784 has lost its name
<3>[    2.050000] Slab cache with size 800 has lost its name
<3>[    2.050000] Slab cache with size 1032 has lost its name
<3>[    2.050000] Slab cache with size 1288 has lost its name
<3>[    2.050000] Slab cache with size 32 has lost its name
<3>[    2.050000] Slab cache with size 1040 has lost its name
<3>[    2.050000] Slab cache with size 48 has lost its name
<3>[    2.050000] Slab cache with size 112 has lost its name
<3>[    2.050000] Slab cache with size 16 has lost its name
<3>[    2.050000] Slab cache with size 32 has lost its name
<3>[    2.050000] Slab cache with size 2152 has lost its name
<3>[    2.050000] Slab cache with size 128 has lost its name
<3>[    2.050000] Slab cache with size 168 has lost its name
<3>[    2.050000] Slab cache with size 64 has lost its name
<3>[    2.050000] Slab cache with size 40 has lost its name
<3>[    2.050000] Slab cache with size 56 has lost its name
<3>[    2.050000] Slab cache with size 24 has lost its name
<3>[    2.050000] Slab cache with size 96 has lost its name
<3>[    2.050000] Slab cache with size 768 has lost its name
<3>[    2.050000] Slab cache with size 440 has lost its name
<3>[    2.050000] Slab cache with size 144 has lost its name
<3>[    2.050000] Slab cache with size 696 has lost its name
<3>[    2.050000] Slab cache with size 280 has lost its name
<3>[    2.050000] Slab cache with size 1824 has lost its name
<3>[    2.050000] Slab cache with size 296 has lost its name
<3>[    2.050000] Slab cache with size 280 has lost its name
<3>[    2.050000] Slab cache with size 352 has lost its name
<3>[    2.050000] Slab cache with size 2704 has lost its name
<3>[    2.050000] Slab cache with size 416 has lost its name
<3>[    2.050000] Slab cache with size 152 has lost its name
<3>[    2.050000] Slab cache with size 2112 has lost its name
<3>[    2.050000] Slab cache with size 216 has lost its name
<3>[    2.050000] Slab cache with size 1032 has lost its name
<3>[    2.050000] Slab cache with size 272 has lost its name
<3>[    2.050000] Slab cache with size 120 has lost its name
<3>[    2.050000] Slab cache with size 6056 has lost its name
<3>[    2.050000] Slab cache with size 1208 has lost its name
<3>[    2.050000] Slab cache with size 136 has lost its name
<3>[    2.050000] Slab cache with size 328 has lost its name
<3>[    2.050000] Slab cache with size 1056 has lost its name
<3>[    2.050000] Slab cache with size 160 has lost its name
<3>[    2.050000] Slab cache with size 1440 has lost its name
<3>[    2.050000] Slab cache with size 168 has lost its name
<3>[    2.050000] Slab cache with size 432 has lost its name
<3>[    2.050000] Slab cache with size 984 has lost its name
<3>[    2.050000] Slab cache with size 320 has lost its name
<3>[    2.050000] Slab cache with size 72 has lost its name
<3>[    2.050000] Slab cache with size 72 has lost its name
<3>[    2.050000] Slab cache with size 112 has lost its name
<3>[    2.050000] Slab cache with size 296 has lost its name
<3>[    2.050000] Slab cache with size 104 has lost its name
<3>[    2.050000] Slab cache with size 56 has lost its name
<3>[    2.050000] Slab cache with size 184 has lost its name
<3>[    2.050000] Slab cache with size 1464 has lost its name
<3>[    2.050000] Slab cache with size 776 has lost its name
<3>[    2.050000] Slab cache with size 1408 has lost its name
<3>[    2.050000] Slab cache with size 2216 has lost its name
<3>[    2.050000] Slab cache with size 6000 has lost its name
<3>[    2.050000] Slab cache with size 80 has lost its name
<3>[    2.050000] Slab cache with size 176 has lost its name
<3>[    2.050000] Slab cache with size 40 has lost its name
<3>[    2.050000] Slab cache with size 88 has lost its name
<3>[    2.050000] Slab cache with size 48 has lost its name
<3>[    2.050000] Slab cache with size 576 has lost its name
<3>[    2.050000] Slab cache with size 616 has lost its name
<3>[    2.050000] Slab cache with size 8192 has lost its name
<3>[    2.050000] Slab cache with size 4096 has lost its name
<3>[    2.050000] Slab cache with size 2048 has lost its name
<3>[    2.050000] Slab cache with size 1024 has lost its name
<3>[    2.050000] Slab cache with size 512 has lost its name
<3>[    2.050000] Slab cache with size 256 has lost its name
<3>[    2.050000] Slab cache with size 192 has lost its name
<3>[    2.050000] Slab cache with size 128 has lost its name
<3>[    2.050000] Slab cache with size 96 has lost its name
<3>[    2.050000] Slab cache with size 64 has lost its name
<3>[    2.050000] Slab cache with size 32 has lost its name
<3>[    2.050000] Slab cache with size 16 has lost its name
<3>[    2.050000] Slab cache with size 8 has lost its name
<3>[    2.050000] Slab cache with size 128 has lost its name
<3>[    2.050000] Slab cache with size 200 has lost its name
<3>[    2.050000] Slab cache with size 240 has lost its name
<3>[    2.050000] Slab cache with size 1416 has lost its name
<3>[    2.050000] Slab cache with size 1304 has lost its name
<3>[    2.050000] Slab cache with size 464 has lost its name
<3>[    2.050000] Slab cache with size 1344 has lost its name
<3>[    2.050000] Slab cache with size 1784 has lost its name
<3>[    2.050000] Slab cache with size 800 has lost its name
<3>[    2.050000] Slab cache with size 1032 has lost its name
<3>[    2.050000] Slab cache with size 1288 has lost its name
<3>[    2.050000] Slab cache with size 32 has lost its name
<3>[    2.050000] Slab cache with size 1040 has lost its name
<3>[    2.050000] Slab cache with size 48 has lost its name
<3>[    2.050000] Slab cache with size 112 has lost its name
<3>[    2.050000] Slab cache with size 16 has lost its name
<3>[    2.050000] Slab cache with size 32 has lost its name
<3>[    2.050000] Slab cache with size 2152 has lost its name
<3>[    2.050000] Slab cache with size 128 has lost its name
<3>[    2.050000] Slab cache with size 168 has lost its name
<3>[    2.050000] Slab cache with size 64 has lost its name
<3>[    2.050000] Slab cache with size 40 has lost its name
<3>[    2.050000] Slab cache with size 56 has lost its name
<3>[    2.050000] Slab cache with size 24 has lost its name
<3>[    2.050000] Slab cache with size 96 has lost its name
<3>[    2.050000] Slab cache with size 768 has lost its name
<3>[    2.050000] Slab cache with size 440 has lost its name
<3>[    2.050000] Slab cache with size 144 has lost its name
<3>[    2.050000] Slab cache with size 696 has lost its name
<3>[    2.050000] Slab cache with size 280 has lost its name
<3>[    2.050000] Slab cache with size 1824 has lost its name
<3>[    2.050000] Slab cache with size 296 has lost its name
<3>[    2.050000] Slab cache with size 280 has lost its name
<3>[    2.050000] Slab cache with size 352 has lost its name
<3>[    2.050000] Slab cache with size 2704 has lost its name
<3>[    2.050000] Slab cache with size 416 has lost its name
<3>[    2.050000] Slab cache with size 152 has lost its name
<3>[    2.050000] Slab cache with size 2112 has lost its name
<3>[    2.050000] Slab cache with size 216 has lost its name
<3>[    2.050000] Slab cache with size 1032 has lost its name
<3>[    2.050000] Slab cache with size 272 has lost its name
<3>[    2.050000] Slab cache with size 120 has lost its name
<3>[    2.050000] Slab cache with size 6056 has lost its name
<3>[    2.050000] Slab cache with size 1208 has lost its name
<3>[    2.050000] Slab cache with size 136 has lost its name
<3>[    2.050000] Slab cache with size 328 has lost its name
<3>[    2.050000] Slab cache with size 1056 has lost its name
<3>[    2.050000] Slab cache with size 160 has lost its name
<3>[    2.050000] Slab cache with size 1440 has lost its name
<3>[    2.050000] Slab cache with size 168 has lost its name
<3>[    2.050000] Slab cache with size 432 has lost its name
<3>[    2.050000] Slab cache with size 984 has lost its name
<3>[    2.050000] Slab cache with size 320 has lost its name
<3>[    2.050000] Slab cache with size 72 has lost its name
<3>[    2.050000] Slab cache with size 72 has lost its name
<3>[    2.050000] Slab cache with size 112 has lost its name
<3>[    2.050000] Slab cache with size 296 has lost its name
<3>[    2.050000] Slab cache with size 104 has lost its name
<3>[    2.050000] Slab cache with size 56 has lost its name
<3>[    2.050000] Slab cache with size 184 has lost its name
<3>[    2.050000] Slab cache with size 1464 has lost its name
<3>[    2.050000] Slab cache with size 776 has lost its name
<3>[    2.050000] Slab cache with size 1408 has lost its name
<3>[    2.050000] Slab cache with size 2216 has lost its name
<3>[    2.050000] Slab cache with size 6000 has lost its name
<3>[    2.050000] Slab cache with size 80 has lost its name
<3>[    2.050000] Slab cache with size 176 has lost its name
<3>[    2.050000] Slab cache with size 40 has lost its name
<3>[    2.050000] Slab cache with size 88 has lost its name
<3>[    2.050000] Slab cache with size 48 has lost its name
<3>[    2.050000] Slab cache with size 576 has lost its name
<3>[    2.050000] Slab cache with size 616 has lost its name
<3>[    2.050000] Slab cache with size 8192 has lost its name
<3>[    2.050000] Slab cache with size 4096 has lost its name
<3>[    2.050000] Slab cache with size 2048 has lost its name
<3>[    2.050000] Slab cache with size 1024 has lost its name
<3>[    2.050000] Slab cache with size 512 has lost its name
<3>[    2.050000] Slab cache with size 256 has lost its name
<3>[    2.050000] Slab cache with size 192 has lost its name
<3>[    2.050000] Slab cache with size 128 has lost its name
<3>[    2.050000] Slab cache with size 96 has lost its name
<3>[    2.050000] Slab cache with size 64 has lost its name
<3>[    2.050000] Slab cache with size 32 has lost its name
<3>[    2.050000] Slab cache with size 16 has lost its name
<3>[    2.050000] Slab cache with size 8 has lost its name
<3>[    2.050000] Slab cache with size 128 has lost its name
<3>[    2.050000] Slab cache with size 200 has lost its name
<6>[    2.050000] io scheduler cfq registered
<6>[    2.050000] io scheduler mq-deadline registered
<4>[    2.050000]
<4>[    2.050000] Modules linked in:
<6>[    2.050000] Pid: 1, comm: swapper Not tainted  
4.11.0-00007-g594e0e4-dirty
<6>[    2.050000] RIP: 0033:[<00007f2e5b961eae>]
<6>[    2.050000] RSP: 0000000067c87c38  EFLAGS: 00010202
<6>[    2.050000] RAX: 0000000068842000 RBX: 0000000067dabae0 RCX:  
0000000000000001
<6>[    2.050000] RDX: 0000000000008000 RSI: 000000006884a000 RDI:  
0000000068842020
<6>[    2.050000] RBP: 0000000067c87c70 R08: 0000000067dabae7 R09:  
0000000067f73000
<6>[    2.050000] R10: 0000000000000000 R11: 0000000000000000 R12:  
0000000060040ae0
<6>[    2.050000] R13: 0000000000000000 R14: 00000000604e7e90 R15:  
0000000060886700
<0>[    2.050000] Kernel panic - not syncing: Segfault with no mm
<4>[    2.050000] CPU: 0 PID: 1 Comm: swapper Not tainted  
4.11.0-00007-g594e0e4-dirty #5
<6>[    2.050000] Stack:
<4>[    2.050000]  604e65b1 200000001 678085d8 67e35000
<4>[    2.050000]  678085c0 604e38b0 678085c0 67c87cf0
<4>[    2.050000]  604e3f02 00400000 678085c0 00000200
<6>[    2.050000] Call Trace:
<6>[    2.050000]  [<604e65b1>] ? check_partition+0x181/0x2c0
<6>[    2.050000]  [<604e38b0>] ? add_partition+0x0/0x5b0
<6>[    2.050000]  [<604e3f02>] rescan_partitions+0xa2/0x470
<6>[    2.050000]  [<604e1bd0>] ? get_gendisk+0x0/0x110
<6>[    2.050000]  [<60228842>] __blkdev_get+0x262/0x610
<6>[    2.050000]  [<601fe3cb>] ? unlock_new_inode+0x8b/0x90
<6>[    2.050000]  [<6027dba0>] ? sysfs_create_link+0x0/0x50
<6>[    2.050000]  [<6022907d>] blkdev_get+0x48d/0x5d0
<6>[    2.050000]  [<60513758>] ? refcount_dec_and_test+0x18/0x20
<6>[    2.050000]  [<604f6d1d>] ? kobject_put+0x5d/0x260
<6>[    2.050000]  [<6027dba0>] ? sysfs_create_link+0x0/0x50
<6>[    2.050000]  [<604e22a1>] device_add_disk+0x3b1/0x610
<6>[    2.050000]  [<604e2925>] ? alloc_disk+0x15/0x20
<6>[    2.050000]  [<604e1ef0>] ? device_add_disk+0x0/0x610
<6>[    2.050000]  [<60030d82>] 0x60030d82
<6>[    2.050000]  [<60030cb0>] ? 0x60030cb0
<6>[    2.050000]  [<60041520>] ? do_one_initcall+0x0/0x1a0
<6>[    2.050000]  [<600415da>] do_one_initcall+0xba/0x1a0
<6>[    2.050000]  [<600928f2>] ? parse_args+0x402/0x6f0
<6>[    2.050000]  [<60041520>] ? do_one_initcall+0x0/0x1a0
<6>[    2.050000]  [<60001fe3>] 0x60001fe3
<6>[    2.050000]  [<6015c8e6>] ? printk+0x0/0x94
<6>[    2.050000]  [<60835037>] kernel_init+0x27/0x150
<6>[    2.050000]  [<60043221>] new_thread_handler+0x81/0xb0
<6>[    2.050000]
Abgebrochen (Speicherabzug geschrieben)

>
> Also please test segv1.c, it tests whether WSL allows us to handle  
> page faults in userspace.
> It should output this:
> SIGSEGV at 0xdeadbeef, fixing up
> x=3, &x=0xdeadbeef
>
> IOW we write to 0xdeadbeef, catch the fault and fix it.

I get this:
thomas@DESKTOP-DQBDJ0U:/mnt/c/Users/thomas/VmShare$ ./segtest
SIGSEGV at 0x0, fixing up
SIGSEGV at 0x0, fixing up
SIGSEGV at 0x0, fixing up
SIGSEGV at 0x0, fixing up
SIGSEGV at 0x0, fixing up
SIGSEGV at 0x0, fixing up
SIGSEGV at 0x0, fixing up
SIGSEGV at 0x0, fixing up
SIGSEGV at 0x0, fixing up
SIGSEGV at 0x0, fixing up
SIGSEGV at 0x0, fixing up
SIGSEGV at 0x0, fixing up
SIGSEGV at 0x0, fixing up
SIGSEGV at 0x0, fixing up
[...]

>
> Thanks,
> //richard

Re: [uml-user] [uml-devel] UML on WSL

[Richard W. <ri...@no...>]

Thomas,

Am 09.05.2017 um 10:15 schrieb Thomas Meyer:
> attached patch work correctly under Linux. But no change under WSL. As stated in the relevant GH issue, there seems to be far more road blockers to make UML work under WSL.
> 
> With you patch I get under WSL:
> 
> thomas@DESKTOP-DQBDJ0U:/mnt/c/Users/thomas/VmShare$ ./linux
> Core dump limits :
>         soft - NONE
>         hard - NONE
> Checking that ptrace can change system call numbers...check_ptrace : failed to modify system call: Invalid Argument

Okay, now it fails later.
UML needs to cancel  syscalls on the host side, it does so by turning them into a getpid() which has no side
effects and, on non-ancient systems, by using PTRACE_SYSEMU.
Let's figure whether they support PTRACE_SYSEMU, can you test the attached patch?

Also please test segv1.c, it tests whether WSL allows us to handle page faults in userspace.
It should output this:
SIGSEGV at 0xdeadbeef, fixing up
x=3, &x=0xdeadbeef

IOW we write to 0xdeadbeef, catch the fault and fix it.

Thanks,
//richard

Re: [uml-user] [uml-devel] UML on WSL

[Thomas M. <th...@m3...>]

Zitat von Richard Weinberger <ri...@no...>:

> Thomas,
>
> Can you please give the attached patch a try?

Hi,

attached patch work correctly under Linux. But no change under WSL. As  
stated in the relevant GH issue, there seems to be far more road  
blockers to make UML work under WSL.

With you patch I get under WSL:

thomas@DESKTOP-DQBDJ0U:/mnt/c/Users/thomas/VmShare$ ./linux
Core dump limits :
         soft - NONE
         hard - NONE
Checking that ptrace can change system call numbers...check_ptrace :  
failed to modify system call: Invalid Argument

>
> Thanks,
> //richard

Re: [uml-user] understanding child process

[Enjoy M. <enj...@gm...>]

On Sun, Apr 30, 2017 at 10:57 AM, Lakshmipathi.G
<lak...@gm...> wrote:
> Hi,
>
> When I launch single UML instance as: ./kernel64-4.3.5
> ubda="cow,./CentOS6.x-AMD64-root_fs" mem=512m umid="uml"
> I see quite few child process with pstree:
>
> ───kernel64-4.3.5(4084)─┬─kernel64-4.3.5(4089)
>            │            │
> ├─kernel64-4.3.5(4090)
>            │            │
> ├─kernel64-4.3.5(4091)
>            │            │
> ├─kernel64-4.3.5(4092)
>            │            │
> ├─kernel64-4.3.5(4093)
>            │            │
> ├─kernel64-4.3.5(4207)
>            │            │
> ├─kernel64-4.3.5(4464)
>            │            │
> ├─kernel64-4.3.5(4790)
>            │            │
> └─kernel64-4.3.5(4813)
>
>
>
> Any thoughts on these process are 4090,4091,4092,4093 etc? Are the needed or
> we can disable them? thanks for any help/pointers.

http://marc.info/?l=user-mode-linux-user&m=140143359530413&w=2


>
> ----
> Cheers,
> Lakshmipathi.G
> http://www.giis.co.in
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> User-mode-linux-user mailing list
> Use...@li...
> https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
>

Re: [uml-user] [uml-devel] UML on WSL

[Richard W. <ri...@no...>]

Thomas,

Can you please give the attached patch a try?

Thanks,
//richard

Re: [uml-user] [uml-devel] UML on WSL

[Richard W. <ri...@no...>]

Thomas,

Am 08.05.2017 um 18:09 schrieb Thomas Meyer:
> Or asked he other way around:
> 
> Is somewhere documented what's the minimum host kernel version that a UML kernel will run on?
> 
> E.g.:
> building a UML kernel from 4.11 will need a host kernel version 2.6.18 with features x, y and z enabled?

Not really. But let's be realistic, we don't have to support a 2.4 host.
UML should run on any kernel of a supported distro.

On the other hand, if we can help WSL with a small change to UML, I'll happily apply such a patch.

Thanks,
//richard

Re: [uml-user] [uml-devel] UML on WSL

[Thomas M. <th...@m3...>]

> Am 08.05.2017 um 17:40 schrieb Thomas Meyer <th...@m3...>:
> 
> 
>> Am 08.05.2017 um 17:35 schrieb Richard Weinberger <ri...@no...>:
>> 
>> Thomas,
>> 
>> Am 08.05.2017 um 17:32 schrieb Thomas Meyer:
>>>> We could figure how to report issues to WSL, create self-hosting unit tests and ask them to add/fix
>>>> these features.
>>> 
>>> Turns out there was already a bug report by somebody about missing UML support in WSL:
>>> 
>>> https://github.com/Microsoft/BashOnWindows/issues/1692
>> 
>> Ah, there are tons of ptrace() features missing.
>> UML is a major user of ptrace(), worse than GDB. ;-\
> 
> Yes, I know.
> 
> Probably also worh quoting the discussion from the relevant GH issue regarding OLDPTRACE :
> 
> "
> Also, for a little context, the onlysoftware I can find on the planet that cares is User Mode Linux. Unless someone tries to run some statically linked strace or maybe gdb binary from the 2.4 era, this will simply never be hit on WSL in 2017. UML seems to still care, entirely academically, to maintain binary compatibility with 2.4. You can think of it as UML never buying into the idea the value changed, while everyone else moved"
> 

Or asked he other way around:

Is somewhere documented what's the minimum host kernel version that a UML kernel will run on?

E.g.:
building a UML kernel from 4.11 will need a host kernel version 2.6.18 with features x, y and z enabled?

>> 
>> Thanks,
>> //richard
>> 
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> User-mode-linux-devel mailing list
>> Use...@li...
>> https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> User-mode-linux-user mailing list
> Use...@li...
> https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user

Re: [uml-user] [uml-devel] UML on WSL

[Richard W. <ri...@no...>]

Thomas,

Am 08.05.2017 um 17:40 schrieb Thomas Meyer:
> "
> Also, for a little context, the /only/software I can find /on the planet/ that cares is User Mode Linux. Unless someone tries to run some statically linked |strace| or
> maybe |gdb| binary from the 2.4 era, this will simply never be hit on WSL in 2017. UML seems to still care, entirely academically, to maintain binary compatibility with 2.4. You
> can think of it as UML never buying into the idea the value changed, while everyone else moved"

-ENOPATCH. :-)

Thanks,
//richard

Re: [uml-user] [uml-devel] UML on WSL

[Thomas M. <th...@m3...>]

> Am 08.05.2017 um 17:35 schrieb Richard Weinberger <ri...@no...>:
> 
> Thomas,
> 
> Am 08.05.2017 um 17:32 schrieb Thomas Meyer:
>>> We could figure how to report issues to WSL, create self-hosting unit tests and ask them to add/fix
>>> these features.
>> 
>> Turns out there was already a bug report by somebody about missing UML support in WSL:
>> 
>> https://github.com/Microsoft/BashOnWindows/issues/1692
> 
> Ah, there are tons of ptrace() features missing.
> UML is a major user of ptrace(), worse than GDB. ;-\

Yes, I know.

Probably also worh quoting the discussion from the relevant GH issue regarding OLDPTRACE :

"
Also, for a little context, the onlysoftware I can find on the planet that cares is User Mode Linux. Unless someone tries to run some statically linked strace or maybe gdb binary from the 2.4 era, this will simply never be hit on WSL in 2017. UML seems to still care, entirely academically, to maintain binary compatibility with 2.4. You can think of it as UML never buying into the idea the value changed, while everyone else moved"

> 
> Thanks,
> //richard
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> User-mode-linux-devel mailing list
> Use...@li...
> https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-user] [uml-devel] UML on WSL

[Richard W. <ri...@no...>]

Thomas,

Am 08.05.2017 um 17:32 schrieb Thomas Meyer:
>> We could figure how to report issues to WSL, create self-hosting unit tests and ask them to add/fix
>> these features.
> 
> Turns out there was already a bug report by somebody about missing UML support in WSL:
> 
> https://github.com/Microsoft/BashOnWindows/issues/1692

Ah, there are tons of ptrace() features missing.
UML is a major user of ptrace(), worse than GDB. ;-\

Thanks,
//richard

Re: [uml-user] [uml-devel] UML on WSL

[Thomas M. <th...@m3...>]

> Am 08.05.2017 um 17:05 schrieb Richard Weinberger <ri...@no...>:
> 
> Thomas,
> 
>> Am 08.05.2017 um 17:02 schrieb Thomas Meyer:
>> Sadly, UML executable bails out very early. it Looks like WSL is missing some PTRACE stuff:
>> 
>> thomas@DESKTOP-DQBDJ0U:/mnt/c/Users/thomas/Downloads$ ./linux
>> Core dump limits :
>>        soft - NONE
>>        hard - NONE
>> Checking that ptrace can change system call numbers...check_ptrace: PTRACE_OLDSETOPTIONS failed: Invalid Argument
> 
> We could figure how to report issues to WSL, create self-hosting unit tests and ask them to add/fix
> these features.

Turns out there was already a bug report by somebody about missing UML support in WSL:

https://github.com/Microsoft/BashOnWindows/issues/1692

> 
> Thanks,
> //richard
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> User-mode-linux-devel mailing list
> Use...@li...
> https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-user] [uml-devel] UML on WSL

[Richard W. <ri...@no...>]

Thomas,

Am 08.05.2017 um 17:02 schrieb Thomas Meyer:
> Sadly, UML executable bails out very early. it Looks like WSL is missing some PTRACE stuff:
> 
> thomas@DESKTOP-DQBDJ0U:/mnt/c/Users/thomas/Downloads$ ./linux
> Core dump limits :
>         soft - NONE
>         hard - NONE
> Checking that ptrace can change system call numbers...check_ptrace: PTRACE_OLDSETOPTIONS failed: Invalid Argument

We could figure how to report issues to WSL, create self-hosting unit tests and ask them to add/fix
these features.

Thanks,
//richard

Re: [uml-user] [uml-devel] UML on WSL

[Thomas M. <th...@m3...>]

Zitat von Richard Weinberger <ric...@gm...>:

> Thomas,
>
> On Sun, May 7, 2017 at 1:44 PM, Thomas Meyer <th...@m3...> wrote:
>> Hi,

Hi,

>>
>> Did anybody try to run UML on the new Windows 10 subsystem for Linux? I
>> wonder what missing functions may hinder to run UML on WSL?
>
> No idea.
> Can you try? I don't have access to a Windows 10 system right now
> where I could test.

Sadly, UML executable bails out very early. it Looks like WSL is  
missing some PTRACE stuff:

thomas@DESKTOP-DQBDJ0U:/mnt/c/Users/thomas/Downloads$ ./linux
Core dump limits :
         soft - NONE
         hard - NONE
Checking that ptrace can change system call numbers...check_ptrace:  
PTRACE_OLDSETOPTIONS failed: Invalid Argument

>
> --
> Thanks,
> //richard
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> User-mode-linux-devel mailing list
> Use...@li...
> https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-user] UML on WSL

[Richard W. <ric...@gm...>]

Thomas,

On Sun, May 7, 2017 at 1:44 PM, Thomas Meyer <th...@m3...> wrote:
> Hi,
>
> Did anybody try to run UML on the new Windows 10 subsystem for Linux? I
> wonder what missing functions may hinder to run UML on WSL?

No idea.
Can you try? I don't have access to a Windows 10 system right now
where I could test.

-- 
Thanks,
//richard

[uml-user] UML on WSL

[Thomas M. <th...@m3...>]

Hi,

Did anybody try to run UML on the new Windows 10 subsystem for Linux? I wonder what missing functions may hinder to run UML on WSL?

See also https://msdn.microsoft.com/de-de/commandline/wsl/release_notes

With kind regards
Thomas

Re: [uml-user] understanding child process

[Lakshmipathi.G <lak...@gm...>]

Thanks Richard/Russell.  Yes, the system went unresponsive, needed to
power-off and restart it(I ran UML from sudo account).  Will create
normal user account with ulimits and check again fork-bomb. As you
mentioned it should go away :-)



-- 
----
Cheers,
Lakshmipathi.G
http://www.giis.co.in http://www.webminal.org

Re: [uml-user] understanding child process

[Richard W. <ri...@no...>]

Russell,

Am 04.05.2017 um 23:10 schrieb Russell Lewis:
> I'm going to quibble (or maybe clarify?) a bit here.  Since UML is a process inside the host kernel, it should have the same power as any other application you run.  If you
> fork-bomb with an ordinary application, I'd expect that you would eventually get errors from the fork() syscall - but in the process, you might also make it impossible to spawn off
> new sshd processes - making it impossible to log in.
> 
> I'd be a little dismayed if you could *crash* the host with a fork bomb, though.  And I don't really care whether the "bad" process is UML, or anything else.
> 
> Experts: Am I missing something?

I assumed that "crash" meant something like "system went unresponsive" and not a kernel panic of
the host.
If you setup your resource limits correctly a fork bomb will be stopped.

Thanks,
//richard

Re: [uml-user] understanding child process

[Richard W. <ri...@no...>]

Am 04.05.2017 um 22:32 schrieb Lakshmipathi.G:
> Thanks for the details. I checked it by creating 5 new process (sleep
> 120 &) while running pstree from host. Nice, didn't know that we can
> control(kill) UML process from host too.

Well, "control". ;-)
You can kill UML processes on the host side and confuse UML horrible.

> I test ran a fork-bomb inside UML, it crashed the host. Is that
> expected behavior? Is there a way to prevent this?

Yes.

UML is an userspace application like any other is, you have to
protect your host from fork-bombing.
It does not matter whether UML starts many processes or an evil user.

Thanks,
//richard

Re: [uml-user] understanding child process

[Lakshmipathi.G <lak...@gm...>]

Thanks for the details. I checked it by creating 5 new process (sleep
120 &) while running pstree from host. Nice, didn't know that we can
control(kill) UML process from host too.

I test ran a fork-bomb inside UML, it crashed the host. Is that
expected behavior? Is there a way to prevent this?

On 5/4/17, Richard Weinberger <ric...@gm...> wrote:
> On Sun, Apr 30, 2017 at 8:46 AM, Lakshmipathi.G
> <lak...@gm...> wrote:
>> Hi Russ,
>>
>> Thanks for the response. I tried with Slackware root file system with
>> same kernel, now it doesn't spawn as many child process. Its possibly
>> related to root file system i guess (may be something like getty
>> process?).
>
> UML creates for every process within UML a stub process on the host side.
>
> --
> Thanks,
> //richard
>


-- 
----
Cheers,
Lakshmipathi.G
http://www.giis.co.in http://www.webminal.org