ltogether 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
> > CONFI
ltogether 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
> > CONFI
wrote:
>
> 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 CO
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 possible
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.
&
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
softwa
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
> >
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.
Bein
ssued 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
/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 pr
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
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,
that this option 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
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.
>
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
&
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 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 any
just one thread 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
nted,
I will need 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, than
ig) {
...
In addition, 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,
22 matches
Mail list logo
