Re: [uml-devel] [PATCH v2] um: add dummy ioremap and iounmap functions

[Geert Uytterhoeven <geert@li...>]

Hi Logan,

On Thu, May 25, 2017 at 5:53 PM, Logan Gunthorpe <logang@...> wrote:
> On 25/05/17 09:48 AM, Richard Weinberger wrote:
>> Which ones are failing?
>> I thought we killed the problem by making CONFIG_COMPILE_TEST depend on !UML.
>
> None, at the moment. My work is trying to add iomem support to scatter
> lists and thus I want to call ioremap in scatterlist.c. That's when
> things fail to build. We could put an '#ifdef HAS_IOMEM' around only the
> uses, but I thought this approach was cleaner. However, if people would
> rather I do that, let me know and I will.
>
>> I was never a fan of that approach because in my opinion drivers should have
>> proper dependencies, including a dependency on HAS_IOMEM.
>
> This doesn't really work when we try to use it in a core library which
> can't depend on HAS_IOMEM.

Still, those code patch could be protected by #ifdef CONFIG_HAS_IOMEM,
or better, if (IS_ENABLED(CONFIG_HAS_IOMEM)).

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [uml-devel] [PATCH v2] um: add dummy ioremap and iounmap functions

[Richard Weinberger <richard@no...>]

Logan,

Am 25.05.2017 um 17:42 schrieb Logan Gunthorpe:
> The user mode architecture does not provide ioremap or iounmap, and
> because of this, the arch won't build when the functions are used in some
> core libraries.

Which ones are failing?
I thought we killed the problem by making CONFIG_COMPILE_TEST depend on !UML.

> I have designs to use these functions in scatterlist.c where they'd
> almost certainly never be called on the um architecture but it does need
> to compile. Thus, if the function is ever hit it returns NULL.

I was never a fan of that approach because in my opinion drivers should have
proper dependencies, including a dependency on HAS_IOMEM.

But I'll no longer block these attempts if we can get rid of tons of fallout
every kernel release.

Thanks,
//richard

Re: [uml-devel] [PATCH] um: add dummy ioremap and iounmap functions

[Al Viro <viro@ZenIV.linux.org.uk>]

On Wed, May 24, 2017 at 04:00:52PM -0600, Logan Gunthorpe wrote:
> The user mode architecture does not provide ioremap or iounmap, and
> because of this, the arch won't build when the functions are used in some
> core libraries.
> 
> I have designs to use these functions in scatterlist.c where they'd
> almost certainly never be called on the um architecture but it does need
> to compile.

Then make it fail there.

Incidentally, s390 has ioremap() only when CONFIG_PCI is set.

[uml-devel] [PATCH v2] um: Add mark_rodata_ro support

[Thomas Meyer <thomas@m3...>]

Signed-off-by: Thomas Meyer <thomas@...>
---
 arch/um/Kconfig.common |  1 +
 arch/um/kernel/mem.c   | 13 ++++++++++++-
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/arch/um/Kconfig.common b/arch/um/Kconfig.common
index 85f6dd2..061009b 100644
--- a/arch/um/Kconfig.common
+++ b/arch/um/Kconfig.common
@@ -2,6 +2,7 @@ config UML
 	bool
 	default y
 	select ARCH_HAS_KCOV
+	select ARCH_HAS_STRICT_KERNEL_RWX
 	select HAVE_ARCH_AUDITSYSCALL
 	select HAVE_ARCH_SECCOMP_FILTER
 	select HAVE_UID16
diff --git a/arch/um/kernel/mem.c b/arch/um/kernel/mem.c
index e7437ec..8705eff 100644
--- a/arch/um/kernel/mem.c
+++ b/arch/um/kernel/mem.c
@@ -12,6 +12,7 @@
 #include <linux/slab.h>
 #include <asm/fixmap.h>
 #include <asm/page.h>
+#include <asm/sections.h>
 #include <as-layout.h>
 #include <init.h>
 #include <kern.h>
@@ -168,7 +169,6 @@ void __init paging_init(void)
  * This can't do anything because nothing in the kernel image can be freed
  * since it's not in kernel physical memory.
  */
-
 void free_initmem(void)
 {
 }
@@ -238,3 +238,14 @@ void *uml_kmalloc(int size, int flags)
 {
 	return kmalloc(size, flags);
 }
+
+void mark_rodata_ro(void)
+{
+	/* rodata_start/end must be PAGE_SIZE aligend! */
+	unsigned long rodata_start = (unsigned long) __start_rodata;
+	unsigned long rodata_end = (unsigned long) __end_rodata;
+
+	printk(KERN_INFO "Write protecting the kernel read-only data: %luk\n",
+	       (rodata_end - rodata_start) >> 10);
+	os_protect_memory((void*)rodata_start, (rodata_end - rodata_start), 1, 0, 0);
+}

