From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 78266 invoked by alias); 25 Jul 2019 13:49:20 -0000 Mailing-List: contact libabigail-help@sourceware.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Id: List-Subscribe: Sender: libabigail-owner@sourceware.org Received: (qmail 78256 invoked by uid 89); 25 Jul 2019 13:49:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.100.3 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-6.3 required=5.0 tests=BAYES_00,ENV_AND_HDR_SPF_MATCH,FSL_HELO_FAKE,RCVD_IN_DNSWL_NONE,SPF_PASS,USER_IN_DEF_SPF_WL autolearn=no version=3.3.1 spammy=H*r:210, H*r:2a00, abigail, H*M:google X-Spam-Status: No, score=-6.3 required=5.0 tests=BAYES_00,ENV_AND_HDR_SPF_MATCH,FSL_HELO_FAKE,RCVD_IN_DNSWL_NONE,SPF_PASS,USER_IN_DEF_SPF_WL autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on sourceware.org X-Spam-Level: X-HELO: mail-wm1-f65.google.com Received: from mail-wm1-f65.google.com (HELO mail-wm1-f65.google.com) (209.85.128.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 25 Jul 2019 13:49:18 +0000 Received: by mail-wm1-f65.google.com with SMTP id s3so45065502wms.2 for ; Thu, 25 Jul 2019 06:49:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=dGmlSt0XGwnDSp+9izWyJDuCCdhVxmWeT++Ui8HrW/g=; b=db3JHpadFt/hvRFbq2Iupi7kIEJSQru77czFLJipZRVcGyWR28SLqjBQg2qrOF3vuU ZambDbmeabGx0YdmbxnG7gaJUNRljU51Vd/Gs0sih836NLhdATD+nb+iKQmVJz/Rr0s9 /Q96HB8PuQTvaaNfCVW0m5Wv8AWfkMCQ0fNp7I5cKVnUfrOeBoGEYqfZVM4gSzXHyonY L6jQ2zY2SCInePRMkh86NnzYBQmicQx1lOP5A5DNWkC+T5QybczUS7XPpZ9/aGHhpNHZ 5gAueeNftFrq5/p7yc9lGzQEnAcUh0vhEGTYE3/K2bJfALJYziVsKREVPfjn27ojTwfq KA/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=dGmlSt0XGwnDSp+9izWyJDuCCdhVxmWeT++Ui8HrW/g=; b=n0S69giB+VxPLg7k7uXdMrVOYuhCijjrVzD+Q/6Dhu7/4FT0VK+d9ZimnZ5uAmC0J4 wp9j9rz+ZB1fjmwiNcCw4Y5ctyYX6+L6jgWweOMGDRrwW2IxFI+irj0eEAnjKZMFmZ8B EK7fLfydYl1/q6QD3wwRDrtrWesiGEHe/oF2Ok8rA4lhlNFMWnrlST2TCgUfcUpOhpoe IA+rGesgED07oL57LlSt1Z6lJI+/PgvWUHPXm1bI9W23GihntBySE2kuJDm9g3Sotmcc 5lIUHfSqSBQWRA1U32pEH7PN3TwLzR0BmnOqdv0eOYgrKo4BPG781B8sqoevPHuqX9ux wWMA== X-Gm-Message-State: APjAAAXxSimGb9sBVm3Aw38SVXHyv+VVvdMEETFw+2vqErjDm/32hvoz axCYKYXjwIfgBfDCQNkUMpgS5w== X-Google-Smtp-Source: APXvYqw1zMZb4qUmpnTmIP83BTqDAR329SmoPl67GQt25yb5FylwV4hleD6BlKwNtVge9ATb3sF6Hw== X-Received: by 2002:a1c:2015:: with SMTP id g21mr78473676wmg.33.1564062556267; Thu, 25 Jul 2019 06:49:16 -0700 (PDT) Received: from google.com ([2a00:79e0:d:210:e8f7:125b:61e9:733d]) by smtp.gmail.com with ESMTPSA id s2sm39888419wmj.33.2019.07.25.06.49.15 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Thu, 25 Jul 2019 06:49:15 -0700 (PDT) Date: Tue, 01 Jan 2019 00:00:00 -0000 From: "Matthias Maennich via libabigail" Reply-To: Matthias Maennich To: Mark Wielaard Cc: libabigail@sourceware.org, dodji@seketeli.org, kernel-team@android.com, Alessio Balsini Subject: Re: [PATCH v1] abg-dwarf-reader: detect kernel modules without exports as such Message-ID: <20190725134911.GA197987@google.com> References: <20190724213255.182046-1-maennich@google.com> <20190724215710.GD15558@wildebeest.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190724215710.GD15558@wildebeest.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-SW-Source: 2019-q3/txt/msg00021.txt.bz2 Hi Mark! On Wed, Jul 24, 2019 at 11:57:10PM +0200, Mark Wielaard wrote: > Hi, > > On Wed, Jul 24, 2019 at 10:32:55PM +0100, Matthias Maennich via libabigail wrote: > > Kernel modules without exported symbols (no use of EXPORT_SYMBOL*()), > > will not have a __ksymtab_strings section. Libabigail will therefore > > assume they are usual ELF binaries. That leads to wrong results as > > now all ELF symbols are considered part of the ABI. That is obviously > > wrong. Instead consider binaries having a .modinfo section to be kernel > > binaries. We keep the __ksymtab_strings condition as vmlinux has no > > .modinfo section but a __ksymtab_strings if symbols are exported. > > [...] > > * src/abg-dwarf-reader.cc(is_linux_kernel_binary): consider > > binaries only having a .modinfo section to be kernel binaries > > [...] > > bool > > is_linux_kernel_binary() const > > - {return find_section(elf_handle(), "__ksymtab_strings", SHT_PROGBITS);} > > + { > > + return find_section(elf_handle(), "__ksymtab_strings", SHT_PROGBITS) > > + || find_section(elf_handle(), ".modinfo", SHT_PROGBITS); > > + } > > I think the change itself is correct and better than what is there > now. > > But this is interesting to me because we are discussing an > eu-elfclassify program addition for elfutils. That utility at the > moment classifies a --linux-kernel-module as: > > /* Returns true if the file is a linux kernel module (is ET_REL and > has the two magic sections .modinfo and .gnu.linkonce.this_module). */ > static bool > is_linux_kernel_module (void) > { > return (elf_kind (elf) == ELF_K_ELF > && elf_type == ET_REL > && has_modinfo > && has_gnu_linkonce_this_module); > } > > Just wondering if you believe that check is too strict? > > The reason to check for both "magic" section names was mainly because > ".modinfo" seemed a little too generic. > > One difference is that eu-elfclassify doesn't check the section type. > Maybe it should do that like here, to make sure that it is > SHT_PROGBITS. > To be honest, I am not entirely sure myself. I was told in IRC that the check above is sufficient and should be good for kernels of at least 3.18+ (possibly older kernels as well). I will add a patch on top to restrict abigail a bit more on this. > Sorry for hijacking this patch review for something slightly > different. But I was happy to see something very similar to what I was > working on in a different, but somewhat related project, and was > wondering whether it was the correct way to classify something as a > kernel module. > > Cheers, > > Mark -- Cheers, Matthias