er while the
second introduces a new option.
Signed-off-by: Amnon Shiloh.
Best Regards,
Amnon.
> On Fri, 22 Feb 2013 12:18:01 +1100 (EST)
> u3...@miso.sublimeip.com (Amnon Shiloh) wrote:
>
> > The code in "kernel/sys.c" that is currently within
> > CONFIG_CHECKPOI
er while the
second introduces a new option.
Signed-off-by: Amnon Shiloh.
Best Regards,
Amnon.
> On Fri, 22 Feb 2013 12:18:01 +1100 (EST)
> u3...@miso.sublimeip.com (Amnon Shiloh) wrote:
>
> > The code in "kernel/sys.c" that is currently within
> > CONFIG_CHECKPOI
.
Signed-off-by: Amnon Shiloh.
Best Regards,
Amnon.
On Fri, 22 Feb 2013 12:18:01 +1100 (EST)
u3...@miso.sublimeip.com (Amnon Shiloh) wrote:
The code in kernel/sys.c that is currently within
CONFIG_CHECKPOINT_RESTORE is in fact, as I explain below,
one possible solution to a general issue
.
Signed-off-by: Amnon Shiloh.
Best Regards,
Amnon.
On Fri, 22 Feb 2013 12:18:01 +1100 (EST)
u3...@miso.sublimeip.com (Amnon Shiloh) wrote:
The code in kernel/sys.c that is currently within
CONFIG_CHECKPOINT_RESTORE is in fact, as I explain below,
one possible solution to a general issue
:
>
> On Thu, 21 Feb 2013 12:00:28 +0400
> Cyrill Gorcunov wrote:
>
> > From: Amnon Shiloh
> > Subject: prctl: Make PR_SET_MM being depend on own CONFIG_MM_FIELDS_SETTING
> >
> > ...
> >
> > Signed-off-by: Amnon Shiloh
>
> The "..
Hi,
Cyrill Gorcunov wrote:
> Wouldn't the below do the same trick but eliminate OR in preproc code?
Yes it would. I don't mind having it either way.
Best Regards,
Amnon.
> ---
> From: Amnon Shiloh
> Subject: prctl: Make PR_SET_MM being depend on own CONFIG_MM_FI
Hi,
Cyrill Gorcunov wrote:
Wouldn't the below do the same trick but eliminate OR in preproc code?
Yes it would. I don't mind having it either way.
Best Regards,
Amnon.
---
From: Amnon Shiloh u3...@miso.sublimeip.com
Subject: prctl: Make PR_SET_MM being depend on own
...@openvz.org wrote:
From: Amnon Shiloh u3...@miso.sublimeip.com
Subject: prctl: Make PR_SET_MM being depend on own CONFIG_MM_FIELDS_SETTING
...
Signed-off-by: Amnon Shiloh u3...@miso.sublimeip.com
The ... makes me sad.
If/when this patch gets sent for real, please explain
Cyrill Gorcunov wrote:
>> Another possibility is to have a dual #if:
>>
>> #if defined(CONFIG_CHECKPOINT_RESTORE) || defined(CONFIG_MM_FIELDS_SETTING)
>
> Thus this approach looks preferred. And MM_FIELDS_SETTING will be y by
> default.
> Mind to cook a patch and lets see if community accept it?
Hi Cyrill,
Cyrill Gorcunov wrote:
> I see. Thanks for explanation! Thus we need some new config option which would
> enable this prctl opcodes (y by default), in turn config-checkpoint-restore
> kconfig option need to select this feature if set. Sounds reasonable?
Yes, This would be one
Hi Cyrill,
Cyrill Gorcunov wrote:
> On Tue, Feb 19, 2013 at 05:25:31PM +1100, Amnon Shiloh wrote:
> >
> > To reconstruct Linux process(es), one must be able to restore all their
> > memory contents, states and registers to their original and consistent
> > values.
&
Hi Cyrill,
Cyrill Gorcunov wrote:
On Tue, Feb 19, 2013 at 05:25:31PM +1100, Amnon Shiloh wrote:
To reconstruct Linux process(es), one must be able to restore all their
memory contents, states and registers to their original and consistent
values.
I personally don't mind if this come
Hi Cyrill,
Cyrill Gorcunov wrote:
I see. Thanks for explanation! Thus we need some new config option which would
enable this prctl opcodes (y by default), in turn config-checkpoint-restore
kconfig option need to select this feature if set. Sounds reasonable?
Yes, This would be one possible
Cyrill Gorcunov wrote:
Another possibility is to have a dual #if:
#if defined(CONFIG_CHECKPOINT_RESTORE) || defined(CONFIG_MM_FIELDS_SETTING)
Thus this approach looks preferred. And MM_FIELDS_SETTING will be y by
default.
Mind to cook a patch and lets see if community accept it? Don't
Steven Rostedt wrote:
> If only you, or a few people are using it (ie. distros don't see a
> need), then it will be up to you to make the changes.
I believe that this functionality is of a general nature and is needed
by many, not only by myself and by the CRIU group, but by all user-level
Steven Rostedt wrote:
> On Mon, 2013-02-18 at 12:39 +1100, Amnon Shiloh wrote:
> > Hello,
> >
> > The code in "kernel/sys.c" provides the "prctl(PR_SET_MM)" function,
> > which is the only way a process can set or modify the following 11
> >
Steven Rostedt wrote:
On Mon, 2013-02-18 at 12:39 +1100, Amnon Shiloh wrote:
Hello,
The code in kernel/sys.c provides the prctl(PR_SET_MM) function,
which is the only way a process can set or modify the following 11
per-process fields:
start_code, end_code, start_data
Steven Rostedt wrote:
If only you, or a few people are using it (ie. distros don't see a
need), then it will be up to you to make the changes.
I believe that this functionality is of a general nature and is needed
by many, not only by myself and by the CRIU group, but by all user-level
Hello,
The code in "kernel/sys.c" provides the "prctl(PR_SET_MM)" function,
which is the only way a process can set or modify the following 11
per-process fields:
start_code, end_code, start_data, end_data, start_brk, brk,
start_stack, arg_start, arg_end, env_start, env_end.
Hello,
The code in kernel/sys.c provides the prctl(PR_SET_MM) function,
which is the only way a process can set or modify the following 11
per-process fields:
start_code, end_code, start_data, end_data, start_brk, brk,
start_stack, arg_start, arg_end, env_start, env_end.
Being
by glibc) will take the process back
to where it was before the interrupt happend, inside the vdso page.
Best Regards,
Amnon.
> On Mon, Nov 26, 2012 at 11:55:01PM +1100, Amnon Shiloh wrote:
> >
> > You could of course keep that old code and modify only the very
> > first instructio
26 Cyrill Gorcunov :
> > On Thu, Nov 22, 2012 at 05:12:38PM +0100, Oleg Nesterov wrote:
> >> On 11/22, Amnon Shiloh wrote:
> >> >
> >> > Now however, that "vsyscall" was effectively replaced by vdso, it
> >> > creates a new problem for
...@openvz.org:
On Thu, Nov 22, 2012 at 05:12:38PM +0100, Oleg Nesterov wrote:
On 11/22, Amnon Shiloh wrote:
Now however, that vsyscall was effectively replaced by vdso, it
creates a new problem for me and probably for anyone else who uses
some form of checkpoint/restore:
Oh, sorry, I
back
to where it was before the interrupt happend, inside the vdso page.
Best Regards,
Amnon.
On Mon, Nov 26, 2012 at 11:55:01PM +1100, Amnon Shiloh wrote:
You could of course keep that old code and modify only the very
first instruction of each routine into a jump instruction
Hi Oleg,
> > 2) I was then told (in my own words): "oh, don't worry, the vsyscall page
> >has now been minimized, all it contains now is *real* system calls,
> >and it always calls them".
>
> Not sure where did you get this idea ;) From the very beginning you were
> told that EMULATE
Hi Oleg,
2) I was then told (in my own words): oh, don't worry, the vsyscall page
has now been minimized, all it contains now is *real* system calls,
and it always calls them.
Not sure where did you get this idea ;) From the very beginning you were
told that EMULATE mode doesn't
I think that allowing to set the x86 debug-registers to the
vsyscall page is more elegant - but do whatever you prefer.
Best Regards,
Amnon.
> forgot to mention...
>
> On 11/23, Oleg Nesterov wrote:
> >
> > On 11/23, Amnon Shiloh wrote:
> > >
> > > Or,
n is still under
discussion.
8) Any solution that allows a ptracer to prevent its traced process
from entering the vsyscall page and execute there system-calls
unchecked (thus in effect escape its jailer), would do for me.
Best Regards,
Amnon.
>
> On 11/23, Amnon Shiloh wrote:
> >
Hi Oleg,
> Amnon,
>
> I am going to "ignore" this thread because this is not my area and
> I can't help anyway. Just one note:
>
> On 11/23, Amnon Shiloh wrote:
> >
> > The solution can be to hold all catched signals while in the VDSO page.
> &g
Hi Oleg,
Amnon,
I am going to ignore this thread because this is not my area and
I can't help anyway. Just one note:
On 11/23, Amnon Shiloh wrote:
The solution can be to hold all catched signals while in the VDSO page.
...
1) + introduce a kernel feature to prevent
catching
that allows a ptracer to prevent its traced process
from entering the vsyscall page and execute there system-calls
unchecked (thus in effect escape its jailer), would do for me.
Best Regards,
Amnon.
On 11/23, Amnon Shiloh wrote:
What I discovered now, is that PTRACE_SYSCALL (also
debug-registers to the
vsyscall page is more elegant - but do whatever you prefer.
Best Regards,
Amnon.
forgot to mention...
On 11/23, Oleg Nesterov wrote:
On 11/23, Amnon Shiloh wrote:
Or, there is an alternative: if only I (the ptracer or the traced process)
was allowed
ocess will get a SIGSEGV signal, which
the ptracer can easily handle.
Best Regards,
Amnon.
> On 11/22, Amnon Shiloh wrote:
> >
> > Now however, that "vsyscall" was effectively replaced by vdso, it
> > creates a new problem for me and probably for anyone else who uses
&
handle.
Best Regards,
Amnon.
On 11/22, Amnon Shiloh wrote:
Now however, that vsyscall was effectively replaced by vdso, it
creates a new problem for me and probably for anyone else who uses
some form of checkpoint/restore:
Oh, sorry, I can't help here. I can only add Cyrill and Pavel
Hi Pavel,
> >>
> >> Now however, that "vsyscall" was effectively replaced by vdso, it
> >> creates a new problem for me and probably for anyone else who uses
> >> some form of checkpoint/restore:
> >
> > Oh, sorry, I can't help here. I can only add Cyrill and Pavel, they
> > seem to enjoy trying
Hi Pavel,
Now however, that vsyscall was effectively replaced by vdso, it
creates a new problem for me and probably for anyone else who uses
some form of checkpoint/restore:
Oh, sorry, I can't help here. I can only add Cyrill and Pavel, they
seem to enjoy trying to solve the c/r
Hi Oleg,
Yes, I can see that "arch/x86/kernel/vsyscall_64.c"
has changed dramatically since I last looked at it.
Since this is the case, I no longer need to trap the vsyscall page.
Now however, that "vsyscall" was effectively replaced by vdso, it
creates a new problem for me and probably for
Hi Oleg,
Yes, I can see that arch/x86/kernel/vsyscall_64.c
has changed dramatically since I last looked at it.
Since this is the case, I no longer need to trap the vsyscall page.
Now however, that vsyscall was effectively replaced by vdso, it
creates a new problem for me and probably for anyone
d in a critical
section or in the middle of a mutex operation, the other threads are
not going to be that happy...
Whether per-process or per-thread, this should be easier to implement
and have a clearer interface than "SA_NOSECURITY".
Best Regards,
Amnon.
> On 11/08, Amnon Shiloh wrote
eed to read the kernel code more to make extra sure it has no
unwanted side effects.
Best Regards,
Amnon.
Oleg Nesterov wrote:
>
> Hi Amnon,
>
> On 11/08, Amnon Shiloh wrote:
> >
> > Thanks for the patch, I tried it and it works nicely!
>
> OK, thanks. I'll wait for o
to read the kernel code more to make extra sure it has no
unwanted side effects.
Best Regards,
Amnon.
Oleg Nesterov wrote:
Hi Amnon,
On 11/08, Amnon Shiloh wrote:
Thanks for the patch, I tried it and it works nicely!
OK, thanks. I'll wait for other comments a bit and then send
per-process or per-thread, this should be easier to implement
and have a clearer interface than SA_NOSECURITY.
Best Regards,
Amnon.
On 11/08, Amnon Shiloh wrote:
What I wish is that I could request (using prctl or whatever):
If a non-privileged user sends me a SIGSTOP, then let
ition, only the super-user (or CAP_SYS_ADMIN, etc.) should be
allowed to set/reset PF_NO_SIGSTOP (and if taking up a precious PF_xxx
flag is a problem, then the flag could be somewhere else).
Thanks,
Amnon.
Oleg Nesterov wrote:
>
> (add lkml/cc's)
>
> On 11/07, Amnon Shiloh wrote:
&
be somewhere else).
Thanks,
Amnon.
Oleg Nesterov wrote:
(add lkml/cc's)
On 11/07, Amnon Shiloh wrote:
Quoting Oleg Nesterov (o...@redhat.com):
On 11/06, Amnon Shiloh wrote:
What I would IDEALLY like to have is a call, probably a ptrace option,
where the parent can
44 matches
Mail list logo
