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:   Tue, 7 Nov 2017 15:31:34 -0600
From:   Atish Patra <atish.patra@...cle.com>
To:     Y Song <ys114321@...il.com>,
        "Naveen N. Rao" <naveen.n.rao@...ux.vnet.ibm.com>
Cc:     Alexei Starovoitov <ast@...com>, netdev <netdev@...r.kernel.org>,
        Sandipan Das <sandipan@...ux.vnet.ibm.com>,
        Brendan Gregg <brendan.d.gregg@...il.com>,
        Daniel Borkmann <daniel@...earbox.net>,
        Martin KaFai Lau <kafai@...com>,
        Kees Cook <keescook@...omium.org>, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] bpf: Add helpers to read useful task_struct members

On 11/07/2017 03:14 PM, Y Song wrote:
> On Tue, Nov 7, 2017 at 12:37 AM, Naveen N. Rao
> <naveen.n.rao@...ux.vnet.ibm.com> wrote:
>> Alexei Starovoitov wrote:
>>>
>>> On 11/7/17 12:55 AM, Naveen N. Rao wrote:
>>>>>
>>>>> I thought such struct shouldn't change layout.
>>>>> If it is we need to fix include/linux/compiler-clang.h to do that
>>>>> anon struct as well.
>>>>
>>>>
>>>> We considered that, but it looked to be very dependent on the version of
>>>> gcc used to build the kernel. But, this may be a simpler approach for
>>>> the shorter term.
>>>>
>>>
>>> why it would depend on version of gcc?
>>
>>
>> From what I can see, randomized_struct_fields_start is defined only for gcc
>>> = 4.6. For older versions, it does not get mapped to an anonymous
>> structure. We may not care for older gcc versions, but..
>>
>> The other issue was that __randomize_layout maps to __designated_init when
>> randstruct plugin is not enabled, which is in turn an attribute on gcc >=
>> v5.1, but not otherwise.
>>
>>> We just need this, no?
>>>
>>> diff --git a/include/linux/compiler-clang.h
>>> b/include/linux/compiler-clang.h
>>> index de179993e039..4e29ab6187cb 100644
>>> --- a/include/linux/compiler-clang.h
>>> +++ b/include/linux/compiler-clang.h
>>> @@ -15,3 +15,6 @@
>>>    * with any version that can compile the kernel
>>>    */
>>>   #define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix),
>>> __COUNTER__)
>>> +
>>> +#define randomized_struct_fields_start struct {
>>> +#define randomized_struct_fields_end   };
>>>
>>> since offsets are mandated by C standard.
>>
>>
>> Yes, this is what we're testing with and is probably sufficient for our
>> purposes.
>
> Just tested this with bcc. bcc actually complains. the rewriter
> is not able to rewrite prev->pid where prev is "struct task_struct *prev".
> I will change bcc rewriter to see whether the field value is correct or not.
>
> Not sure my understanding is correct or not, but I am afraid that
> the above approach for clang compiler change may not work.
> If clang calculates the field offset based on header file, the offset
> may not be the same as kernel one....
>
> I verified that the drawf info with randomized structure config does not
> match randomized structure member offset. Specifically, I tried
> linux/proc_ns.h struct proc_ns_operations,
> dwarf says:
>   field name: offset 0
>   field real_ns_name: offset 8
> But if you print out the real offset at runtime, you get 40 and 16 respectively.
>
I am also trying to get it work with bcc as any python scripts that 
access task_struct gives wrong output (task_switch.py, runqlen.py). I 
recompiled my kernel (4.14-rc7 & bcc) with the patch.

I am seeing following error.
# ./task_switch.py
/virtual/main.c:17:18: warning: implicit declaration of function 
'bpf_get_task_pid_tgid' is invalid in C99
       [-Wimplicit-function-declaration]
   key.prev_pid = bpf_get_task_pid_tgid(prev);
                  ^
1 warning generated.
LLVM ERROR: Program used external function 'bpf_get_task_pid_tgid' which 
could not be resolved!

Are you also seeing the same issue or something else ?

Regards,
Atish
>>
>> - Naveen
>>
>>
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