Re: [uml-devel] [PATCH v2] um: Avoid longjmp/setjmp symbol clashes with libpthread.a

[Richard Weinberger <richard@no...>]

Florian,

Am 24.05.2017 um 02:32 schrieb Florian Fainelli:
> Building a statically linked UML kernel on a Centos 6.9 host resulted in
> the following linking failure (GCC 4.4, glibc-2.12):
> 
> /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/libpthread.a(libpthread.o):
> In function `siglongjmp':
> (.text+0x8490): multiple definition of `longjmp'
> arch/x86/um/built-in.o:/local/users/fainelli/openwrt/trunk/build_dir/target-x86_64_musl/linux-uml/linux-4.4.69/arch/x86/um/setjmp_64.S:44:
> first defined here
> /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/libpthread.a(libpthread.o):
> In function `sem_open':
> (.text+0x77cd): warning: the use of `mktemp' is dangerous, better use
> `mkstemp'
> collect2: ld returned 1 exit status
> make[4]: *** [vmlinux] Error 1
> 
> Adopt a solution similar to the one done for vmap where we define
> longjmp/setjmp to be kernel_longjmp/setjmp. In the process, make sure we
> do rename the functions in arch/x86/um/setjmp_*.S accordingly.

What is not so clear to me, why are you facing this build issue and other users, including me,
not?

Thanks,
//richard

[uml-devel] [PATCH] um: userspace - be more verbose in ptrace set regs error

[Thomas Meyer <thomas@m3...>]

When ptrace fails to set GP/FP regs for the target process,
log the error before crashing the UML kernel.

Signed-off-by: Thomas Meyer <thomas@...>
---
 arch/um/os-Linux/skas/process.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/arch/um/os-Linux/skas/process.c b/arch/um/os-Linux/skas/process.c
index 4530867..819d686 100644
--- a/arch/um/os-Linux/skas/process.c
+++ b/arch/um/os-Linux/skas/process.c
@@ -352,11 +352,17 @@ void userspace(struct uml_pt_regs *regs)
 		 * fail.  In this case, there is nothing to do but
 		 * just kill the process.
 		 */
-		if (ptrace(PTRACE_SETREGS, pid, 0, regs->gp))
+		if (ptrace(PTRACE_SETREGS, pid, 0, regs->gp)) {
+			printk(UM_KERN_ERR "userspace - ptrace set regs "
+			       "failed, errno = %d\n", errno);
 			fatal_sigsegv();
+		}
 
-		if (put_fp_registers(pid, regs->fp))
+		if (put_fp_registers(pid, regs->fp)) {
+			printk(UM_KERN_ERR "userspace - ptrace set fp regs "
+			       "failed, errno = %d\n", errno);
 			fatal_sigsegv();
+		}
 
 		/* Now we set local_using_sysemu to be used for one loop */
 		local_using_sysemu = get_using_sysemu();

Re: [uml-devel] um: xstate changes breaks my UML setup

[Thomas Meyer <thomas@m3...>]

> Am 23.05.2017 um 21:30 schrieb Richard Weinberger <richard.weinberger@...>:
> 
> Thomas,
> 
>> On Tue, May 23, 2017 at 7:56 PM, Thomas Meyer <thomas@...> wrote:
>> Hi,
>> 
>> 
>> 
>> to make UML work again with the latest Fedora Installation I Need to revert
>> those commits:
>> 
>> b6024b21fec8367ef961a771cc9dde31f1831965
>> 
>> a78ff1112263fdd871d3506dbcff44f6f12e8423
>> 
>> 
>> 
>> A reproducer script/config is available here:
>> 
>> https://github.com/thomasmey/uml/blob/master/fedora-26-install.sh
> 
> Please start using the CC feature of your mailer. :-)

Damn, I did so, but Windows 10 Mail is just so broken...

> 
> -- 
> 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
> User-mode-linux-devel@...
> https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] um: prinft patches from Masami Hiramatsu

[Richard Weinberger <richard.weinberger@gm...>]

On Tue, May 23, 2017 at 7:56 PM, Thomas Meyer <thomas@...> wrote:
> Hi,
>
>
>
> did you see those patches?
>
>
>
> https://marc.info/?l=linux-kernel&m=149337486632399&w=2

Yes, they are on my TODO.

-- 
Thanks,
//richard

Re: [uml-devel] um: xstate changes breaks my UML setup

[Richard Weinberger <richard.weinberger@gm...>]

Thomas,

On Tue, May 23, 2017 at 7:56 PM, Thomas Meyer <thomas@...> wrote:
> Hi,
>
>
>
> to make UML work again with the latest Fedora Installation I Need to revert
> those commits:
>
> b6024b21fec8367ef961a771cc9dde31f1831965
>
> a78ff1112263fdd871d3506dbcff44f6f12e8423
>
>
>
> A reproducer script/config is available here:
>
> https://github.com/thomasmey/uml/blob/master/fedora-26-install.sh

Please start using the CC feature of your mailer. :-)

-- 
Thanks,
//richard

[uml-devel] um: prinft patches from Masami Hiramatsu

[Thomas Meyer <thomas@m3...>]

Hi,

did you see those patches?

https://marc.info/?l=linux-kernel&m=149337486632399&w=2

they were only post to linux-kernel.

With Kind regards
Thomas

[uml-devel] um: xstate changes breaks my UML setup

[Thomas Meyer <thomas@m3...>]

Hi,

to make UML work again with the latest Fedora Installation I Need to revert those commits:
b6024b21fec8367ef961a771cc9dde31f1831965
a78ff1112263fdd871d3506dbcff44f6f12e8423

A reproducer script/config is available here:
https://github.com/thomasmey/uml/blob/master/fedora-26-install.sh

with Kind regards
thomas

Re: [uml-devel] Multiple longjmp definitions with STATIC_LINKING=y

[Richard Weinberger <richard@no...>]

Florian,

Am 23.05.2017 um 05:28 schrieb Florian Fainelli:
> Hi Richard,
> 
> I have been playing with UML again and trying to get it to statically
> link on a CentOS 6.9 host that has:
> 
> glibc-2.12-static
> gcc-4.4
> 
> installed results in the following:
> 
> /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/libpthread.a(libpthread.o):
> In function `siglongjmp':
> (.text+0x8490): multiple definition of `longjmp'
> arch/x86/um/built-in.o:/local/users/fainelli/openwrt/trunk/build_dir/target-x86_64_musl/linux-uml/linux-4.4.69/arch/x86/um/setjmp_64.S:44:
> first defined here
> /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/libpthread.a(libpthread.o):
> In function `sem_open':
> (.text+0x77cd): warning: the use of `mktemp' is dangerous, better use
> `mkstemp'
> collect2: ld returned 1 exit status
> make[4]: *** [vmlinux] Error 1

