Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp3734815pxj; Tue, 15 Jun 2021 07:34:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzQKfrVSbgrODGHwH3oiHcPGDtg3+nG6O6hLh21b8cOgWM3q4jsalWuJJDMyoMCdGSTSevO X-Received: by 2002:a5d:914f:: with SMTP id y15mr18906939ioq.196.1623767691026; Tue, 15 Jun 2021 07:34:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623767691; cv=none; d=google.com; s=arc-20160816; b=B/+82px5md6DM5jpib7VmakrtPCxjvhTuvseWxdnf4nH0X1fQyXdq8cyoXpDfxgnSA Izrm4+296X0ANT65B9p+mEE7nAWPuyF6e1nsrYG0X05vUWA2tiJ4ANtpUXY9CGIz2R4I ZfowBeyAndkWqDDvsyIhvhr+4VE9Za//9hduuHiXsyszCPZBg74QHrPmy3pzbLJ0GzNj 9/e8X0R/u1LakwoHY8dF4X51gRi4EJVwlGxvjPCtnpwsbC9iYpGtvaho9D5GN9E5XNRx 2JntKYDNv9fGDlxAheLRgDyVikRc2qco7SYzNHRlNVUiO6Lk2wg7lXi3mtKOWE+nRxEN YgmA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=EepixlgAvZh6F1sAG1s05x59lrNIaJmC5xzwbwtYruM=; b=q+Sql+UviGeDyc1hrhHAJ/cQCXxltFM4UCg8T2d+ia0GnM2xahrbtB5dO+efhX8un0 87pMV08XtG9M1jiBRmevWCvQlTUufZOaW8BMfBLmemMMvbLCaOLGiUSAa7+dOuKd5R34 RGnnxyaMW1ffQ+LIGdiaZ4cZVN3Llpm1xwW6idfuZ6ANX+kgpUcTxl1olO37ONJCT62+ 6ffGWJbbXcPfCHIt33Rekm65QhiG76yAcp2zi+nZCZ28vpje4PLXocTCTjWJaol/sC32 nJSg5CN9VkLwIn8PjXiHpLWyTuDo6/NLFhMhW3Ucz83uNah5JDakpuyLF2GwWLwzVGij cjDA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e4si10066300ile.128.2021.06.15.07.34.37; Tue, 15 Jun 2021 07:34:51 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231308AbhFOOfw (ORCPT + 99 others); Tue, 15 Jun 2021 10:35:52 -0400 Received: from gate.crashing.org ([63.228.1.57]:54008 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231307AbhFOOfv (ORCPT ); Tue, 15 Jun 2021 10:35:51 -0400 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 15FEUdaR001580; Tue, 15 Jun 2021 09:30:39 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 15FEUc51001579; Tue, 15 Jun 2021 09:30:38 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Tue, 15 Jun 2021 09:30:38 -0500 From: Segher Boessenkool To: Jessica Yu Cc: Nicholas Piggin , Michal =?iso-8859-1?Q?Such=E1nek?= , linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 1/2] module: add elf_check_module_arch for module specific elf arch checks Message-ID: <20210615143038.GH5077@gate.crashing.org> References: <20210611093959.821525-1-npiggin@gmail.com> <20210611093959.821525-2-npiggin@gmail.com> <1623722110.amu32mwaqs.astroid@bobo.none> <20210615125057.GF5077@gate.crashing.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 15, 2021 at 03:41:00PM +0200, Jessica Yu wrote: > +++ Segher Boessenkool [15/06/21 07:50 -0500]: > >On Tue, Jun 15, 2021 at 02:17:40PM +0200, Jessica Yu wrote: > >>+int __weak elf_check_module_arch(Elf_Ehdr *hdr) > >>+{ > >>+ return 1; > >>+} > > > >But is this a good idea? It isn't useful to be able to attempt to load > >a module not compiled for your architecture, and it increases the attack > >surface tremendously. These checks are one of the few things that can > >*not* be weak symbols, imo. > > Hm, could you please elaborate a bit more? This patchset is adding > extra Elf header checks specifically for powerpc, and the module > loader usually provides arch-specific hooks via weak symbols. We are > just providing an new hook here, which should act as a no-op if it > isn't used. > > So if an architecture wants to provide extra header checks, it can do > so by overriding the new weak symbol. Otherwise, the weak function acts as > a noop. We also already have the existing elf_check_arch() check for each > arch and that is *not* a weak symbol. The way I read your patch the default elf_check_module_arch does not call elf_check_arch? Is that clearly called elsewhere and I'm just dumb again? Sorry for the distraction in that case :-/ Segher