On Sat, Aug 23, 2014 at 03:30:01PM +0200, Oleg Nesterov wrote:
> forgot to mention,
>
> On 08/23, Oleg Nesterov wrote:
> >
> > On 08/23, Cyrill Gorcunov wrote:
> >
> > > Looks like I need
> > > to use cred_guard_mutex instead of task_lock here, no?
On Sat, Aug 23, 2014 at 01:53:02PM +0200, Oleg Nesterov wrote:
> >
> > It should protect from allocation/devetion/mergin of another vma. IOW when
> > I lookup for vma I need to be sure it exist and won't disappear at least
> > while I validate it.
>
> plus you need mmap_sem (at least for reading)
validation and copying at the
beginning of prctl_set_mm_map before we take the lock.
Signed-off-by: Cyrill Gorcunov
CC: Oleg Nesterov
Cc: Kees Cook
Cc: Tejun Heo
Cc: Andrew Morton
Cc: Andrew Vagin
Cc: Eric W. Biederman
Cc: H. Peter Anvin
Cc: Serge Hallyn
Cc: Pavel Emelyanov
Cc: Vasiliy
Hi, here I addressed the comments from previous review pass (thanks a lot for
the comments btw). Please take a look. While these changes are sitting in -mm
tree we've an option to improve struct prctl_mm_map definition (versioning
and such. personally i don't see a need to add some new @version
@version member.
Also add BUILD_BUG_ON to make sure the structure is not bloated too much.
Signed-off-by: Cyrill Gorcunov
CC: Oleg Nesterov
Cc: Kees Cook
Cc: Tejun Heo
Cc: Andrew Morton
Cc: Andrew Vagin
Cc: Eric W. Biederman
Cc: H. Peter Anvin
Cc: Serge Hallyn
Cc: Pavel Emelyanov
Cc
Hi, here I addressed the comments from previous review pass (thanks a lot for
the comments btw). Please take a look. While these changes are sitting in -mm
tree we've an option to improve struct prctl_mm_map definition (versioning
and such. personally i don't see a need to add some new @version
@version member.
Also add BUILD_BUG_ON to make sure the structure is not bloated too much.
Signed-off-by: Cyrill Gorcunov gorcu...@openvz.org
CC: Oleg Nesterov o...@redhat.com
Cc: Kees Cook keesc...@chromium.org
Cc: Tejun Heo t...@kernel.org
Cc: Andrew Morton a...@linux-foundation.org
Cc: Andrew
validation and copying at the
beginning of prctl_set_mm_map before we take the lock.
Signed-off-by: Cyrill Gorcunov gorcu...@openvz.org
CC: Oleg Nesterov o...@redhat.com
Cc: Kees Cook keesc...@chromium.org
Cc: Tejun Heo t...@kernel.org
Cc: Andrew Morton a...@linux-foundation.org
Cc: Andrew Vagin ava
On Sat, Aug 23, 2014 at 01:53:02PM +0200, Oleg Nesterov wrote:
It should protect from allocation/devetion/mergin of another vma. IOW when
I lookup for vma I need to be sure it exist and won't disappear at least
while I validate it.
plus you need mmap_sem (at least for reading) when you
On Sat, Aug 23, 2014 at 03:30:01PM +0200, Oleg Nesterov wrote:
forgot to mention,
On 08/23, Oleg Nesterov wrote:
On 08/23, Cyrill Gorcunov wrote:
Looks like I need
to use cred_guard_mutex instead of task_lock here, no?
Please don't. First of all, it can't help because
problem (mostly to
avoid the usage of mm-start_stack) and ignores VM_GROWSUP.
Signed-off-by: Oleg Nesterov o...@redhat.com
Reviewed-by: Cyrill Gorcunov gorcu...@gmail.com
I don't understand this check either, the comment above it says nothing
but only commits what code is doing not explaining
On Sat, Aug 23, 2014 at 05:32:22PM +0200, Oleg Nesterov wrote:
Besides, it can't help anyway. cred_guard_mutex is per-process (not
per-thread),
suppose that a vfork()'ed child does prctl() while another thread reads
the
parent's /proc/pid/auxv.
Then either I need to use
On Sat, Aug 23, 2014 at 09:29:15PM +0200, Oleg Nesterov wrote:
On 08/23, Cyrill Gorcunov wrote:
On Sat, Aug 23, 2014 at 05:32:22PM +0200, Oleg Nesterov wrote:
And btw, where do you see RLIMIT_STACK in do_shmat() ?
Indirectly, though start_stack pointer. We assign
On Fri, Aug 22, 2014 at 01:46:28PM -0700, Andrew Morton wrote:
> On Sat, 23 Aug 2014 00:38:09 +0400 Cyrill Gorcunov wrote:
>
> > >
> > > Or will we? What happens if we later decide that some additional field
> > > needs to be added? Do we version the interfa
On Thu, Aug 21, 2014 at 11:49:12PM -0700, Andrew Morton wrote:
> > >
> > > But it's a bit hacky. Can anyone think of anything smarter?
> >
> > Looks good to me and not that hacky actually.
>
> Hacky :( I guess it's pretty safe because this is a userspace-visible
> structure so we'll never be
On Fri, Aug 22, 2014 at 09:22:41PM +0200, Oleg Nesterov wrote:
> Hi Cyrill,
>
> I think the patch is fine but I can't understand the usage of mmap_sem
> and alloc_lock,
>
> > + stack_vma = find_vma(mm, (unsigned long)prctl_map->start_stack);
>
> OK, find_vma() needs mmap_sem. But otherwise,
On Thu, Aug 21, 2014 at 06:50:33PM -0400, Peter Feiner wrote:
> On Fri, Aug 22, 2014 at 12:51:47AM +0300, Kirill A. Shutemov wrote:
> > > > One thing: there could be (I haven't checked) complications on
> > > > vma_merge(): since vm_flags are identical it assumes that it can reuse
> > > >
On Thu, Aug 21, 2014 at 03:51:15PM -0700, Andrew Morton wrote:
...
> >
> > Still note that updating exe-file link now doesn't require sys-resource
> > capability anymore, after all there is no much profit in preventing setup
> > own file link (there are a number of ways to execute own code --
On Thu, Aug 21, 2014 at 03:51:15PM -0700, Andrew Morton wrote:
...
Still note that updating exe-file link now doesn't require sys-resource
capability anymore, after all there is no much profit in preventing setup
own file link (there are a number of ways to execute own code -- ptrace,
On Thu, Aug 21, 2014 at 06:50:33PM -0400, Peter Feiner wrote:
On Fri, Aug 22, 2014 at 12:51:47AM +0300, Kirill A. Shutemov wrote:
One thing: there could be (I haven't checked) complications on
vma_merge(): since vm_flags are identical it assumes that it can reuse
vma-vm_page_prot of
On Fri, Aug 22, 2014 at 09:22:41PM +0200, Oleg Nesterov wrote:
Hi Cyrill,
I think the patch is fine but I can't understand the usage of mmap_sem
and alloc_lock,
+ stack_vma = find_vma(mm, (unsigned long)prctl_map-start_stack);
OK, find_vma() needs mmap_sem. But otherwise, why this
On Thu, Aug 21, 2014 at 11:49:12PM -0700, Andrew Morton wrote:
But it's a bit hacky. Can anyone think of anything smarter?
Looks good to me and not that hacky actually.
Hacky :( I guess it's pretty safe because this is a userspace-visible
structure so we'll never be changing it.
On Fri, Aug 22, 2014 at 01:46:28PM -0700, Andrew Morton wrote:
On Sat, 23 Aug 2014 00:38:09 +0400 Cyrill Gorcunov gorcu...@gmail.com wrote:
Or will we? What happens if we later decide that some additional field
needs to be added? Do we version the interface? Add a new prctl
On Thu, Aug 21, 2014 at 03:37:37PM -0400, Peter Feiner wrote:
>
> Thanks Kirill, I prefer your approach. I'll send a v2.
>
> I believe you're right about c9d0bf241451. It seems like passing the old & new
> pgprot through pgprot_modify would handle the problem. Furthermore, as you
> suggest,
On Thu, Aug 21, 2014 at 03:37:37PM -0400, Peter Feiner wrote:
Thanks Kirill, I prefer your approach. I'll send a v2.
I believe you're right about c9d0bf241451. It seems like passing the old new
pgprot through pgprot_modify would handle the problem. Furthermore, as you
suggest,
On Mon, Aug 04, 2014 at 09:22:55PM +0400, Cyrill Gorcunov wrote:
> Hi! Here is (I hope) a final version of the series (i've had a typo
> in check_data_rlimit helper, thanks serge.hallyn@ for spotting it).
>
> Please take a look once time permit (and drop previous two verisions
On Mon, Aug 04, 2014 at 09:22:55PM +0400, Cyrill Gorcunov wrote:
Hi! Here is (I hope) a final version of the series (i've had a typo
in check_data_rlimit helper, thanks serge.hallyn@ for spotting it).
Please take a look once time permit (and drop previous two verisions
from mbox). Thanks
On Sat, Aug 09, 2014 at 04:28:50PM +0200, Oleg Nesterov wrote:
> >
> > Hi Oleg, sorry for not responding to previous emails, will try to review
> > this
> > things tomorrow (from a glance looks quite good!). Btw, this moment strike
> > my
> > eyes -- why don't we use kmem_cache_zalloc here but
On Sat, Aug 09, 2014 at 04:28:50PM +0200, Oleg Nesterov wrote:
Hi Oleg, sorry for not responding to previous emails, will try to review
this
things tomorrow (from a glance looks quite good!). Btw, this moment strike
my
eyes -- why don't we use kmem_cache_zalloc here but do assign
On Fri, Aug 08, 2014 at 08:57:47PM +0200, Oleg Nesterov wrote:
...
> +++ b/fs/proc/inode.c
> @@ -73,6 +73,7 @@ static struct inode *proc_alloc_inode(struct super_block
> *sb)
> ei->pde = NULL;
> ei->sysctl = NULL;
> ei->sysctl_entry = NULL;
> + ei->pid_entry = NULL;
>
On Fri, Aug 08, 2014 at 08:57:47PM +0200, Oleg Nesterov wrote:
...
+++ b/fs/proc/inode.c
@@ -73,6 +73,7 @@ static struct inode *proc_alloc_inode(struct super_block
*sb)
ei-pde = NULL;
ei-sysctl = NULL;
ei-sysctl_entry = NULL;
+ ei-pid_entry = NULL;
ei-ns.ns =
y keep a local reference to the module owner and
use it later.
CC: Pavel Emelyanov
CC: Jiri Slaby
CC: Greg Kroah-Hartman
Signed-off-by: Cyrill Gorcunov
---
drivers/tty/tty_io.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: linux-2.6.git/drivers/tty/tt
On Thu, Aug 07, 2014 at 01:18:12PM +0400, Cyrill Gorcunov wrote:
> > mod = driver->owner;
> > tty_driver_kref_put(driver);
> > module_put(mod);
> >
> > Check the upstream whether the same issue exists there.
>
> Same in tty.git
>
> static
On Thu, Aug 07, 2014 at 01:05:28PM +0400, Pavel Emelyanov wrote:
> >
> > So how this code supposed to work then? I mean tty_driver_kref_put must
> > never call
> > for destruct_tty_driver, otherwise we're accessing freed memory.
>
> mod = driver->owner;
> tty_driver_kref_put(driver);
>
On Thu, Aug 07, 2014 at 12:28:58PM +0400, Pavel Emelyanov wrote:
> On 08/07/2014 12:25 PM, Cyrill Gorcunov wrote:
> > Hi guys, could you please explain me the sequence
> >
> > static void release_one_tty(struct work_struct *work)
> > {
> > struct tty_struct *t
Hi guys, could you please explain me the sequence
static void release_one_tty(struct work_struct *work)
{
struct tty_struct *tty =
container_of(work, struct tty_struct, hangup_work);
struct tty_driver *driver = tty->driver;
if (tty->ops->cleanup)
Hi guys, could you please explain me the sequence
static void release_one_tty(struct work_struct *work)
{
struct tty_struct *tty =
container_of(work, struct tty_struct, hangup_work);
struct tty_driver *driver = tty-driver;
if (tty-ops-cleanup)
On Thu, Aug 07, 2014 at 12:28:58PM +0400, Pavel Emelyanov wrote:
On 08/07/2014 12:25 PM, Cyrill Gorcunov wrote:
Hi guys, could you please explain me the sequence
static void release_one_tty(struct work_struct *work)
{
struct tty_struct *tty =
container_of(work, struct
On Thu, Aug 07, 2014 at 01:05:28PM +0400, Pavel Emelyanov wrote:
So how this code supposed to work then? I mean tty_driver_kref_put must
never call
for destruct_tty_driver, otherwise we're accessing freed memory.
mod = driver-owner;
tty_driver_kref_put(driver);
module_put(mod);
On Thu, Aug 07, 2014 at 01:18:12PM +0400, Cyrill Gorcunov wrote:
mod = driver-owner;
tty_driver_kref_put(driver);
module_put(mod);
Check the upstream whether the same issue exists there.
Same in tty.git
static void release_one_tty(struct work_struct *work)
{
---
From: Cyrill
Slaby jsl...@suse.cz
CC: Greg Kroah-Hartman gre...@linuxfoundation.org
Signed-off-by: Cyrill Gorcunov gorcu...@openvz.org
---
drivers/tty/tty_io.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: linux-2.6.git/drivers/tty/tty_io.c
>
> Todo:
>
> - Cleanup the tail_vma horror in m_start
>
> - Update task_nommu.c in the same way
>
> - Fix lock_trace() users
>
> Oleg.
(Sorry for delay) Thanks a lot, Oleg!
Acked-by: Cyrill Gorcunov
to whole series
--
To unsubscribe from this list: se
- Fix lock_trace() users
Oleg.
(Sorry for delay) Thanks a lot, Oleg!
Acked-by: Cyrill Gorcunov gorcu...@openvz.org
to whole series
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
On Tue, Aug 05, 2014 at 12:08:53PM +0400, Andrew Vagin wrote:
> >
> > Signed-off-by: Cyrill Gorcunov
> > Cc: Kees Cook
> > Cc: Tejun Heo
> > Cc: Andrew Morton
> > Cc: Andrew Vagin
>
> Acked-by: Andrew Vagin
>
> I have tested this patch
On Tue, Aug 05, 2014 at 12:08:53PM +0400, Andrew Vagin wrote:
Signed-off-by: Cyrill Gorcunov gorcu...@openvz.org
Cc: Kees Cook keesc...@chromium.org
Cc: Tejun Heo t...@kernel.org
Cc: Andrew Morton a...@linux-foundation.org
Cc: Andrew Vagin ava...@openvz.org
Acked-by: Andrew Vagin
Signed-off-by: Cyrill Gorcunov
Cc: Kees Cook
Cc: Tejun Heo
Cc: Andrew Morton
Cc: Andrew Vagin
Cc: Eric W. Biederman
Cc: H. Peter Anvin
Cc: Serge Hallyn
Cc: Pavel Emelyanov
Cc: Vasiliy Kulikov
Cc: KAMEZAWA Hiroyuki
Cc: Michael Kerrisk
Cc: Julien Tinnes
---
kernel/sys.c | 11
he size of currently supported struct prctl_mm_map.
v2:
- compact macros (by keescook@)
- wrap new code with CONFIG_ (by akpm@)
v3 (by jln@):
- use __prctl_check_order for brk and start_brk
- use may_adjust_brk helper
- make sure that only root can update @exe_fd link
Signed-off-by: Cyrill Gorc
Instead of taking mm->mmap_sem inside prctl_set_mm_exe_file move
it out of and rename the helper to prctl_set_mm_exe_file_locked.
This will allow to reuse this function in a next patch.
Signed-off-by: Cyrill Gorcunov
Cc: Kees Cook
Cc: Tejun Heo
Cc: Andrew Morton
Cc: Andrew Vagin
Cc: Eri
To eliminate code duplication lets introduce check_data_rlimit
helper which we will use in brk() and prctl() syscalls.
v2 (serge.hallyn@):
- need to check against RLIM_INFINITY rather than RLIMIT_DATA
Signed-off-by: Cyrill Gorcunov
Cc: Kees Cook
Cc: Tejun Heo
Cc: Andrew Morton
Cc: Andrew
Hi! Here is (I hope) a final version of the series (i've had a typo
in check_data_rlimit helper, thanks serge.hallyn@ for spotting it).
Please take a look once time permit (and drop previous two verisions
from mbox). Thanks!
Cyrill
--
To unsubscribe from this list: send the line
On Sun, Aug 03, 2014 at 11:18:43PM +0200, Oleg Nesterov wrote:
> On 08/03, Oleg Nesterov wrote:
> >
> > The question is, why m_start() calls mm_access(). This is not even
> > strictly correct if the task execs between m_stop() + m_start().
> >
> > Can't we do something like below? The patch is
On Sun, Aug 03, 2014 at 11:18:43PM +0200, Oleg Nesterov wrote:
On 08/03, Oleg Nesterov wrote:
The question is, why m_start() calls mm_access(). This is not even
strictly correct if the task execs between m_stop() + m_start().
Can't we do something like below? The patch is obviously
Hi! Here is (I hope) a final version of the series (i've had a typo
in check_data_rlimit helper, thanks serge.hallyn@ for spotting it).
Please take a look once time permit (and drop previous two verisions
from mbox). Thanks!
Cyrill
--
To unsubscribe from this list: send the line
Instead of taking mm-mmap_sem inside prctl_set_mm_exe_file move
it out of and rename the helper to prctl_set_mm_exe_file_locked.
This will allow to reuse this function in a next patch.
Signed-off-by: Cyrill Gorcunov gorcu...@openvz.org
Cc: Kees Cook keesc...@chromium.org
Cc: Tejun Heo t
To eliminate code duplication lets introduce check_data_rlimit
helper which we will use in brk() and prctl() syscalls.
v2 (serge.hallyn@):
- need to check against RLIM_INFINITY rather than RLIMIT_DATA
Signed-off-by: Cyrill Gorcunov gorcu...@openvz.org
Cc: Kees Cook keesc...@chromium.org
Cc
prctl_mm_map.
v2:
- compact macros (by keescook@)
- wrap new code with CONFIG_ (by akpm@)
v3 (by jln@):
- use __prctl_check_order for brk and start_brk
- use may_adjust_brk helper
- make sure that only root can update @exe_fd link
Signed-off-by: Cyrill Gorcunov gorcu...@openvz.org
Cc: Kees
Signed-off-by: Cyrill Gorcunov gorcu...@openvz.org
Cc: Kees Cook keesc...@chromium.org
Cc: Tejun Heo t...@kernel.org
Cc: Andrew Morton a...@linux-foundation.org
Cc: Andrew Vagin ava...@openvz.org
Cc: Eric W. Biederman ebied...@xmission.com
Cc: H. Peter Anvin h...@zytor.com
Cc: Serge Hallyn
age walk and sets soft-dirty according to the
> VMAs' VM_SOFTDIRTY flag.
>
> Signed-off-by: Peter Feiner
Acked-by: Cyrill Gorcunov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
.
Signed-off-by: Peter Feiner pfei...@google.com
Acked-by: Cyrill Gorcunov gorcu...@openvz.org
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
On Thu, Jul 31, 2014 at 01:31:30AM +0300, Kirill A. Shutemov wrote:
...
> >
> > *cringe*
> >
> > I don't like it. That really should be a responsiblity of specific
> > ->show();
> > "I'm going to take that mutex, bugger off if we are in execve()" makes a lot
> > more sense than having e.g.
On Thu, Jul 31, 2014 at 01:31:30AM +0300, Kirill A. Shutemov wrote:
...
*cringe*
I don't like it. That really should be a responsiblity of specific
-show();
I'm going to take that mutex, bugger off if we are in execve() makes a lot
more sense than having e.g. seq_read() care of
On Thu, Jul 24, 2014 at 07:32:25PM +, Serge Hallyn wrote:
> Quoting Cyrill Gorcunov (gorcu...@openvz.org):
> > To eliminate code duplication lets introduce may_adjust_brk
> > helper which we will use in brk() and prctl() syscalls.
> >
> > Signed-off-by: Cyrill
On Thu, Jul 24, 2014 at 12:31:54PM -0700, Kees Cook wrote:
...
> > +
> > +#ifdef CONFIG_STACK_GROWSUP
> > + if (may_adjust_brk(rlimit(RLIMIT_STACK),
> > + stack_vma->vm_end,
> > + prctl_map->start_stack, 0, 0))
> > +#else
> > + if
On Thu, Jul 24, 2014 at 12:18:56PM -0700, Kees Cook wrote:
> >
> > +static inline int may_adjust_brk(unsigned long rlim,
> > +unsigned long new_brk,
> > +unsigned long start_brk,
> > +unsigned long
On Thu, Jul 24, 2014 at 11:44:50AM -0700, Kees Cook wrote:
...
> >
> > The file can have a suid bit, so after executing it we may lose ability
> > to attach to it. To check that we can check that uid and gid is zero
> > in a current userns (local root).
> >
> > What else do we need to check?
>
>
Hi, here is a second version. I've tried to address all comments
(for which I'm really grateful). I believe the main question which
remains opened is exe-fd setup. Hopefully the current limitation
(root only) would be enough.
Also, Julien, there is no additional need for ordering test of
Signed-off-by: Cyrill Gorcunov
Cc: Kees Cook
Cc: Tejun Heo
Cc: Andrew Morton
Cc: Andrew Vagin
Cc: Eric W. Biederman
Cc: H. Peter Anvin
Cc: Serge Hallyn
Cc: Pavel Emelyanov
Cc: Vasiliy Kulikov
Cc: KAMEZAWA Hiroyuki
Cc: Michael Kerrisk
Cc: Julien Tinnes
---
kernel/sys.c | 10
To eliminate code duplication lets introduce may_adjust_brk
helper which we will use in brk() and prctl() syscalls.
Signed-off-by: Cyrill Gorcunov
Cc: Kees Cook
Cc: Tejun Heo
Cc: Andrew Morton
Cc: Andrew Vagin
Cc: Eric W. Biederman
Cc: H. Peter Anvin
Cc: Serge Hallyn
Cc: Pavel Emelyanov
Instead of taking mm->mmap_sem inside prctl_set_mm_exe_file move
it out of and rename the helper to prctl_set_mm_exe_file_locked.
This will allow to reuse this function in a next patch.
Signed-off-by: Cyrill Gorcunov
Cc: Kees Cook
Cc: Tejun Heo
Cc: Andrew Morton
Cc: Andrew Vagin
Cc: Eri
he size of currently supported struct prctl_mm_map.
v2:
- compact macros (by keescook@)
- wrap new code with CONFIG_ (by akpm@)
v3 (by jln@):
- use __prctl_check_order for brk and start_brk
- use may_adjust_brk helper
- make sure that only root can update @exe_fd link
Signed-off-by: Cyrill Gorc
On Thu, Jul 24, 2014 at 05:48:28PM +0400, Andrew Vagin wrote:
> On Tue, Jul 22, 2014 at 01:07:51PM -0700, Kees Cook wrote:
> > > - @exe_fd is referred from /proc/$pid/exe and when generating
> > >coredump. We uses prctl_set_mm_exe_file_locked helper to update
> > >this member, so exe-file
On Thu, Jul 24, 2014 at 05:48:28PM +0400, Andrew Vagin wrote:
On Tue, Jul 22, 2014 at 01:07:51PM -0700, Kees Cook wrote:
- @exe_fd is referred from /proc/$pid/exe and when generating
coredump. We uses prctl_set_mm_exe_file_locked helper to update
this member, so exe-file link
Instead of taking mm-mmap_sem inside prctl_set_mm_exe_file move
it out of and rename the helper to prctl_set_mm_exe_file_locked.
This will allow to reuse this function in a next patch.
Signed-off-by: Cyrill Gorcunov gorcu...@openvz.org
Cc: Kees Cook keesc...@chromium.org
Cc: Tejun Heo t
prctl_mm_map.
v2:
- compact macros (by keescook@)
- wrap new code with CONFIG_ (by akpm@)
v3 (by jln@):
- use __prctl_check_order for brk and start_brk
- use may_adjust_brk helper
- make sure that only root can update @exe_fd link
Signed-off-by: Cyrill Gorcunov gorcu...@openvz.org
Cc: Kees
To eliminate code duplication lets introduce may_adjust_brk
helper which we will use in brk() and prctl() syscalls.
Signed-off-by: Cyrill Gorcunov gorcu...@openvz.org
Cc: Kees Cook keesc...@chromium.org
Cc: Tejun Heo t...@kernel.org
Cc: Andrew Morton a...@linux-foundation.org
Cc: Andrew Vagin ava
Signed-off-by: Cyrill Gorcunov gorcu...@openvz.org
Cc: Kees Cook keesc...@chromium.org
Cc: Tejun Heo t...@kernel.org
Cc: Andrew Morton a...@linux-foundation.org
Cc: Andrew Vagin ava...@openvz.org
Cc: Eric W. Biederman ebied...@xmission.com
Cc: H. Peter Anvin h...@zytor.com
Cc: Serge Hallyn
Hi, here is a second version. I've tried to address all comments
(for which I'm really grateful). I believe the main question which
remains opened is exe-fd setup. Hopefully the current limitation
(root only) would be enough.
Also, Julien, there is no additional need for ordering test of
On Thu, Jul 24, 2014 at 11:44:50AM -0700, Kees Cook wrote:
...
The file can have a suid bit, so after executing it we may lose ability
to attach to it. To check that we can check that uid and gid is zero
in a current userns (local root).
What else do we need to check?
Yeah, I think
On Thu, Jul 24, 2014 at 12:18:56PM -0700, Kees Cook wrote:
+static inline int may_adjust_brk(unsigned long rlim,
+unsigned long new_brk,
+unsigned long start_brk,
+unsigned long end_data,
+
On Thu, Jul 24, 2014 at 12:31:54PM -0700, Kees Cook wrote:
...
+
+#ifdef CONFIG_STACK_GROWSUP
+ if (may_adjust_brk(rlimit(RLIMIT_STACK),
+ stack_vma-vm_end,
+ prctl_map-start_stack, 0, 0))
+#else
+ if
On Thu, Jul 24, 2014 at 07:32:25PM +, Serge Hallyn wrote:
Quoting Cyrill Gorcunov (gorcu...@openvz.org):
To eliminate code duplication lets introduce may_adjust_brk
helper which we will use in brk() and prctl() syscalls.
Signed-off-by: Cyrill Gorcunov gorcu...@openvz.org
Cc: Kees
On Tue, Jul 22, 2014 at 01:07:51PM -0700, Kees Cook wrote:
> On Fri, Jul 11, 2014 at 10:36 AM, Cyrill Gorcunov wrote:
> > On Wed, Jul 09, 2014 at 07:06:04PM +0400, Cyrill Gorcunov wrote:
> >>
> >> Thanks a lot for comments, Kees! I tend to agre, leaving off the @
On Tue, Jul 22, 2014 at 01:07:51PM -0700, Kees Cook wrote:
On Fri, Jul 11, 2014 at 10:36 AM, Cyrill Gorcunov gorcu...@gmail.com wrote:
On Wed, Jul 09, 2014 at 07:06:04PM +0400, Cyrill Gorcunov wrote:
Thanks a lot for comments, Kees! I tend to agre, leaving off the @prctl_map
variable out
Commit-ID: 5442e9fbd7c23172a1c9bc736629cd123a9923f0
Gitweb: http://git.kernel.org/tip/5442e9fbd7c23172a1c9bc736629cd123a9923f0
Author: Cyrill Gorcunov
AuthorDate: Wed, 16 Jul 2014 01:54:54 +0400
Committer: Thomas Gleixner
CommitDate: Fri, 18 Jul 2014 11:49:57 +0200
timerfd: Implement
Commit-ID: af9c4957cf212ad9cf0bee34c95cb11de5426e85
Gitweb: http://git.kernel.org/tip/af9c4957cf212ad9cf0bee34c95cb11de5426e85
Author: Cyrill Gorcunov
AuthorDate: Wed, 16 Jul 2014 01:54:52 +0400
Committer: Thomas Gleixner
CommitDate: Fri, 18 Jul 2014 11:49:57 +0200
timerfd: Implement
Commit-ID: 854d06d9fc350130617debdd9e9f49d1c4ba5206
Gitweb: http://git.kernel.org/tip/854d06d9fc350130617debdd9e9f49d1c4ba5206
Author: Cyrill Gorcunov
AuthorDate: Wed, 16 Jul 2014 01:54:53 +0400
Committer: Thomas Gleixner
CommitDate: Fri, 18 Jul 2014 11:49:57 +0200
docs: Procfs
Commit-ID: af9c4957cf212ad9cf0bee34c95cb11de5426e85
Gitweb: http://git.kernel.org/tip/af9c4957cf212ad9cf0bee34c95cb11de5426e85
Author: Cyrill Gorcunov gorcu...@openvz.org
AuthorDate: Wed, 16 Jul 2014 01:54:52 +0400
Committer: Thomas Gleixner t...@linutronix.de
CommitDate: Fri, 18 Jul
Commit-ID: 854d06d9fc350130617debdd9e9f49d1c4ba5206
Gitweb: http://git.kernel.org/tip/854d06d9fc350130617debdd9e9f49d1c4ba5206
Author: Cyrill Gorcunov gorcu...@openvz.org
AuthorDate: Wed, 16 Jul 2014 01:54:53 +0400
Committer: Thomas Gleixner t...@linutronix.de
CommitDate: Fri, 18 Jul
Commit-ID: 5442e9fbd7c23172a1c9bc736629cd123a9923f0
Gitweb: http://git.kernel.org/tip/5442e9fbd7c23172a1c9bc736629cd123a9923f0
Author: Cyrill Gorcunov gorcu...@openvz.org
AuthorDate: Wed, 16 Jul 2014 01:54:54 +0400
Committer: Thomas Gleixner t...@linutronix.de
CommitDate: Fri, 18 Jul
Hi, sorry for spamming, but in v4 I simply messed up in the series,
doing reply-to-reply with updated variants. So here are all patches
up to date on top of -rc5. Sorry again for resend.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
(by akpm@):
-Use define timerfd_show NULL for non c/r config
CC: Thomas Gleixner
CC: Andrew Morton
CC: Andrey Vagin
CC: Pavel Emelyanov
CC: Vladimir Davydov
Signed-off-by: Cyrill Gorcunov
---
fs/timerfd.c | 34 +-
1 file changed, 33 insertions(+), 1 deletion
on
the timer is woken up. The only purpose of this command is to restore
the expirations in a sake of checkpoint/restore procedure.
It requires the kernel to be built with CONFIG_CHECKPOINT_RESTORE
support.
Signed-off-by: Cyrill Gorcunov
CC: Michael Kerrisk
CC: Thomas
: Vladimir Davydov
Signed-off-by: Cyrill Gorcunov
---
fs/timerfd.c| 37 +
include/linux/timerfd.h |5 +
2 files changed, 42 insertions(+)
Index: linux-2.6.git/fs/timerfd.c
CC: Thomas Gleixner
CC: Andrew Morton
CC: Andrey Vagin
CC: Pavel Emelyanov
CC: Vladimir Davydov
Signed-off-by: Cyrill Gorcunov
---
Documentation/filesystems/proc.txt | 19 +++
1 file changed, 19 insertions(+)
Index: linux-2.6.git/Documentation/filesystems/proc.txt
On Tue, Jul 15, 2014 at 11:16:23PM +0200, Thomas Gleixner wrote:
> >
> > Maybe it's because of new -rc? Letme check...
>
> No, it's because its against an older version of your patches which
> lack the #ifdef PROC_FS around the show function
Crap. Sorry. Thomas, I'm fetching -rc5 now, I
On Tue, Jul 15, 2014 at 11:08:39PM +0200, Thomas Gleixner wrote:
> On Tue, 15 Jul 2014, Cyrill Gorcunov wrote:
>
> > On Tue, Jul 15, 2014 at 06:11:58PM +0200, Thomas Gleixner wrote:
> > > >
> > > > Dear sirs, ping?
> > >
> > > Hmm,
On Tue, Jul 15, 2014 at 06:11:58PM +0200, Thomas Gleixner wrote:
> >
> > Dear sirs, ping?
>
> Hmm, I was waiting for a V5, but it seems you just updated that single
> patch according to the review. I'll pick it up
Thanks a lot, Thomas!
--
To unsubscribe from this list: send the line
On Mon, Jun 30, 2014 at 11:43:54PM +0400, Cyrill Gorcunov wrote:
> On Mon, Jun 23, 2014 at 10:54:31PM +0400, Cyrill Gorcunov wrote:
> >
> > Hi guys, here is an updated version of c/r support for timerfd files. The
> > main change
> > is in how @ticks are restored in pat
On Mon, Jun 30, 2014 at 11:43:54PM +0400, Cyrill Gorcunov wrote:
On Mon, Jun 23, 2014 at 10:54:31PM +0400, Cyrill Gorcunov wrote:
Hi guys, here is an updated version of c/r support for timerfd files. The
main change
is in how @ticks are restored in patch 3 -- I switched to ioctl code
On Tue, Jul 15, 2014 at 06:11:58PM +0200, Thomas Gleixner wrote:
Dear sirs, ping?
Hmm, I was waiting for a V5, but it seems you just updated that single
patch according to the review. I'll pick it up
Thanks a lot, Thomas!
--
To unsubscribe from this list: send the line unsubscribe
801 - 900 of 2647 matches
Mail list logo
