Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
Message-ID: <5c2c046c-ed85-3718-223f-b74a05d0b483@fb.com>
Date:   Wed, 18 May 2022 13:57:20 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
 Gecko/20100101 Thunderbird/91.9.0
Subject: Re: [PATCH bpf v3 2/2] bpf_trace: bail out from
 bpf_kprobe_multi_link_attach when in compat
Content-Language: en-US
To:     Eugene Syromiatnikov <esyr@redhat.com>
Cc:     Jiri Olsa <jolsa@kernel.org>,
        Masami Hiramatsu <mhiramat@kernel.org>,
        Steven Rostedt <rostedt@goodmis.org>,
        Ingo Molnar <mingo@redhat.com>,
        Alexei Starovoitov <ast@kernel.org>,
        Daniel Borkmann <daniel@iogearbox.net>,
        Andrii Nakryiko <andrii@kernel.org>,
        Martin KaFai Lau <kafai@fb.com>,
        Song Liu <songliubraving@fb.com>,
        John Fastabend <john.fastabend@gmail.com>,
        KP Singh <kpsingh@kernel.org>, netdev@vger.kernel.org,
        bpf@vger.kernel.org, linux-kernel@vger.kernel.org
References: <cover.1652876187.git.esyr@redhat.com>
 <47cbdb76178a112763a3766a03d8cc51842fcab0.1652876188.git.esyr@redhat.com>
 <7bbb4a95-0d12-2a8f-9503-2613d774eaaa@fb.com>
 <20220518200358.GB29226@asgard.redhat.com>
