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, 19 Jan 2023 15:09:36 +0000
From:   Gary Guo <gary@garyguo.net>
To:     Lucas De Marchi <lucas.demarchi@intel.com>
Cc:     Michal =?UTF-8?B?U3VjaMOhbmVr?= <msuchanek@suse.de>,
        Kees Cook <keescook@chromium.org>,
        "Masahiro Yamada" <masahiroy@kernel.org>,
        <linux-kbuild@vger.kernel.org>,
        "Wedson Almeida Filho" <wedsonaf@google.com>,
        Joel Stanley <joel@jms.id.au>,
        Alex Gaynor <alex.gaynor@gmail.com>,
        Miguel Ojeda <ojeda@kernel.org>,
        "Wedson Almeida Filho" <wedsonaf@gmail.com>,
        Nicolas Schier <nicolas@fjasle.eu>,
        <rust-for-linux@vger.kernel.org>,
        Guo Zhengkui <guozhengkui@vivo.com>,
        "Boqun Feng" <boqun.feng@gmail.com>,
        Nicholas Piggin <npiggin@gmail.com>,
        =?UTF-8?B?QmrDtnJu?= Roy Baron <bjorn3_gh@protonmail.com>,
        Nathan Chancellor <nathan@kernel.org>,
        Nick Desaulniers <ndesaulniers@google.com>,
        <linux-kernel@vger.kernel.org>,
        Julia Lawall <Julia.Lawall@inria.fr>,
        "Luis Chamberlain" <mcgrof@kernel.org>,
        <linuxppc-dev@lists.ozlabs.org>, <linux-modules@vger.kernel.org>
