Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 25 May 2023 11:45:33 -0700
From:   Lucas De Marchi <lucas.demarchi@intel.com>
To:     Linus Torvalds <torvalds@linux-foundation.org>
CC:     Petr Pavlu <petr.pavlu@suse.com>,
        Luis Chamberlain <mcgrof@kernel.org>,
        <gregkh@linuxfoundation.org>, <rafael@kernel.org>,
        <song@kernel.org>, <lucas.de.marchi@gmail.com>,
        <christophe.leroy@csgroup.eu>, <peterz@infradead.org>,
        <rppt@kernel.org>, <dave@stgolabs.net>, <willy@infradead.org>,
        <vbabka@suse.cz>, <mhocko@suse.com>, <dave.hansen@linux.intel.com>,
        <colin.i.king@gmail.com>, <jim.cromie@gmail.com>,
        <catalin.marinas@arm.com>, <jbaron@akamai.com>,
        <rick.p.edgecombe@intel.com>, <yujie.liu@intel.com>,
        <david@redhat.com>, <tglx@linutronix.de>, <hch@lst.de>,
        <patches@lists.linux.dev>, <linux-modules@vger.kernel.org>,
        <linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>,
        <pmladek@suse.com>, <prarit@redhat.com>, <lennart@poettering.net>
Subject: Re: [PATCH 2/2] module: add support to avoid duplicates early on load
Message-ID: <6gwjomw6sxxmlglxfoilelswv4hgygqelomevb4k4wrlrk3gtm@wrakbmwztgeu>
References: <20230524213620.3509138-1-mcgrof@kernel.org>
 <20230524213620.3509138-3-mcgrof@kernel.org>
 <8fc5b26b-d2f6-0c8f-34a1-af085dbef155@suse.com>
 <CAHk-=wiPjcPL_50WRWOi-Fmi9TYO6yp_oj63a_N84FzG-rxGKQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAHk-=wiPjcPL_50WRWOi-Fmi9TYO6yp_oj63a_N84FzG-rxGKQ@mail.gmail.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?T29OLzh5bUc2TTBod3orKzh0NkZPVGYyTVhGTy91QWpnU0l5TVVHV2doWUFr?=
 =?utf-8?B?aVZxSUp0c1pJc0lnTDBnYlpNTXU0dUxDNzJEeDU1K083ZGZlalIyeThKZmIr?=
 =?utf-8?B?aU5zdEV4dlNVMVBlSUFwQ0U4amNkeDh1QmpRVHJUVHkreFlCQlVpME5hSmdq?=
 =?utf-8?B?NFNFK0lReW0rOWh3WFVLZWxVaHhnQlNHRUpXbHJiV1hxWVJzYlFrSTVlem01?=
 =?utf-8?B?bFB6cGI0Y1lWb0VhZTBydzE0cmlBVFdXQy9MVUlaL0dmeXZhaExLT2dkeFVW?=
 =?utf-8?B?bmdOSC9rS09NVTRXc1dFMWt6L1IweXUwQ3pyWk81OGE3L3BlTjB4QUFOMDFG?=
 =?utf-8?B?eWdvb2hZZ01hZVdXSWcxcWhqMmlVT0RsWXpXeUxKMGZudm5aRU1pbThDNi9o?=
 =?utf-8?B?NDhWSTM3NlJnZ2MzVnNWR3JLdW9YVUhneGcwUnIxdUtJVFZFeFRhdUxzYUZ1?=
 =?utf-8?B?UENqOGlZRk1aZlZ4VXVCVnBrSnBuUkNVRnFXZUN1cnFlaG53Ull0Q0w5UXBr?=
 =?utf-8?B?QU5sUXhCYmVKTjdRbkZmUWU3MlJ6czRQQWNnTHFTbFlrMHE0WklPcXEveVpB?=
 =?utf-8?B?UDNRTVNEdGJDRXl3UHA3RFBINForM1BZSEUvdWl3U0ZKNGxkL2pJNHBMMC9P?=
 =?utf-8?B?ejIyVTIzOFBlQmZ2STRxUEh5L3E0cHhmbURUODY0eVZPV1dHSVQxWVZiWTgz?=
 =?utf-8?B?UmNDYkQwTWhiYWVZakM1N1ZGNlQwcWRKbmRBL1VzRFkvV3pUUEd4UklFNEpu?=
 =?utf-8?B?MDlsRS9jOEw0QVB6bUVWdEliRzRYazNHM2FRbEw3VTF5aWtyYTRnb25zQ3k4?=
 =?utf-8?B?WlVnSkY2c082emhHOVlsdGNYcnd2aVNIL3ZDeW5zR1hiWUZtRERKUlVxQi9u?=
 =?utf-8?B?N3k5R25RTmE1R3djTWNoZFNtUytJUVpLYWl5d0cvTVFxK3ZWZE9UeFBleFVz?=
 =?utf-8?B?TUpZb0s5WjREWHNhRUxjNDdCVFBEa1VjQVRpeUNjZWg2Q3YvNHcwUWxFU2RS?=
 =?utf-8?B?dTVSZ0gzL3FZSUlSaDVsenpoUExOOG5TTTRkZW8veTFlc2lmMXpoQ3pmZGlF?=
 =?utf-8?B?QVBMZG1NK3RLT1VKTVFVZ1NDQ3lrL3V4Q0x0WFhCZXIrTmpiWWdXTGNpaFJh?=
 =?utf-8?B?N09obFE4S0wrZGdqdm5keDlGUThLdXg5MGREY0JQVXpJeUVEQ01aTzZKb1Rv?=
 =?utf-8?B?RUhZVTF0bFZTOWhOTjczQ2djY2p5aHZrUHFFN2R1Z3lSNU9DT2Vvbk11UTBY?=
 =?utf-8?B?aGJlYURyUTh0UjY3bkVBclFTR2tsbjFpdDVmY3pjY0hkNitONlAvNUNNZUds?=
 =?utf-8?B?Y3R4YzdMKysrSHo3aG0rOUtoNmd0NUI4KzdlWC9jSWljaUtHUUQwU0s2dmFF?=
 =?utf-8?B?RE1qNFExU29mTytGckUvV2kvT2ExYldrWlRKUFdhRGVPdHNkUUdDQW5Pd0ky?=
 =?utf-8?B?YSt6djFqaXFDZlAvUTk3YWR4UitJdjA1T3lTRnI2ellranUrMStha2RhV29Z?=
 =?utf-8?B?TldGbk5zV2tIZGpQK3dkN2d5SWpsSWZKOXJlQWNrTUFuUk9GNXNiN3Q5L1Fp?=
 =?utf-8?B?ZEVKSkI5UFhvU3J2VFdiVFZ6ME1UMEJ3dG1pY1p3OTY4ekFsQW1SK2c3ZEtz?=
 =?utf-8?B?ZmJjMFF1NjVSbytIMnZTNS81RG1TSXBBbUhaTjJnYkZlbDRjbGd1UGtWSEZo?=
 =?utf-8?B?alNnUTdYT0RhdTd2NkN2ZlN1MENEYTl1akNMUSt2YVlXVWNOOXZ3bElESVRC?=
 =?utf-8?B?OFFlb2xwYlFBVjg3U2JaRE0wOXZkWi8wZTd0S1ovTzY0RHlaZTRWY2FPZHdG?=
 =?utf-8?B?OVNLclVVTmhBejFMMGl1TjBtdW1YamUwTGhDbXpIVmZtVi9PQzgwTHIzc1Iz?=
 =?utf-8?B?ek1XTDh5cm5uWWJjRXhQSUx3ZkhxK3R5U1QwaTJwSkpQNFdjQmpkS2xWU093?=
 =?utf-8?B?a24vdU14VEh5YThzck5zL0tWRUdEdHBKMHBZM3F6UjRVZjl5SVVWNURUVVZx?=
 =?utf-8?B?UDhuOVZiNFgzVldvWVBlMkdGeVFCcUZDMDhrcy84Qm1pVjdUVW9OMHdLeGdO?=
 =?utf-8?B?S25INVFlNDR1K0k3MGd1OHM4TjlScm5iT1N0QkpYZFlNMVZJTWxDdDFicW9E?=
 =?utf-8?B?RC9IZ2JCMXErVzUrTlBJT3hlQVNhT2xvVFNheFROcCtxMkFvMDNLeDVRbHQ4?=
 =?utf-8?B?ZUE9PQ==?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 03113594-9149-4197-f0c3-08db5d503b4a
