Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1472775 > unrolled thread

Re: [PATCHv2 0/2] introduce get_task_exe_file and use it to fix audit_exe_compare

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCHv2 0/2] introduce get_task_exe_file and use it to fix  audit_exe_compare Richard Guy Briggs <rgb@redhat.com> - 2016-08-30 21:00 +0200
    Re: [PATCHv2 0/2] introduce get_task_exe_file and use it to fix  audit_exe_compare Mateusz Guzik <mguzik@redhat.com> - 2016-08-30 22:20 +0200

#1472775 — Re: [PATCHv2 0/2] introduce get_task_exe_file and use it to fix audit_exe_compare

On 2016-08-23 16:20, Mateusz Guzik wrote:
> audit_exe_compare directly accesses mm->exe_file without making sure the
> object is stable. Fixing it using current primitives results in
> partially duplicating what proc_exe_link is doing.
> 
> As such, introduce a trivial helper which can be used in both places and
> fix the func.
> 
> Changes since v1:
> * removed an unused 'out' label which crept in
> 
> Mateusz Guzik (2):
>   mm: introduce get_task_exe_file
>   audit: fix exe_file access in audit_exe_compare

The task_lock affects a much bigger struct than the mm ref count.  Is
this really necessary?  Is a spin-lock significantly lower cost than a
refcount?  Other than that, this refactorization looks sensible.

Acked-by: Richard Guy Briggs <rgb@redhat.com>

>  fs/proc/base.c       |  7 +------
>  include/linux/mm.h   |  1 +
>  kernel/audit_watch.c |  8 +++++---
>  kernel/fork.c        | 23 +++++++++++++++++++++++
>  4 files changed, 30 insertions(+), 9 deletions(-)
> 
> -- 
> 1.8.3.1
> 

- RGB

--
Richard Guy Briggs <rgb@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635

[toc] | [next] | [standalone]

#1472834

On Tue, Aug 30, 2016 at 02:50:21PM -0400, Richard Guy Briggs wrote:
> On 2016-08-23 16:20, Mateusz Guzik wrote:
> > audit_exe_compare directly accesses mm->exe_file without making sure the
> > object is stable. Fixing it using current primitives results in
> > partially duplicating what proc_exe_link is doing.
> > 
> > As such, introduce a trivial helper which can be used in both places and
> > fix the func.
> > 
> > Changes since v1:
> > * removed an unused 'out' label which crept in
> > 
> > Mateusz Guzik (2):
> >   mm: introduce get_task_exe_file
> >   audit: fix exe_file access in audit_exe_compare
> 
> The task_lock affects a much bigger struct than the mm ref count.  Is
> this really necessary?  Is a spin-lock significantly lower cost than a
> refcount?  Other than that, this refactorization looks sensible.
> 

proc_exe_link was taking the lock anyway to guarantee a stable mm.
I think the helper cleans the code up a little bit and there is
microoptimisation to not play with the refcount.

If audit_exe_compare has guarantees the task wont reach exit_mm, it can
use get_mm_exe_file which means the atomic op would be only on the file
object.

I was under the impression this is the expected behaviour, but your
patch used the task lock to grab mm, so I mimicked it here.

-- 
Mateusz Guzik

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web