Subject: Re: [PATCH] modpost: support arbitrary symbol length in modversion
Message-ID: <20230119150936.30811312.gary@garyguo.net>
In-Reply-To: <20230117192059.z5v5lfc2bzxk4ad2@ldmartin-desk2.lan>
References: <20230111161155.1349375-1-gary@garyguo.net>
        <20230112214059.o4vq474c47edjup6@ldmartin-desk2>
        <20230113181841.4d378a24.gary@garyguo.net>
        <20230117175144.GI16547@kitsune.suse.cz>
        <20230117192059.z5v5lfc2bzxk4ad2@ldmartin-desk2.lan>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?NWo5d1A0Mk1xMkZtWlpXVEU4NnY2dDlZL2pDcEU4Z1BnRTJBVnp6UXdnRWMz?=
 =?utf-8?B?S0IyRllqMzlzQlk5WUNwQmtYUklKQktNYnR0THlIQTh3VWd5Tlp0dmVmZENR?=
 =?utf-8?B?V1dyVG5CL3h6c3JwWFhRbElLeVB4YldNVzAzS3dKd2lESmRZVmZZdUxxMlBs?=
 =?utf-8?B?bURXMU9pSHh6T0dNTmhrTmtkZUxRL2lRNXFhN2k5ck05Q0RCVkRESVZWRTlo?=
 =?utf-8?B?czE2dy95emtBZHd5U0N6T01VS0V2MGZvazhvTUsvc0wycEJxQ0NFM1pFMlJh?=
 =?utf-8?B?cjRwRzNZT0JWM2ZYSnQ4TDhkczRUazNjenhaRUNOWlNYTzdPUEx1cnlQM3Er?=
 =?utf-8?B?bGwwK0hKVU9xcGFvOVFJQkhFNkQ1VWlyOTZHMFBEeU0zY1M4ZUlGbWt4ejBX?=
 =?utf-8?B?bGZGdmZ6REJDd2sveXlaaE9wcnJ2azZtTHozT1R1V2lqVGg1M0x2Y1loTzE1?=
 =?utf-8?B?QmU4dTF3elNtZkNqYWZQeWs4a3FnTVhYaHUyZGd4L1RDdUNQWXpSd0tzVkFL?=
 =?utf-8?B?MkhxdDRKY1E4SThWMytwYkM1UWxiY2VsNmhpR1ErRzJVS25HVUp3Y2lHTkV1?=
 =?utf-8?B?ZXl0SzFHQVlsbGVLdzFhY3FxczVudWhBYUYzSFhnMDRpOS8va0xBM0FTU2k3?=
 =?utf-8?B?OGkrTkhpR3hhYjJ5aEpQT2xUZTZSSmJOU2t6NFVVSUNrWlNwdEZTR0dtL3I5?=
 =?utf-8?B?TUdqZ2xnZ0VCVkZYUzE0YXJaTzJYb0Z0MWRqVGVwTWtzckZYQnBUanN3aXEr?=
 =?utf-8?B?ODkxZE42Mkc4VkJDV2hMNzNXVlVvWm1HaTZuV3ozWXBkK1VlenQ2d2lyME1O?=
 =?utf-8?B?MW0vem5Bc0RxaEVoRHBLOUdmSmY0eElod2MzV1JxWElNaHh1U3h0QytwYkNP?=
 =?utf-8?B?VHdobEZoYzRidjUzQ0Q3NEt5MmdxYmhxYUtFSDZVVk9vNVlYRmFBVFZFa1c0?=
 =?utf-8?B?eFlPY3h6ZEtOVGVkU1VVMnhNVWV6Tmgvb2JFUXVjQnZYZGNIek1ac3JSSjly?=
 =?utf-8?B?NXVEVVl2ZDQ2TE9lRDBMeGhBa3dSR25WM1B6SnBJLzN5dGc0RHppYXcvcWQ2?=
 =?utf-8?B?N2s5R2ZibDlZZ2lUZGczaFoyR2pQaVNpV21ZUnBEbzdOVUx6MU0rQnB6ZU0r?=
 =?utf-8?B?UTN0U2lYdmY1a2poWS9qdVNzSGY4NHkrQWZpMVJ1UkJjRDFKSmlTZEhFNTZz?=
 =?utf-8?B?V2YyK21ybk80ZkRCaFFHZDBWQ0h3MjlBRHFkNCtIbGQ4NzhqcEYvRDZBQ1FB?=
 =?utf-8?B?MjdZZXcvdkZyaUk4QWNvaFVadDVZUTlJaHBuVW9JMVk2T0MzR1V2cHNra1Q0?=
 =?utf-8?B?cDlXUTMvelpzeDlOQitRcFNNNXp5UXUwSTUyY0dPbklMaUhpZGhoM0xWaGhu?=
 =?utf-8?B?REJlZWFRbDgvN2hZRXNZUGpsd2tnZ2JvTzJ1MHVTcUllSm9Ub2NMR3d5SW94?=
 =?utf-8?B?NGN5YnkyemU4aE9JeE0yM1Rld2M1V1JYRmU2WTRwcUhJY2tiMDdDWm80VUUv?=
 =?utf-8?B?SmNDUWpkUk1mOGNqVWtFZEtESW40UWdJd1ZyRGFKTkptM1NrRXV0aWF0dnFE?=
 =?utf-8?B?WkJZSzJTbzdRWnFGSngvbmdmc1hjY2VmWmtJR1JsWm5ETThEU1dFT2cvZEFM?=
 =?utf-8?B?cjR0dWxFdlZmckFibmhXMDJPRm9QbW9uSjBGWTVzbnVuK05XZXI0Vzl6LzRi?=
 =?utf-8?B?RTV4UGp3YTVGbTJFWnY5a2JxYkNVaGFxYnhtaXF0bU9kOXJrREJHb3lkTmlp?=
 =?utf-8?B?eWFGZ2Q4NkRqWWlFM3g4bkpWSWMwR2dVQk1MS1U4aGlTSG1sVERQWlVBUE5s?=
 =?utf-8?B?dnIvUENzRDc4WG5CTWdUamdubEFkSGNsK3lpMExTdDZrWDNjWjRsR2hRQ2or?=
 =?utf-8?B?Y0VxU3Y3UXU1a1JxRjRmNmM3bWZGdVQ2RXZOMS9EV2NyQm5uWFFGcXZOaGFr?=
 =?utf-8?B?TWZkczNlUUF0UWltYVlKWFZIT2ZvaHFwYU9CYjlwelRNNzE4SHgwQzhYVkNo?=
 =?utf-8?B?dG8vKzFDQ3NPcFJucVJndnBDMHc2UFJUNXhYZWVScHp0UURibnBhRFlaQWw5?=
 =?utf-8?B?YS8vaDJuSlNqOC9xOEJYeEdWUkhvZHhqRy9iekJyZ0F1NTBwMjI2R2xZdVZX?=
 =?utf-8?Q?jSGVxlfTYcJ+8PzhVeGFnIhG+?=