X-MS-Exchange-CrossTenant-AuthSource: CY5PR11MB6139.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 May 2023 18:45:37.9050
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: ebtrVVQDT6PiTH7r0RDiKo6bZdfdvDgXbrFXIbg/oVI1uY9UJ5D0DalNEYz2GpBQmO9zjWmqeCX7p2jVuWcWiGvAZDzNx3D+p7mpXiTCCA4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR11MB5520
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,
        SPF_NONE,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham
        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 Thu, May 25, 2023 at 09:07:23AM -0700, Linus Torvalds wrote:
>On Thu, May 25, 2023 at 4:40 AM Petr Pavlu <petr.pavlu@suse.com> wrote:
>>
>> kmod normally uses finit_module() only if a module is not compressed,
>> otherwise it decompresses it first and then invokes init_module().
>
>Note that it would probably be good to teach Fedora and SuSE to use
>the kernel-side decompression, if only because we have it and would
>like to try to avoid using the old "load contents from user memory".
>
>Mainly because it allows security modules to actively check for
>tampering (ie things like verity etc). Long-term, it would be good to
>just deprecate the old init_module() entirely.

Right... I was trying to remember why that wasn't done yet since I
thought it was. The in-kernel decompression is much more recent than
the finit_module. Commit b1ae6dc41eaa ("module: add in-kernel support for decompressing")
was actually the one allowing to decompress on the kernel side
and  commit 169a58ad824d ("module/decompress: Support zstd in-kernel decompression")
brought the algo support on the kernel and userspace side to parity.