Meh, this is a new one.
How is musl involved in this game?

Does it help when you add another redefine-hack to arch/um/Makefile?
See -Dvmap=kernel_vmap.

> Should we have some linker script magic not to export this symbol and
> prevent a clash with libpthread.a pulling its own version?

Yes, we should. But so far nobody had the time to bite the bullet. :-)
This is not the first bug of this kind. Please see.
https://lkml.org/lkml/2015/11/19/726

Thanks,
//richard

Re: [uml-devel] [PATCH] um: Add mark_rodata_ro support.

[Thomas Meyer <thomas@m3...>]

> Am 22.05.2017 um 21:37 schrieb Richard Weinberger <richard@...>:
> 
> Thomas,
> 
>> Am 22.05.2017 um 21:18 schrieb Thomas Meyer:
>> 
>>> Am 22.05.2017 um 20:34 schrieb Richard Weinberger <richard@...>:
>>> 
>>> Thomas,
>>> 
>>>> Am 22.05.2017 um 20:14 schrieb Thomas Meyer:
>>>> It's purely cosmetic; to get rid of the boot message: "This architecture does not have kernel memory protection." in init/main.c
>>>> 
>>>> Which isn't true for UML as all read only stuff should end up in a read only ELF section. Shouldn't it?
>>> 
>>> Hmm, reading /proc/<pid of uml>/maps tells a different story on my host.
>>> Did you check?
>> 
>> No... I may should have done so...
>> 
>> Okay, but it should be possible to mprotect those regions ?
> 
> Yes, it should.
> Can you give it a try?

Will do so!

> 
> 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
> User-mode-linux-devel@...
> https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH] um: Add mark_rodata_ro support.

[Richard Weinberger <richard@no...>]

Thomas,

