netdev - Re: [PATCH v2 bpf-next 1/4] bpf: introduce task_vma bpf

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 4 Jan 2021 17:46:25 -0800
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Song Liu <songliubraving@...com>
Cc:     Yonghong Song <yhs@...com>,
        "bpf@...r.kernel.org" <bpf@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "ast@...nel.org" <ast@...nel.org>,
        "daniel@...earbox.net" <daniel@...earbox.net>,
        "andrii@...nel.org" <andrii@...nel.org>,
        "john.fastabend@...il.com" <john.fastabend@...il.com>,
        "kpsingh@...omium.org" <kpsingh@...omium.org>,
        Kernel Team <Kernel-team@...com>
Subject: Re: [PATCH v2 bpf-next 1/4] bpf: introduce task_vma bpf_iter

On Fri, Dec 18, 2020 at 05:23:25PM +0000, Song Liu wrote:
> 
> 
> > On Dec 18, 2020, at 8:38 AM, Yonghong Song <yhs@...com> wrote:
> > 
> > 
> > 
> > On 12/17/20 9:23 PM, Alexei Starovoitov wrote:
> >> On Thu, Dec 17, 2020 at 8:33 PM Song Liu <songliubraving@...com> wrote:
> >>>> 
> >>>> ahh. I missed that. Makes sense.
> >>>> vm_file needs to be accurate, but vm_area_struct should be accessed as ptr_to_btf_id.
> >>> 
> >>> Passing pointer of vm_area_struct into BPF will be tricky. For example, shall we
> >>> allow the user to access vma->vm_file? IIUC, with ptr_to_btf_id the verifier will
> >>> allow access of vma->vm_file as a valid pointer to struct file. However, since the
> >>> vma might be freed, vma->vm_file could point to random data.
> >> I don't think so. The proposed patch will do get_file() on it.
> >> There is actually no need to assign it into a different variable.
> >> Accessing it via vma->vm_file is safe and cleaner.
> > 
> > I did not check the code but do you have scenarios where vma is freed but old vma->vm_file is not freed due to reference counting, but
> > freed vma area is reused so vma->vm_file could be garbage?
> 
> AFAIK, once we unlock mmap_sem, the vma could be freed and reused. I guess ptr_to_btf_id
> or probe_read would not help with this?

Theoretically we can hack the verifier to treat some ptr_to_btf_id as "less
valid" than the other ptr_to_btf_id, but the user experience will not be great.
Reading such bpf prog will not be obvious. I think it's better to run bpf prog
in mmap_lock then and let it access vma->vm_file. After prog finishes the iter
bit can do if (mmap_lock_is_contended()) before iterating. That will deliver
better performance too. Instead of task_vma_seq_get_next() doing
mmap_lock/unlock at every vma. No need for get_file() either. And no
__vm_area_struct exposure.