From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 76CFBC5475B for ; Sat, 9 Mar 2024 01:23:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 909B46B03FF; Fri, 8 Mar 2024 20:23:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8BA1F6B0401; Fri, 8 Mar 2024 20:23:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 782276B0402; Fri, 8 Mar 2024 20:23:47 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 694B96B03FF for ; Fri, 8 Mar 2024 20:23:47 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 388E080616 for ; Sat, 9 Mar 2024 01:23:47 +0000 (UTC) X-FDA: 81875753694.09.8EBEFE9 Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53]) by imf26.hostedemail.com (Postfix) with ESMTP id 872EA140006 for ; Sat, 9 Mar 2024 01:23:44 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=MYmTqfXF; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf26.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.221.53 as permitted sender) smtp.mailfrom=alexei.starovoitov@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709947424; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=zCGj8BlVR14bB1JeMHbRXQzBaaC9CW2Gp3Uo0KDR9B4=; b=ljaTKpt5Ec13IIopfyst8Jki7YtgPTnoKONRoZ9AeDIs7BTx1igin9v3EfYM0rQ0SeFhLB V26pJbLFj1A/NlPiADJsmo4YAegccpCFB5tJIzQcN+GRUQYF9/VGd/ULirupsteN+nRYor v9FdTy8Y1pa23O6CY8+ccVS7yE0pIEg= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=MYmTqfXF; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf26.hostedemail.com: domain of alexei.starovoitov@gmail.com designates 209.85.221.53 as permitted sender) smtp.mailfrom=alexei.starovoitov@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709947424; a=rsa-sha256; cv=none; b=q+Un+VbGisaaOta4BAUbDKGQs3ABFQ7xCHLtJ7jsZJa6Ew0YpLEygzGtB5fupygIC/m3Z9 e+S7hHvlyWyrqJtaCZQvleUWQmWWd4mP948Vh0ZHfG2PaDOWEaRJO9G3+3kIrMBJfSOQes rZPsP+0dgPfc50Ps2ISLu+Qxwzrmn08= Received: by mail-wr1-f53.google.com with SMTP id ffacd0b85a97d-33e695d0614so868731f8f.0 for ; Fri, 08 Mar 2024 17:23:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709947423; x=1710552223; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=zCGj8BlVR14bB1JeMHbRXQzBaaC9CW2Gp3Uo0KDR9B4=; b=MYmTqfXFi7w5wu9gmwn1x3JtdqAVOwJkd+lgNxulpoi/6BOwLzN+/0KEyrBVc1XT+f kEQiCalBwpOLUwRgqPQb44QTltDhC/XYfsO3K9gORYqiDcHUlRcHQzeCsUqGfOuaB24J NL/D+Gf87330S8tZSsPtptiENRGYfFC8zT9fpa0NrpUCS+DIB54FIO53awk5tKU67dpt Jm4vCKbWpX+O1x/Pff6AnUUIN0QAIIjuO+gQn3cfPgoqhUHErcPkcrxSWx1qlea9TejG 2UOb+9i6tOo69HT0j8s99hyPz2J0BwMLjlNGlqGgt9RU3+g1Q+itE5GhkbYHRKg2OV+/ tjDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709947423; x=1710552223; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=zCGj8BlVR14bB1JeMHbRXQzBaaC9CW2Gp3Uo0KDR9B4=; b=WZ+3i6r3wVecSJaJhXiz2vcvpbdq/zCWAgmgmnPh5IV8humwqofJa19IFAX4aKLsEZ cbJBDu+MeK5fMLms27e24yORJDSGfgRkM/mKcRUCxpxmptF4v7076gwiv3Q7gfqHyeb6 DeT/vHbEIisPWIEAbRCCttbRy34Z/dscCzHRQ43OgNEO+/F9PxponD4GvCBiKUa63p3D x3NqAap9dTE7XsM+kILWnqd8ganNGDIpUWGpgGqB9u3AXw49z9KDSwowHSh1bAKFSKuy kXCTW26aiBUEdya9v/RKZh8S5ZDyxlc/xDNKvxasSetPxYjM3NdHzWoqXSxCq89aB4hl ylUA== X-Forwarded-Encrypted: i=1; AJvYcCWs8/wTG7CIqgd3ZRUnKT8k1JvBUyoG6TMNg+Z4WOLFjCU7s6HKnDudpw2FiLwoh5wlPIBJdzIIwcNN1y3S5wyiQH4= X-Gm-Message-State: AOJu0YwkwCMelsYZzjlyC9AFUvV2Te+YNaCXsKkMRWySQV213mbKPzgI TUcfXHguMFH98gPznCuqgmISdqK2LbPs53h1ftLqscOFZ5AoCUdYnJAhToSUanN14jvR80PRLin Whj1roPlufY2BUQdTD1b4m42eEEc= X-Google-Smtp-Source: AGHT+IFD384mKLi9tiE8oMVelWsJF8EntROLIMyoUiTfWkm4n9EX1jPko7YklLovHGv49yMPVN9cCCBfsiYXtyxSNqE= X-Received: by 2002:adf:e392:0:b0:33c:e396:b035 with SMTP id e18-20020adfe392000000b0033ce396b035mr370928wrm.69.1709947422550; Fri, 08 Mar 2024 17:23:42 -0800 (PST) MIME-Version: 1.0 References: <20240306-flach-tragbar-b2b3c531bf0d@brauner> <20240306-sandgrube-flora-a61409c2f10c@brauner> <20240307-phosphor-entnahmen-8ef28b782abf@brauner> <20240308-kleben-eindecken-73c993fb3ebd@brauner> In-Reply-To: <20240308-kleben-eindecken-73c993fb3ebd@brauner> From: Alexei Starovoitov Date: Fri, 8 Mar 2024 17:23:30 -0800 Message-ID: Subject: Re: [PATCH v2 bpf-next 0/9] add new acquire/release BPF kfuncs To: Christian Brauner Cc: Matt Bobrowski , bpf , Alexei Starovoitov , Andrii Nakryiko , KP Singh , Jann Horn , Jiri Olsa , Daniel Borkmann , Linus Torvalds , Linux-Fsdevel , Andrew Morton , linux-mm , LSM List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 872EA140006 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: xkjauoc5ha5mmgew3pntzqya4rc84eyj X-HE-Tag: 1709947424-105830 X-HE-Meta: U2FsdGVkX19PrrCN/O85fIeSXbMcV2WgNl1b48KSJ0J9bUhpzK+I+J7VSKr+19RviUFCqw2UkJGbJdPn62nizuoVCVbbyqGzChD5ApPOqfNV/vLCFOYqVt/nFQVSvT0+6ozgxHV6kttEkhbr3Di1qGAlPFIbS4EC6RqBLBqxoJetZ/uF+2WO6rGtLmTeHsNdZ55R+Fts4FBgKPXyjNMY667S9FbZALhm3yDFOnS3hIxQraP9IUnG8Ad7NbketHN9sTYdehW+7Pl6vZe9OjqnKz4kTZANBWA4MplBZs0zmYldQ/iEoDRxJ/ppmt2yNoqYsvvY4BT8RBP17sHReefkET/6CzthJyFyfWvfKehWs1/zSI6VeRubZDlmQYx6bTQxccy4VpG5+0F55Hs1WmViFH7XiW8/0NMitHnL3BVF7wePMTG/Ee2ZQMFb4yVnGXqQ2VgVEYrNsUhtcm6K0TW+58o3k2aAMDN0FxWnlm3EQ1k0JtUSPZzu8NpXZrkJu8WTEPt/1RIqFs578X0Ew+aGYFdvdxNTLOZWmlVtr4bhOh7k2F72VLBWFUolml+dNgFYx2bIqrZt62tYW/BEmFKQdFu67rJJfHUa55XE64JrQfu9TMrXfbyJ9bxv1iAxY587h2IxjpGhjYm48rFX9xHGcGElsWk8Ub3BB+HkFEQ6thC/2Aii46MzjDSUL//UR8Nti3gAbx+yQVqhVDcVOSWjZiMe2q27/ToGLs0VA/c8U7oSWtN7dz4aUUaX81yx3BcHtAauYGZvcbWMAJLlOgW2O0gCxjANtQShnoKVzUdy/Af+kGslMA1QmtBKHNuUcXrfDeczj/TH8nhzQWRpp6qF2S6Kfwg2l5AmO+EgI7PR3BAxGxNb0Ln+gqAH6vWDMIiLC0Nm0Fi29U3xFH8pB+amq4S2/HCxvsXF78x3l66YZ+NB+lpY7mjqbypkv96FOyn+Z2UcIjRU0R04yctl1Mm kLGXR9UH NEPrliA/6QUgwLduJ37cGF5gypB17Gv/Y54ZD+g+/689JtccyaYa7wEIzXqgSIs2FGIDL X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Fri, Mar 8, 2024 at 2:36=E2=80=AFAM Christian Brauner wrote: > > > These exports are specifically for an out-of-tree BPF LSM program that > is not accessible to the public. The question in the other mail stands. The question was already answered. You just don't like the answer. bpf progs are not equivalent to kernel modules. They have completely different safety and visibility properties. The safety part I already talked about. Sounds like the visibility has to be explained. Kernel modules are opaque binary blobs. bpf programs are fully transparent. The intent is known to the verifier and to anyone with understanding of bpf assembly. Those that cannot read bpf asm can read C source code that is embedded in the bpf program in kernel memory. It's not the same as "llvm-dwarfdump module.ko" on disk. The bpf prog source code is loaded into the kernel at program verification time for debugging and visibility reasons. If there is a verifier bug and bpf manages to crash the kernel vmcore will have relevant lines of program C source code right there. Hence out-of-tree or in-tree bpf makes no practical difference. The program cannot hide its meaning and doesn't hamper debugging. Hence adding EXPORT_SYMBOL =3D=3D Brace for impact! Expect crashes, api misuse and what not. While adding bpf_kfunc is a nop for kernel development. If kfunc is in the way of code refactoring it can be removed (as we demonstrated several times). A kfunc won't cause headaches for the kernel code it is calling (assuming no verifier bugs). If there is a bug it's on us to fix it as we demonstrated in the past. For example: bpf_probe_read_kernel(). It's a wrapper of copy_from_kernel_nofault() and over the years bpf users hit various bugs in copy_from_kernel_nofault(), reported them, and _bpf developers_ fixed them. Though copy_from_kernel_nofault() is as generic as it can get and the same bugs could have been reproduced without bpf we took care of fixing these parts of the kernel. Look at path_put(). It's EXPORT_SYMBOL and any kernel module can easily screw up reference counting, so that sooner or later distro folks will experience debug pains due to out-of-tree drivers. kfunc that calls path_put() won't have such consequences. The verifier will prevent path_put() on a pointer that wasn't acquired by the same bpf program. No support pains. It's a nop for vfs folks. > > First of all, there is no such thing as get_task_fs_pwd/root > > in the kernel. > > Yeah, we'd need specific helpers for a never seen before out-of-tree BPF > LSM. I don't see how that's different from an out-of-tree kernel module. Sorry, but you don't seem to understand what bpf can and cannot do, hence they look similar. > > One can argue that get_mm_exe_file() is not exported, > > but it's nothing but rcu_lock-wrap plus get_file_rcu() > > which is EXPORT_SYMBOL. > > Oh, good spot. That's an accident. get_file_rcu() definitely shouldn't > be exported. So that'll be removed asap. So, just to make a point that "Included in that set are functions that aren't currently even exported to modules" you want to un-export get_file_rcu() ? Because as the patch stands today everything that these kfuncs are calling is EXPORT_SYMBOL.