Am 22.05.2017 um 21:18 schrieb Thomas Meyer:
> 
>> Am 22.05.2017 um 20:34 schrieb Richard Weinberger <richard@...>:
>>
>> Thomas,
>>
>>> Am 22.05.2017 um 20:14 schrieb Thomas Meyer:
>>> It's purely cosmetic; to get rid of the boot message: "This architecture does not have kernel memory protection." in init/main.c
>>>
>>> Which isn't true for UML as all read only stuff should end up in a read only ELF section. Shouldn't it?
>>
>> Hmm, reading /proc/<pid of uml>/maps tells a different story on my host.
>> Did you check?
> 
> No... I may should have done so...
> 
> Okay, but it should be possible to mprotect those regions ?

Yes, it should.
Can you give it a try?

Thanks,
//richard

Re: [uml-devel] [PATCH] um: Add mark_rodata_ro support.

[Thomas Meyer <thomas@m3...>]

> Am 22.05.2017 um 20:34 schrieb Richard Weinberger <richard@...>:
> 
> Thomas,
> 
>> Am 22.05.2017 um 20:14 schrieb Thomas Meyer:
>> It's purely cosmetic; to get rid of the boot message: "This architecture does not have kernel memory protection." in init/main.c
>> 
>> Which isn't true for UML as all read only stuff should end up in a read only ELF section. Shouldn't it?
> 
> Hmm, reading /proc/<pid of uml>/maps tells a different story on my host.
> Did you check?

No... I may should have done so...

Okay, but it should be possible to mprotect those regions ?
> 
> Thanks,
> //richard

Re: [uml-devel] [PATCH] um: Add mark_rodata_ro support.

[Richard Weinberger <richard@no...>]

Thomas,

Am 22.05.2017 um 20:14 schrieb Thomas Meyer:
> It's purely cosmetic; to get rid of the boot message: "This architecture does not have kernel memory protection." in init/main.c
> 
> Which isn't true for UML as all read only stuff should end up in a read only ELF section. Shouldn't it?

Hmm, reading /proc/<pid of uml>/maps tells a different story on my host.
Did you check?

Thanks,
//richard

Re: [uml-devel] [PATCH] um: Add mark_rodata_ro support.

[Thomas Meyer <thomas@m3...>]

> Am 21.05.2017 um 23:28 schrieb Richard Weinberger <richard.weinberger@...>:
> 
> Thomas,
> 
>> On Thu, May 18, 2017 at 12:11 AM, Thomas Meyer <thomas@...> wrote:
>> This is actually a no-op as all read-only should be read-only in the ELF.
> 
> What problem does this patch fix? Or what is the purpose?

Hi,

It's purely cosmetic; to get rid of the boot message: "This architecture does not have kernel memory protection." in init/main.c

Which isn't true for UML as all read only stuff should end up in a read only ELF section. Shouldn't it?

> 
> -- 
> 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
> User-mode-linux-devel@...
> https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [RFC PATCH 1/7] um: Use printk instead of printf in make_uml_dir

[Richard Weinberger <richard.weinberger@gm...>]

On Wed, May 17, 2017 at 10:35 AM, Thomas Meyer <thomas@...> wrote:
>> On Tue, 16 May 2017 17:46:47 +0200
>> Thomas Meyer <thomas@...> wrote:
>>
>>> Hi,
>>>
>>> as far as I understand everything under os-Linux should be OS specific
>>> and shouldn't rely on kernel functions.
>>
>> I see, but umid.c already uses many printk()s. So that policy
>> is not so clear now. For example, without this series,
>
> Yes you are right. I did write nonsense!
>
> I'm fine with all patches in series. Looks good to me!

Yeah, the policy is not so clear.
In theory os-Linux should contain no kernel stuff, but the printk()s do not
hurt, in most cases.

-- 
Thanks,
//richard

Re: [uml-devel] [PATCH] um: Don't build arch/x86/um/user-offsets.s with gcc plugins

[Richard Weinberger <richard.weinberger@gm...>]

Thomas,

On Wed, May 17, 2017 at 10:41 PM, Thomas Meyer <thomas@...> wrote:
> For some reasons I don't know users-offsets.s get's build before the
> gcc-plugins itself.

Can you please figure? I want to make sure that we really fix the root cause
and not just papering over a symptom.

-- 
Thanks,
//richard

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

[Al Viro <viro@ZenIV.linux.org.uk>]

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...

Re: [uml-devel] [PATCH] um: Add mark_rodata_ro support.

[Richard Weinberger <richard.weinberger@gm...>]

Thomas,

On Thu, May 18, 2017 at 12:11 AM, Thomas Meyer <thomas@...> wrote:
> This is actually a no-op as all read-only should be read-only in the ELF.

What problem does this patch fix? Or what is the purpose?

-- 
Thanks,
//richard

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