From:   Yonghong Song <yhs@fb.com>
In-Reply-To: <20220518200358.GB29226@asgard.redhat.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Qko0WXFiWFhlOHJTN3NwUXd5SVJ2aUNWTkhnMnN4OWFLVDhtRDJrd0ROdHNa?=
 =?utf-8?B?Smg1NzAvR2JOdWZUdkEwUmk5ZmZYeTkzTWhhdWU3V2xJWHhwR3hsK1pwNFUy?=
 =?utf-8?B?Wm8xVGNRR3E2K1d0QW8rckZ6V1haOGxMK3MrQVFPa1FxL0JJS3hiYW9XRGlx?=
 =?utf-8?B?d0tEM2tjb3RYMVp1TmE0bTNTRUpQRzV2VURWelE0MEpQdW9GZzJ1TkNUYWV6?=
 =?utf-8?B?NjNLT0VQdzNiaGdwUFFsYlFzQzc5UzZLZjhIaXk3SXcvMXh6Z3psNm9LMG1R?=
 =?utf-8?B?dDh4eUl0WnlPRmI0R2hXNWk1NTZHVmNOVDRIM1pyQU8rMDNadmV4MlhxcEpF?=
 =?utf-8?B?Nm1DMHRtdXRteEd1TU4vTHVuWllQd0s0Zmc0ZGdZWWtwQS8ydVRpUFlnNzRn?=
 =?utf-8?B?Y1djOGdSZ0hyT1kwcUpTWlFocy9tTzJVVVIyUEhMVndQR0srbmhTclpGVW1B?=
 =?utf-8?B?cjZzdGo4NUlPV1lSaVI2WnphS1EwbkplL09qbjJ3UjdnbWw1bVRJRWVUM2h1?=
 =?utf-8?B?TEtkRGg3NGVIdjY4L0tzUTM1dTRJWDkyQVNuaDVMK0xLN2NZM2pnenNTZ2pH?=
 =?utf-8?B?Y0tRNG5DUmxubXc4cjg2VE1Ldkc3aVRLL3FFVmxhbGFWeUs1S0RMTWcrUnZJ?=
 =?utf-8?B?OXYwUmpHb2V5cDYwNXp0Z1FwV2gySlBkSmhpUVdQUzkyc1hDMFVaM3pRL253?=
 =?utf-8?B?R1Y4Y0p3WVNiZjhLbDJMWE43NFhPcThPdTk0N0JPeFpReE9Cb1pRRi9YZkdH?=
 =?utf-8?B?cThUSXl2TG5DSmhyekJES2IwOUNyYnhvV09FRWJwejZEM054bGVmVU5IbFpV?=
 =?utf-8?B?RGNPTFdYeEtNSnNkUnZQQ25IMjlCTkw4WTFkdEp5STNWclZtRmZKbHpzMXda?=
 =?utf-8?B?bHFkdFBKcThLMGdQZnlpM0RyRnZkY0FzOEQ5VUlTcTY3WEdCMldYUTJwdjc2?=
 =?utf-8?B?RXJIbFNPaGdWTzluckZOeEwwZjVicnJKRFZoY09PL05ORUNWdk1MemR2aHNw?=
 =?utf-8?B?VXlYRmFaYURIZ1YzWVhVWlJzS09aRlo3Z0diTmsrc1ZzWHZJZVl5eHpEakpY?=
 =?utf-8?B?clh3VSt6UGVKRkZWdXcvSnkzWEkycDdFZGNDT1JkRVhaWGRFQ0xiRTkrb25M?=
 =?utf-8?B?bWtJMExCbkRMcVd6QmhMQ2hVWTVteXVQYU9JcVpDYnQvRGNIalA3Y09QMGpo?=
 =?utf-8?B?UWt5SkY5VVAyQXFmcXZFYzI0VHlIMjRJdUl3VWhXRTI2RVMzdGUySDdTYUlG?=
 =?utf-8?B?MEc2UFFqNHlXOTY2bitlWTNnaE1lSTdrUDdZSFI5V0QvbHYwc2VXclZJWDZt?=
 =?utf-8?B?Y1FaMnVRdE9jcUxlOUFOM3Q2N2pBNVBHV1RZeUdrdlVSU0wxc3diekUwbG16?=
 =?utf-8?B?NkVQRm1hT2wxNk90VFp4T1BlTnNTN1N1ZTVZTW15SDBoUVJ6SFFDTjJ3NnBn?=
 =?utf-8?B?Y1RheGttdkdQaHNvaTgza29KT1VwK1VVR0JDbkNZcUZxNENqNXdna2xlYnNR?=
 =?utf-8?B?Qlp2dWd6dW5uZS8rRGFRaHNNVkkyNFJab05xTjBzWEdTanF5NmMvaTdCSzB2?=
 =?utf-8?B?VU1VVzMyNmZlamE0SXFHQUkyZnk2VTN5WEpwVU5ITy9UdVlVRk94QTNJUU5N?=
 =?utf-8?B?dmptWjA5d3d1Z1ZTQ21HVndTbEVJQ2pUVUcreUhvTEhDRTRzMTQ2RHNXRXd6?=
 =?utf-8?B?RXhVZnJqK2p0Yjl2QVFwN2ZOTW90SkRZOHZvYm91Tm4xOEpkcTFiL2NIU2Nx?=
 =?utf-8?B?RHdLbms2TmZxOWlub2lNWXBmcE5NK3RiT0pNbE1CN0ZUemxlSmxyYXhMRktC?=
 =?utf-8?B?NVhxWWQvS2gyT05lLzlUeHJvVEFvSWhkcFQrT0xqeGtESjl5WlN3b2V3dWZ5?=
 =?utf-8?B?aGdxaXArYyszeEJ3WUFKU0Q1VFdpK0hYTGVMVk9IZUljeFR6bGNtbGhPVGU0?=
 =?utf-8?B?WGk3OFp2eFE5SjZnaTR4R2dyQWl0Q25teDdORmdzak4zdFdoanFJVC9WOHho?=
 =?utf-8?B?bWhBN0lLaHlWYTdVekpTTzM3Y1dVQzZkYVJ6cFBJU3NTSjJ6SHJIRWszVC9o?=
 =?utf-8?B?UzY0cmk0SXBoWnZ3SlI1bHlrc3dvd21VcjZmTm1sWmRTMjhUTHUzYnhLWjJI?=
 =?utf-8?B?Q2hvTUI1dGtGWFg0Q3BqV0taNGRSV2JJcEpFditDWllvbzRiS2dXK2IrV2Zv?=
 =?utf-8?B?QmJDSXhLQzZ6ckpGeG5qYzB6ZVBwQTR4dHRCczZla2toMkxNK3FEaHpIcWxR?=
 =?utf-8?B?OFZBVzBiK0c2endkUC91Zk1xQUs4SDNmTHdSdi9HdDVGeGFEQ2w5QzF2Q1FK?=
 =?utf-8?B?WktwYXloajQzVW1pL1RtMGpzSmQ4aW4zUXJackVHOVhuODB1SEJianZMbk5t?=
 =?utf-8?Q?uoQJiq3GxojkWau4=3D?=
X-OriginatorOrg: fb.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8918b872-9f68-4401-849f-08da39110170
X-MS-Exchange-CrossTenant-AuthSource: SN6PR1501MB2064.namprd15.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 May 2022 20:57:22.9131
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: BzW8NJewoBYxweIxT4ouufxeHqK/i8TU5RbUuDW8brcxP2Kf43epEL2UevnK+mcz
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR15MB2425
X-Proofpoint-GUID: HFrE5LcfemPgdzHjkAsF8Ss1gfpgJRYR
X-Proofpoint-ORIG-GUID: HFrE5LcfemPgdzHjkAsF8Ss1gfpgJRYR
Content-Transfer-Encoding: 7bit
X-Proofpoint-UnRewURL: 0 URL was un-rewritten
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.205,Aquarius:18.0.874,Hydra:6.0.486,FMLib:17.11.64.514
 definitions=2022-05-18_06,2022-05-17_02,2022-02-23_01
X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
	DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,NICE_REPLY_A,RDNS_NONE,SPF_HELO_NONE,
	T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no
	version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
	lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


On 5/18/22 1:03 PM, Eugene Syromiatnikov wrote:
> On Wed, May 18, 2022 at 09:55:05AM -0700, Yonghong Song wrote:
>>
>>
>> On 5/18/22 5:22 AM, Eugene Syromiatnikov wrote:
>>> Since bpf_kprobe_multi_link_attach doesn't support 32-bit kernels
>>> for whatever reason, having it enabled for compat processes on 64-bit
>>> kernels makes even less sense due to discrepances in the type sizes
>>> that it does not handle.
>>
>> If I understand correctly, the reason is due to
>> in libbpf we have
>> struct bpf_link_create_opts {
>>          size_t sz; /* size of this struct for forward/backward compatibility
>> */
>>          __u32 flags;
>>          union bpf_iter_link_info *iter_info;
>>          __u32 iter_info_len;
>>          __u32 target_btf_id;
>>          union {
>>                  struct {
>>                          __u64 bpf_cookie;
>>                  } perf_event;
>>                  struct {
>>                          __u32 flags;
>>                          __u32 cnt;
>>                          const char **syms;
>>                          const unsigned long *addrs;
>>                          const __u64 *cookies;
>>                  } kprobe_multi;
>>          };
>>          size_t :0;
>> };
>>
>> Note that we have `const unsigned long *addrs;`
>>
>> If we have 32-bit user space application and 64bit kernel,
>> and we will have userspace 32-bit pointers and kernel as
>> 64bit pointers and current kernel doesn't handle 32-bit
>> user pointer properly.
>>
>> Consider this may involve libbpf uapi change, maybe
>> we should change "const unsigned long *addrs;" to
>> "const __u64 *addrs;" considering we haven't freeze
>> libbpf UAPI yet.
>>
>> Otherwise, we stick to current code with this patch,
>> it will make it difficult to support 32-bit app with
>> 64-bit kernel for kprobe_multi in the future due to
>> uapi issues.
>>
>> WDYT?
> 
> As 32 bit arches are "unsupported" currently, the change would be more
> a semantic one rather then practical;  I don't mind having it here (basically,
> the tools/* part of [1]), though (assuming it is still possible to get it
> in 5.18).
> 
> [1] https://lore.kernel.org/lkml/6ef675aeeea442fa8fc168cd1cb4e4e474f65a3f.1652772731.git.esyr@redhat.com/

I think for patch [1], we only need libbpf and selftest change, no
kernel change is needed since we
explicitly does not support 32bit kernel in the
beginning of function bpf_kprobe_multi_link_attach():

         /* no support for 32bit archs yet */
         if (sizeof(u64) != sizeof(void *))
                 return -EOPNOTSUPP;

and in kernel, address (pointer) size will be considered
long (64bit) which is exactly the libbpf change did that.

> 
>>>
>>> Fixes: 0dcac272540613d4 ("bpf: Add multi kprobe link")
>>> Signed-off-by: Eugene Syromiatnikov <esyr@redhat.com>
>>> ---
>>>   kernel/trace/bpf_trace.c | 2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
>>> index 212faa4..2f83489 100644
>>> --- a/kernel/trace/bpf_trace.c
>>> +++ b/kernel/trace/bpf_trace.c
>>> @@ -2412,7 +2412,7 @@ int bpf_kprobe_multi_link_attach(const union bpf_attr *attr, struct bpf_prog *pr
>>>   	int err;
>>>   	/* no support for 32bit archs yet */
>>> -	if (sizeof(u64) != sizeof(void *))
>>> +	if (sizeof(u64) != sizeof(void *) || in_compat_syscall())
>>>   		return -EOPNOTSUPP;
>>>   	if (prog->expected_attach_type != BPF_TRACE_KPROBE_MULTI)
>>
>