mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Alexei Starovoitov <ast@fb.com>
To: Y Song <ys114321@gmail.com>,
	"Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>
Cc: netdev <netdev@vger.kernel.org>,
	Sandipan Das <sandipan@linux.vnet.ibm.com>,
	Brendan Gregg <brendan.d.gregg@gmail.com>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Martin KaFai Lau <kafai@fb.com>,
	Kees Cook <keescook@chromium.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH] bpf: Add helpers to read useful task_struct members
Date: Wed, 8 Nov 2017 06:39:28 +0900	[thread overview]
Message-ID: <fc6e7617-ee4e-b799-7565-bdfc4f7e0159@fb.com> (raw)
In-Reply-To: <CAH3MdRX-XehVX5A1O7+vxR+UuG46z7mRSMOer4hsxFYdKjWKUg@mail.gmail.com>

On 11/8/17 6:14 AM, Y Song wrote:
> On Tue, Nov 7, 2017 at 12:37 AM, Naveen N. Rao
> <naveen.n.rao@linux.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....

why is that?
When randomization is off both gcc and clang must generate the same
offsets, since it's C standard.

bcc rewriter issue is odd. I suspect it was broken from day one.
Meaning that bcc didn't support poking into anonymous union and structs.

> 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.

thanks for confirming. It means that gcc randomization plugin is broken
and has to be fixed with regard to adjusting debug info while
randomizing the fields.

  parent reply	other threads:[~2017-11-07 21:40 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-03  6:58 Sandipan Das
2017-11-04  9:34 ` Alexei Starovoitov
2017-11-04 17:31   ` Naveen N. Rao
2017-11-04 21:10     ` Alexei Starovoitov
2017-11-06 15:55       ` Naveen N. Rao
2017-11-07  8:08         ` Alexei Starovoitov
2017-11-07  8:37           ` Naveen N. Rao
2017-11-07 21:14             ` Y Song
2017-11-07 21:31               ` Atish Patra
2017-11-07 21:45                 ` Y Song
2017-11-07 21:39               ` Alexei Starovoitov [this message]
2017-11-07 21:47                 ` Y Song
2017-11-07 22:04                   ` Alexei Starovoitov
2017-11-07 22:42                     ` Y Song
2017-11-08  0:29                       ` Atish Patra
2017-11-08  1:25                         ` Y Song
2017-11-06  5:16     ` Sandipan Das
2017-11-07  0:16 ` Tushar Dave

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fc6e7617-ee4e-b799-7565-bdfc4f7e0159@fb.com \
    --to=ast@fb.com \
    --cc=brendan.d.gregg@gmail.com \
    --cc=daniel@iogearbox.net \
    --cc=kafai@fb.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=naveen.n.rao@linux.vnet.ibm.com \
    --cc=netdev@vger.kernel.org \
    --cc=sandipan@linux.vnet.ibm.com \
    --cc=ys114321@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome