Am 28.11.2015 um 22:32 schrieb Mickaël Salaün:
> Replace the default insecure mode 0777 with 0700 for temporary file.
>
> Prohibit other users to change the executable mapped code.
Hmm, isn't the tmp file already unlinked at this stage?
Thanks,
//richard
Am 28.11.2015 um 22:32 schrieb Mickaël Salaün:
> Open the memory mapped file with the O_TMPFILE flag when available.
>
> Signed-off-by: Mickaël Salaün
> ---
> arch/um/os-Linux/mem.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/um/os-Linux/mem.c b/arch/um/os-Linux/
Am 28.11.2015 um 23:52 schrieb Mickaël Salaün:
>
> On 28/11/2015 22:40, Richard Weinberger wrote:
>> Am 28.11.2015 um 22:32 schrieb Mickaël Salaün:
>>> Replace the default insecure mode 0777 with 0700 for temporary file.
>>>
>>> Prohibit other users to chang
Am 28.11.2015 um 23:56 schrieb Mickaël Salaün:
>
> On 28/11/2015 23:07, Richard Weinberger wrote:
>> Am 28.11.2015 um 22:32 schrieb Mickaël Salaün:
>>> Open the memory mapped file with the O_TMPFILE flag when available.
>>>
>>> Signed-off-by: Mickaël Sala
Am 29.11.2015 um 00:00 schrieb Mickaël Salaün:
>
>
> On 28/11/2015 23:55, Richard Weinberger wrote:
>> Am 28.11.2015 um 23:52 schrieb Mickaël Salaün:
>>>
>>> On 28/11/2015 22:40, Richard Weinberger wrote:
>>>> Am 28.11.2015 um 22:32 schrieb Mickaël Sa
On Tue, Dec 1, 2015 at 9:18 PM, Geyslan G. Bem wrote:
> When using va_list ensure that va_start will be followed by va_end.
>
> Signed-off-by: Geyslan G. Bem
> ---
> arch/um/drivers/net_user.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/arch/um/drivers/net
Am 08.12.2015 um 21:37 schrieb Tristan Schmelcher:
> On 6 December 2015 at 09:43, Mickaël Salaün wrote:
>> Well, I'm concerned to use umask because it is not thread-safe and drivers
>> may use create_mem_file() in a multi-theaded context.
>
> You are right. We should perhaps set the umask to 070
Am 22.12.2015 um 22:15 schrieb Mickaël Salaün:
> This series protect the memory mapped file. This apply on v4.4-rc6.
>
> Changes since v4:
> * fix spelling [1/2]
>
> Changes since v3:
> * add Tristan Schmelcher's ack
>
> Changes since v2; addressed Tristan Schmelcher's comment:
> * remove the wh
...modules are using this symbol.
Export it like all other archs to.
Signed-off-by: Richard Weinberger
---
arch/um/kernel/reboot.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/um/kernel/reboot.c b/arch/um/kernel/reboot.c
index 9bdf67a..b60a9f8 100644
--- a/arch/um/kernel/reboot.c
Viro
Signed-off-by: Richard Weinberger
diff --git a/arch/um/kernel/signal.c b/arch/um/kernel/signal.c
index fc8be0e..57acbd6 100644
--- a/arch/um/kernel/signal.c
+++ b/arch/um/kernel/signal.c
@@ -69,7 +69,7 @@ void do_signal(struct pt_regs *regs)
struct ksignal ksig;
int
Am 23.01.2016 um 20:17 schrieb Colin King:
> From: Colin Ian King
>
> static analysis from cppcheck detected %x being used for
> unsigned longs:
>
> [arch/x86/um/os-Linux/task_size.c:112]: (warning) %x in format
> string (no. 1) requires 'unsigned int' but the argument type
> is 'unsigned lo
Am 29.01.2016 um 00:56 schrieb Nicolai Stange:
> Commit 16da306849d0 ("um: kill pfn_t")
> introduced a compile warning for defconfig:
>
> arch/um/kernel/skas/mmu.c:38:206: warning: right shift count >= width of
> type
> [-Wshift-count-overflow]
>
> Aforement
Am 29.01.2016 um 02:32 schrieb Nicolai Stange:
> Richard Weinberger writes:
>
>> Am 29.01.2016 um 00:56 schrieb Nicolai Stange:
>>> Commit 16da306849d0 ("um: kill pfn_t")
>>> introduced a compile warning for defconfig:
>>>
>>> ar
Am 29.01.2016 um 15:31 schrieb Nicolai Stange:
>>> Question 1: now that ->pte_high will be gone, do you want to have
>>> ->pte_low renamed to e.g. ->pte_val?
>>
>> So, with a freshly booted brain the story looks a bit different.
>> All this code needs a cleanup and we need to check what
Hi!
Am 18.06.2016 um 13:02 schrieb Enrico Mioso:
> Hi guys.
>
> I am experiencing an user-mode-linux memory leak, that induces the user-mode
> kernel to eventually panic.
>
> My sequence of actions to trigger it is relatively simple:
> - start it on an ubuntu 16.04 core image, after installing
Recent changes to printk() broke UML's stack trace
output. Kill the root of the problem by using a single
printk() statement.
Signed-off-by: Richard Weinberger
---
arch/um/kernel/sysrq.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/um/kernel/sysrq.c b/ar
On Wed, Jan 4, 2017 at 2:54 PM, Enjoy Mindful wrote:
> Hi,
>
> https://marc.info/?l=user-mode-linux-devel
> https://marc.info/?l=user-mode-linux-user
> https://sourceforge.net/p/user-mode-linux/mailman/user-mode-linux-user/
>
> I'm looking for archive tar balls for user-mode-linux-devel and
> user
On Fri, Mar 17, 2017 at 4:46 PM, Pavel Machek wrote:
> On Tue 2017-02-28 16:28:11, Natale Patriciello wrote:
>> It seems there is no interest in fixing bugs (such as [1]). Moreover,
>> same guest filesystem (same host os, distribution, etc.) on two
>> different machines (i7-2630 the first, i7-7700
Matthias,
Am 17.04.2017 um 22:37 schrieb Matthias Kaehlcke:
> El Mon, Apr 03, 2017 at 12:54:58PM -0700 Matthias Kaehlcke ha dit:
>
>> Signed-off-by: Matthias Kaehlcke
>> ---
>> arch/x86/um/shared/sysdep/kernel-offsets.h | 9 +
>> 1 file changed, 1 insertion(+), 8 deletions(-)
>>
>> diff
On Mon, Apr 3, 2017 at 9:54 PM, Matthias Kaehlcke wrote:
> Signed-off-by: Matthias Kaehlcke
> ---
> arch/x86/um/shared/sysdep/kernel-offsets.h | 9 +
> 1 file changed, 1 insertion(+), 8 deletions(-)
>
> diff --git a/arch/x86/um/shared/sysdep/kernel-offsets.h
> b/arch/x86/um/shared/sysde
On Sun, Dec 25, 2016 at 11:11 PM, Richard Weinberger wrote:
> Recent changes to printk() broke UML's stack trace
> output. Kill the root of the problem by using a single
> printk() statement.
>
> Signed-off-by: Richard Weinberger
> ---
> arch/um/kernel/sysrq.c | 6 +
On Sun, Apr 30, 2017 at 8:46 AM, Lakshmipathi.G
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 c
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
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
Thomas,
On Sun, May 7, 2017 at 1:44 PM, Thomas Meyer 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 tes
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
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/
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
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
Thomas,
Can you please give the attached patch a try?
Thanks,
//richard
>From b64c967e3960eff33e96f7dcff261635fffeb504 Mon Sep 17 00:00:00 2001
From: Richard Weinberger
Date: Mon, 8 May 2017 21:43:27 +0200
Subject: [PATCH] um: Drop PTRACE_OLDSETOPTIONS usage
IMHO in 2017 can assume that nob
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
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, fix
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
---
Hi!
Unless I miss something is fe
Dan,
On Mon, May 22, 2017 at 12:39 AM, Dan Kaminsky 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
> f
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 `siglo
Florian,
Am 01.06.2017 um 21:38 schrieb Florian Fainelli:
>> Presumably because we are not using the same glibc version? The one I
>> have installed on this machine is glibc-2.12, do you want me to attach a
>> copy of it?
>
> Richard, what do we do with this?
I'd like to see the issues that Thom
Am 01.06.2017 um 22:15 schrieb Florian Fainelli:
> On 06/01/2017 01:11 PM, Richard Weinberger wrote:
>> Florian,
>>
>> Am 01.06.2017 um 21:38 schrieb Florian Fainelli:
>>>> Presumably because we are not using the same glibc version? The one I
>>>> hav
Florian,
Am 05.06.2017 um 21:32 schrieb Florian Fainelli:
> On 05/23/2017 05:32 PM, Florian Fainelli wrote:
>> 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/../../../../l
Am 08.06.2017 um 18:10 schrieb Krzysztof Kozlowski:
> Remove old, dead Kconfig option INET_LRO. It is gone since
> commit 7bbf3cae65b6 ("ipv4: Remove inet_lro library").
>
> Signed-off-by: Krzysztof Kozlowski
Acked-by: Richard Weinberg
Florian,
Am 29.06.2017 um 00:40 schrieb Florian Fainelli:
>> Hehe, yes.
>> This patch is good, I like it. :)
>> It will part of the next pull request.
>
> Humm okay, did you apply the patch in one of your kernel trees on
> git.kernel.org or somewhere else?
Will happen soon since the merge window
Anton,
Am Samstag, 9. Dezember 2017, 18:09:17 CET schrieb Anton Ivanov:
> Thanks,
>
> I guess I missed that one.
>
> A.
>
> On 09/12/17 11:49, Dan Carpenter wrote:
> > We need to unlock and restore IRQs on this error path.
> >
> > Fixes: ad1f62ab2bd4 ("High Performance UML Vector Network Drive
Am Donnerstag, 5. April 2018, 23:21:02 CEST schrieb Hernán Gonzalez:
> This option restores the DEBUG_BUGVERBOSE functionality as it was
> previous to commit 9a93848fe787 ("x86/debug: Implement __WARN() using
> UD0").
>
> Signed-off-by: Hernán Gonzalez
Applied.
Thanks,
//richard
--
We have a new mailing list, so update the MAINTAINERS file.
Signed-off-by: Richard Weinberger
---
MAINTAINERS | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index b60179d948bb..4834d1551248 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14768,8
Hi!
The new mailing list address is: linux...@lists.infradead.org
Please subscribe via web[0] or mail[1].
Thanks,
//richard
[0] http://lists.infradead.org/mailman/listinfo/linux-um
[1] linux-um-j...@lists.infradead.org
--
sigma star gmbh - Eduard-Bodem-Gasse 6 - 6020 Innsbruck - Austria
ATU66
101 - 144 of 144 matches
Mail list logo
