From patchwork Sun Mar 19 21:35:37 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Luis Chamberlain X-Patchwork-Id: 6864 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:604a:0:0:0:0:0 with SMTP id j10csp883471wrt; Sun, 19 Mar 2023 14:38:17 -0700 (PDT) X-Google-Smtp-Source: AK7set98yuLm21ws/20knDh4diU90kQFvzUITrxCLj1ToLuAIohw6MMLNiE2N/iOKEH56V7sss8v X-Received: by 2002:a17:90a:1991:b0:237:40a5:7cb9 with SMTP id 17-20020a17090a199100b0023740a57cb9mr16123957pji.5.1679261897589; Sun, 19 Mar 2023 14:38:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1679261897; cv=none; d=google.com; s=arc-20160816; b=qipCQm4ThDNLSxAg5Gdt2A1mIYnH+UY/pGaRbARcEdjoAj/qOyCq3dDBvdAB58DX6j egLNTyOQbR4Rx9NdCfWZtNjqNyH6P+bnvwW1f/wUiNnZmInAmPwWBV6YdkWlh5iEmpxb 2Dof9ZeH2zZbB6CD8eVVO+Jzlu1BSxwHskrape1pBYWbxGG9s9CD1Dk1MRWJcsytP0rn I8W5YJZfFYveOWFZX8uO5zw/bYydT2CNdI0fXeO0dDMAnKMdLXap2dLigEqEtl0M0osp lFFiATxMFwi5+xmcliIJ8hPCW7IsB3eVnR43ZVy7dbvam/hSRfKvbzz8Tfp6eZrWBmlu 9ANA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=4+NzyS15tvE5FVGnxGqo+lPc7QVVkfAfgOyCb7VB/XM=; b=KOirqGxcxk1sb35DQrM0oDtlQYGkIWEvmp0B2nf75nhv+B5mi7MQMvMskMyGuoH8WF DnYo8KrAGHbpKrhfqbO5TT4oB5hqvnPamEFFhwzO7CL5bZbGGxQ7RgB8XrgXnMpWf4OR jcoboDGlxhNaJKZTyGDTjXliMV1AP+gFjPHwIZ8FnHD4ZytmkOB8lSkUztD7vLPV82hW KKigtoWH3JXqMNq+S0F6JVnLt3BijGmhhgsOl7SfYyc6cjfGiFWHB88Hpc9+KDveSsj9 aEkYqdoIuSm8fKuS520saJkpx95BoVQogbCtdohqD7FmeaxI4LRO8fBfRoBUEnTbq9N+ xdsw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=bombadil.20210309 header.b=2fCknlgW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id z8-20020a17090abd8800b0023676bd55d1si13772962pjr.94.2023.03.19.14.38.04; Sun, 19 Mar 2023 14:38:17 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@infradead.org header.s=bombadil.20210309 header.b=2fCknlgW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230266AbjCSVfz (ORCPT + 99 others); Sun, 19 Mar 2023 17:35:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55470 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229835AbjCSVfq (ORCPT ); Sun, 19 Mar 2023 17:35:46 -0400 Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:3::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0D3FD11653; Sun, 19 Mar 2023 14:35:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Sender:Content-Transfer-Encoding: MIME-Version:Message-Id:Date:Subject:Cc:To:From:Reply-To:Content-Type: Content-ID:Content-Description:In-Reply-To:References; bh=4+NzyS15tvE5FVGnxGqo+lPc7QVVkfAfgOyCb7VB/XM=; b=2fCknlgWTdi0+x9lnrIeEbLIVF 55fk6OZVI/R/W4zkljEDBoMJYWXrtaJ3bomUUBCust/KBP/LbuyJcwRnpNwLj0fQwv3ctcAgiL7ir 7mqnmJkl2YYlTf7C/WvinuYJjuwQGhiGkj7+xfoIwfwhouTy4Vo8s07Ov7Ld+b82o4+peoc7s6kSF eVlDDuVqWNfzedPSw1AdAom95xddzlX/HSzVVsDfjrgjASpA8GPd59FXRWzIGaMkVqkxYi9FR+GwN JhuiVJdpgVggFx07x3Hwl1lkviNdIpBJRQs/r2zbxlaEy/53Iw5ybzma1Vl20ybB8e58/rbIEJtX1 KA0KCVnw==; Received: from mcgrof by bombadil.infradead.org with local (Exim 4.96 #2 (Red Hat Linux)) id 1pe0gp-007Vmp-1H; Sun, 19 Mar 2023 21:35:43 +0000 From: Luis Chamberlain To: linux-modules@vger.kernel.org, linux-kernel@vger.kernel.org, pmladek@suse.com, david@redhat.com, petr.pavlu@suse.com, prarit@redhat.com Cc: christophe.leroy@csgroup.eu, song@kernel.org, mcgrof@kernel.org Subject: [PATCH 0/5] module: ELF validation enhancement and cleanups Date: Sun, 19 Mar 2023 14:35:37 -0700 Message-Id: <20230319213542.1790479-1-mcgrof@kernel.org> X-Mailer: git-send-email 2.38.1 MIME-Version: 1.0 Sender: Luis Chamberlain X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_NONE 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: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1760833723579118710?= X-GMAIL-MSGID: =?utf-8?q?1760833723579118710?= While doing a cleanup of load_module() to do less work before we allocate [0], one of the undocumented tricks we pull off is memcpy'ing the struct module from the module.mod.c into the kernel, with the modifications we've made to it on load_module(). This puts a bit of love to make the clearer, and extends our ELF validity checker to ensure we verify this before allowing us to even process a module. This effort has discovered a new possible build issue we have to fix: It is in theory possible today to modify the module struct module size, let a kernel developer lazily just build the module (say make fs/xfs/) and then try to insert that module without ensuring the module size expected should have grown. You can verify the size with: nm --print-size --size-sort fs/xfs/xfs.ko | grep __this_module 0000000000000000 0000000000000500 D __this_module The struct module size will be different per each kernel configuration, and so this is system build dependent. The new ELF check put in place prevents this situation and also make the use case of memcpying the struct module very clear, along with ensuring we keep all modifications we've made to it. [0] https://lkml.kernel.org/r/20230311051712.4095040-1-mcgrof@kernel.org Luis Chamberlain (5): module: add sanity check for ELF module section module: add stop-grap sanity check on module memcpy() module: move more elf validity checks to elf_validity_check() module: merge remnants of setup_load_info() to elf validation module: fold usermode helper kmod into modules directory MAINTAINERS | 13 +-- kernel/Makefile | 1 - kernel/module/Makefile | 4 +- kernel/{ => module}/kmod.c | 0 kernel/module/main.c | 219 ++++++++++++++++++++++++------------- 5 files changed, 148 insertions(+), 89 deletions(-) rename kernel/{ => module}/kmod.c (100%)