[Richard Weinberger <richard@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 <richard@...>
---
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

[uml-devel] [PATCH] um: Add mark_rodata_ro support.

[Thomas Meyer <thomas@m3...>]

This is actually a no-op as all read-only should be read-only in the ELF.

Signed-off-by: Thomas Meyer <thomas@...>
---
 arch/um/Kconfig.common | 1 +
 arch/um/kernel/mem.c   | 5 ++++-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/um/Kconfig.common b/arch/um/Kconfig.common
index 85f6dd2..061009b 100644
--- a/arch/um/Kconfig.common
+++ b/arch/um/Kconfig.common
@@ -2,6 +2,7 @@ config UML
 	bool
 	default y
 	select ARCH_HAS_KCOV
+	select ARCH_HAS_STRICT_KERNEL_RWX
 	select HAVE_ARCH_AUDITSYSCALL
 	select HAVE_ARCH_SECCOMP_FILTER
 	select HAVE_UID16
diff --git a/arch/um/kernel/mem.c b/arch/um/kernel/mem.c
index e7437ec..027ed03 100644
--- a/arch/um/kernel/mem.c
+++ b/arch/um/kernel/mem.c
@@ -168,7 +168,6 @@ void __init paging_init(void)
  * This can't do anything because nothing in the kernel image can be freed
  * since it's not in kernel physical memory.
  */
-
 void free_initmem(void)
 {
 }
@@ -238,3 +237,7 @@ void *uml_kmalloc(int size, int flags)
 {
 	return kmalloc(size, flags);
 }
+
+void mark_rodata_ro(void)
+{
+}

[uml-devel] [PATCH] um: Don't build arch/x86/um/user-offsets.s with gcc plugins

[Thomas Meyer <thomas@m3...>]

For some reasons I don't know users-offsets.s get's build before the
gcc-plugins itself.
This patch fixes the problem by not using the gcc-plugins for building
user-offsets.s

make order example:
$ make ARCH=um
  CHK     include/generated/uapi/linux/version.h
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/basic/bin2c
  HOSTCC  scripts/unifdef
  CC      arch/x86/um/user-offsets.s
  CHK     include/generated/user_constants.h
  CHK     include/config/kernel.release
  CHK     include/generated/utsrelease.h
  HOSTCXX -fPIC scripts/gcc-plugins/latent_entropy_plugin.o
  HOSTLLD -shared scripts/gcc-plugins/latent_entropy_plugin.so
  HOSTCXX -fPIC scripts/gcc-plugins/structleak_plugin.o
  HOSTLLD -shared scripts/gcc-plugins/structleak_plugin.so

Signed-off-by: Thomas Meyer <thomas@...>
---
 arch/x86/um/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/um/Makefile b/arch/x86/um/Makefile
index 46cbbfe..d67c78a 100644
--- a/arch/x86/um/Makefile
+++ b/arch/x86/um/Makefile
@@ -36,7 +36,7 @@ subarch-$(CONFIG_MODULES) += ../kernel/module.o
 USER_OBJS := bugs_$(BITS).o ptrace_user.o fault.o
 
 extra-y += user-offsets.s
-$(obj)/user-offsets.s: c_flags = -Wp,-MD,$(depfile) $(USER_CFLAGS) \
+$(obj)/user-offsets.s: c_flags = -Wp,-MD,$(depfile) $(filter-out $(GCC_PLUGINS_CFLAGS), $(USER_CFLAGS) ) \
 	-Iarch/x86/include/generated
 
 UNPROFILE_OBJS := stub_segv.o

Re: [uml-devel] [RFC PATCH 1/7] um: Use printk instead of printf in make_uml_dir

[Thomas Meyer <thomas@m3...>]

> Am 17.05.2017 um 03:52 schrieb Masami Hiramatsu <mhiramat@...>:
> 
> Hi Thomas,

Hi,

> 
> On Tue, 16 May 2017 17:46:47 +0200
> Thomas Meyer <thomas@...> wrote:
> 
>> Hi,
>> 
>> as far as I understand everything under os-Linux should be OS specific 
>> and shouldn't rely on kernel functions.
> 
> I see, but umid.c already uses many printk()s. So that policy
> is not so clear now. For example, without this series,

Yes you are right. I did write nonsense!

I'm fine with all patches in series. Looks good to me!

> 
> $ grep printk -rw arch/um/os-Linux/ | wc -l
> 159
> 
> Thank you,
> 
>> 
>> @Richard: What do you think about this patch?
>> 
>> See: https://marc.info/?l=linux-kernel&m=149337493432407&w=2
>> 
>> with kind regards
>> thomas
> 
> 
> -- 
> Masami Hiramatsu <mhiramat@...>