This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: prevent module unloading


Wondering, then how does the possibility of changing the $return value works?

On Wed, Oct 18, 2017 at 11:21 AM, Daniel Doron
<danielmeirdoron@gmail.com> wrote:
> Brilliant! thanks Arkady :-)
>
> On Wed, Oct 18, 2017 at 11:20 AM, Arkady <arkady.miasnikov@gmail.com> wrote:
>> Modifying syscall arguments in the SystemTap probe will not impact the
>> system call itself.
>> The krpobes copies the syscall arguments to a memory space allocated
>> specifically for the probe.
>> What the SystemTap probes see is a copy of the arguments user
>> application provided.
>>
>> If you want to "break" a system call you need to modify internal
>> kernel structures or the
>> original syscall stack. One approach could be to change the UID in the
>> beginning of the rmmod
>> and recover the UID in the end
>>
>> On Wed, Oct 18, 2017 at 11:13 AM, Daniel Doron
>> <danielmeirdoron@gmail.com> wrote:
>>> Hi,
>>>
>>> i am interested in protecting some modules unloading via SystemTap. I
>>> have contemplated modifying the name_user argument but i see it is
>>> passed as const. So does that mean that the pointer is pointing to a
>>> read only memory location in which case i have no way of modifying it?
>>> I wanted to change it to some non-existing module name which would
>>> result in an error...Or maybe there is a way to cast the const away
>>> and modify the name....?
>>>
>>> Ideas?
>>>
>>>
>>> Thanks,
>>> -Daniel.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]