linux-kernel - Re: [PATCH 0/7] Uprobes: Support SDT markers having reference count (semaphore)

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]

Message-Id: <71f19b63-a641-1705-f087-a39b8b81c4be@linux.ibm.com>
Date:   Fri, 8 Jun 2018 12:04:25 +0530
From:   Ravi Bangoria <ravi.bangoria@...ux.ibm.com>
To:     Masami Hiramatsu <mhiramat@...nel.org>
Cc:     oleg@...hat.com, srikar@...ux.vnet.ibm.com, rostedt@...dmis.org,
        peterz@...radead.org, mingo@...hat.com, acme@...nel.org,
        alexander.shishkin@...ux.intel.com, jolsa@...hat.com,
        namhyung@...nel.org, linux-kernel@...r.kernel.org, corbet@....net,
        linux-doc@...r.kernel.org, ananth@...ux.vnet.ibm.com,
        alexis.berlemont@...il.com, naveen.n.rao@...ux.vnet.ibm.com,
        Ravi Bangoria <ravi.bangoria@...ux.ibm.com>
Subject: Re: [PATCH 0/7] Uprobes: Support SDT markers having reference count
 (semaphore)

Hi Masami,

>> So for kernel modules,
>>
>> is it fine to change current ABI from
>>     uprobe_register(inode, offset, consumer)
>> to
>>     uprobe_register(inode, offset, ref_ctr_offset, consumer)
>>
>> Or I should introduce new function for this:
>>     uprobe_register_refctr(inode, offset, ref_ctr_offset, consumer)
>> and export it to kernel module?
>>
>> What's your suggestion?
> 
> Latter is fine to me. Since the refctr is introduced totally in userspace
> (for SDT) and free-address userspace probing doesn't need refctr, maybe
> we should keep those separated.

Sure.

> 
>> [...]
>>
>>>>
>>>>  - This patches still has one issue. If there are multiple instances of
>>>>    same application running and user wants to trace any particular
>>>>    instance, trace_uprobe is updating reference counter in all instances.
>>>>    This is not a problem on user side because instruction is not replaced
>>>>    with trap/int3 and thus user will only see samples from his interested
>>>>    process. But still this is more of a correctness issue. I'm working on
>>>>    a fix for this.
>>>
>>> Hmm, it sounds like not a correctness issue, but there maybe a performace
>>> tradeoff. Tracing one particulear instance, other instances also will get
>>> a performance loss
>>
>>
>> Right, but it's temporary. I mean, putting everything in to this series was making
>> it complex. So this is the initial one and I'll send followup patches which will
>> optimize the reference counter update.
> 
> Ah, OK. If you have prepared the followup patches, could you also send it
> with this series? Perhups it will help us to understand the issue clearer.

Not ready as such.. it's making the code bit complicated. I'm working on it
and will send the next series with those patches included.

> 
>>
>>> (Only if the parameter preparation block is heavy,
>>> because the heaviest part of probing - trap/int3 and recording data - isn't
>>> executed.)
>>>> BTW, why this happens? I thought the refcounter part is just a data which
>>> is not shared among processes...
>>>
>>
>> This happens because we are not calling consumer_filter function. consumer_filter
>> is the one who decides whether to change the instruction to trap or not in a given
>> mm. We also need to call it before updating reference counter.
> 
> Hmm, it sounds simple... maybe we can increment refctr in install_breakpoint/
> remove_breakpoint?

Not really, it would be simpler if I can put it inside install_breakpoint().
Consider an mmap() case. Probed instruction resides in the text section whereas
reference counter resides in the data section. These sections gets mapped using
separate mmap() calls. So, when process mmaps the text section we will change the
instruction, but section holding the reference counter may not have been mapped
yet in the virtual memory. If so, we will fail to update the reference counter.

Thanks,
Ravi