X-OriginatorOrg: garyguo.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 64797cba-7dbb-4055-ae9e-08dafa2f2f40
X-MS-Exchange-CrossTenant-AuthSource: LO2P265MB5183.GBRP265.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Jan 2023 15:09:39.1239
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: bbc898ad-b10f-4e10-8552-d9377b823d45
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: IIXzNLvZr7FsHnmF5247Yhn45RpY4VtkAdSpbW/NXgn5t4VgbLE93lGjsIPdYlVlzRP+SRcGgLXsJcBYkKXt/g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO0P265MB6947
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,
        RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS 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 Tue, 17 Jan 2023 11:22:45 -0800
Lucas De Marchi <lucas.demarchi@intel.com> wrote:

> On Tue, Jan 17, 2023 at 06:51:44PM +0100, Michal Such=C3=A1nek wrote:
> >Hello,
> >
> >On Fri, Jan 13, 2023 at 06:18:41PM +0000, Gary Guo wrote: =20
> >> On Thu, 12 Jan 2023 14:40:59 -0700
> >> Lucas De Marchi <lucas.demarchi@intel.com> wrote:
> >> =20
> >> > On Wed, Jan 11, 2023 at 04:11:51PM +0000, Gary Guo wrote: =20
> >> > >
> >> > > struct modversion_info {
> >> > >-	unsigned long crc;
> >> > >-	char name[MODULE_NAME_LEN];
> >> > >+	/* Offset of the next modversion entry in relation to this one. *=
/
> >> > >+	u32 next;
> >> > >+	u32 crc;
> >> > >+	char name[0]; =20
> >> >
> >> > although not really exported as uapi, this will break userspace as t=
his is
> >> > used in the  elf file generated for the modules. I think
> >> > this change must be made in a backward compatible way and kmod updat=
ed
> >> > to deal with the variable name length:
> >> >
> >> > kmod $ git grep "\[64"
> >> > libkmod/libkmod-elf.c:  char name[64 - sizeof(uint32_t)];
> >> > libkmod/libkmod-elf.c:  char name[64 - sizeof(uint64_t)];
> >> >
> >> > in kmod we have both 32 and 64 because a 64-bit kmod can read both 3=
2
> >> > and 64 bit module, and vice versa.
> >> > =20
> >>
> >> Hi Lucas,
> >>
> >> Thanks for the information.
> >>
> >> The change can't be "truly" backward compatible, in a sense that
> >> regardless of the new format we choose, kmod would not be able to deco=
de
> >> symbols longer than "64 - sizeof(long)" bytes. So the list it retrieve=
s
> >> is going to be incomplete, isn't it?
> >>
> >> What kind of backward compatibility should be expected? It could be:
> >> * short symbols can still be found by old versions of kmod, but not
> >>   long symbols; =20
> >
> >That sounds good. Not everyone is using rust, and with this option
> >people who do will need to upgrade tooling, and people who don't care
> >don't need to do anything. =20
>=20
> that could be it indeed. My main worry here is:
>=20
> "After the support is added in kmod, kmod needs to be able to output the
> correct information regardless if the module is from before/after the
> change in the kernel and also without relying on kernel version."
> Just changing the struct modversion_info doesn't make that possible.
>=20
> Maybe adding the long symbols in another section?

Yeah, that's what I imagined how it could be implemented when I said
"short symbols can still be found by old versions of kmod, but not long
symbols".

> Or ble just increase to 512 and add the size to a
> "__versions_hdr" section. If we then output a max size per module,
> this would offset a little bit the additional size gained for the
> modules using rust.

That format isn't really elegant IMO. And symbol length can vary a lot,
having all symbols dictated by the longest symbol doesn't sound a good
approach.

> And the additional 0's should compress well
> so I'm not sure the additional size is that much relevant here.

I am not sure why compression is mentioned here. I don't think section
in .ko files are compressed.

(sorry forget to reply-all, re-send email to the list)

Best,
Gary