I will teach kmod to take the proper path considering the in-kernel
decompression availability.

>
>But yes:
>
>> It means that these and similarly organized distributions end up using
>> init_module(), and adding complexity to optimize finit_module() wouldn't
>> actually help in their case.
>
>Yeah, I think the real bug is absolutely in udev, and trying to load
>the same module hundreds of times is very very wrong. So I think the
>"mitigate it in the kernel" is at most a quick hack to fix user-space
>brokenness.
>
>And I don't think 1/2 is acceptable as that "quick hack". Not at all.
>It also seems fundamentally buggy, as it uses purely the inode number
>as the file identity, which means that it does bad things across
>filesystem limits.
>
>That said, I posted an alternate patch that I think _is_ valid as that
>quick hack. I don't love it, but it sure is simpler (and avoids the
>i_ino bug):
>
>    https://lore.kernel.org/lkml/CAHk-=wgKu=tJf1bm_dtme4Hde4zTB=_7EdgR8avsDRK4_jD+uA@mail.gmail.com/
>
>that patch hasn't seen any testing, and for all I know it won't even
>boot because of some thinko, but I think it would be acceptable as a
>workaround if it does work.
>
>But no, it's not some kind of "fix" for the bug, and yes, using
>init_module() rather than finit_module() will circumvent the quick
>hack. The true fix would be for udev to do proper handling of its data
>structures instead of randomly spraying duplicate module loading
>events.
>
>I don't know why udev does what it does. From what Luis told me,
>apparently it's just forking stuff and keeping all its data structures
>in memory, and has no actual consistency or locking or memory of what
>it has done. Luis pointed me at

It's a long time I don't touch that udev code, but my understanding
is that it first creates the kmod context and then starts to fork workers
(up to a limit) as the events arrive and there are no idle workers available.
At this point each of them have a separate kmod context derived from the
initial context. I was told the workers are needed because
a) they must be resilient to crashing without catastrophic consequences and
b) the kernel floods udev with thousands of netlink events during boot.
c) unrelated netlink events can't wait a module to be loaded, for example.

If the above is true (need confirmation from udev devs), then what could
be done on the userspace side would be:

1) do the modalias lookup first, before delegating the module load part
    to the workers. That will translate the modalias to the module name,
2) hand over to the worker the module loading part by name, not by alias,
    iff there isn't one being done for that already by other workers -
    workers need to share some state with the main process.

With this the dedup can happen based on the *module name*. I was told
a dedup based on the aliases is not effective as there are slight
changes on the modaliases being sent on boot leading to the same module.


>    https://lore.kernel.org/all/23bd0ce6-ef78-1cd8-1f21-0e706a00424a@suse.com/T/#u
>
>for some udev background.

the synchronization point in the kernel side rather than on userspace
used to be cheap and the race window smaller.  About the race: libkmod
already checks if there's a module being loaded before actually loading
it, however there is a race between the initstate file being created by
the kernel side and new requests arriving to load the same module.

>
>It's been about a decade since I looked at udev sources, and none of
>this encourages me to take a second look, so all of the above may be
>me misunderstanding just exactly what the udev problem is. But for
>that 'finit' case, we *could* try that simple hack of mine.
>
>I say "hack", but the patch really is pretty simple, and the concept
>of "exclusive special access" certainly is not some hack in itself.
>It's just not anything we've ever done before. So the hackishness from
>that exclusive_deny_write_access() thing in my patch is mainly that it
>shouldn't be needed at all (and that the exclusivity should probably
>be set some other way).
>
>Comments welcome.

Thinking only on the finit_module case and given libkmod will be
changed to prefer that path, it's not clear if it's preferred
to dedup on module name (userspace) or inode (kernel). Also worth
mentioning that both of them only protect against the window of calling
finit_module() and having a initstate file created by the kernel: if the
file exists in the coming or live states, libkmod will already do the
shortcut.

Are you willig to merge (a possibly improved version of) your patch
or the userspace change is still something that
would be desired?  Doing that on the kernel has the small advantage
that it also synchronizes requests from sources other than udev,
but I don't think we would have many to justify.

Lucas De Marchi

>
>                  Linus