Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0300BC433F5 for ; Sun, 12 Dec 2021 19:30:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229596AbhLLTai (ORCPT ); Sun, 12 Dec 2021 14:30:38 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51102 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229477AbhLLTai (ORCPT ); Sun, 12 Dec 2021 14:30:38 -0500 Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E0540C061714 for ; Sun, 12 Dec 2021 11:30:37 -0800 (PST) Received: by mail-pj1-x1034.google.com with SMTP id n15-20020a17090a160f00b001a75089daa3so13173689pja.1 for ; Sun, 12 Dec 2021 11:30:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uHFphg5cxl9eHx+EM+ayhZRLUX15gEzneKCxjSJWVNc=; b=atO3zjkadP5BGnoJZKa+jVrckytkN0sEjwUFaB2f01w6x8zbgy8j/+weAfhlOmPHiL aVj2KSLyZxmrlRWsdtTGxT36hrGdBbvn6Lz5I4JJZKHRMZ/Uhp+TY3dLCSzLNPZ7gGiQ LqoyVVhhH/tWWHazEMp7uzDQ2E2KHzYNxrIMRAC9RGrV3m7J+vyyyHg1knwjGCvgERAa eviLH4PDS7JyN5dPBAoNVznIjDQnj9l7y+aMBFPlrMCgazYHha5EyJxaSyY/4j3UxIX9 +LkgUk85Wcg7OmiqMSLHrQ0aeQ0XKq5IFUhQ948w8m/8lkPvQk2JNDPSuJOczTN+pl85 CprQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uHFphg5cxl9eHx+EM+ayhZRLUX15gEzneKCxjSJWVNc=; b=AUhMOB6emXnTG7qu9poFXO8QMKteYcg6bf2XdpqQyeSNpDzadw5/t09VMAYa4uh9aC YZQxY7Th09mWD9M8H2hWtLxMFfv6qiLBGDzHqLJP1y8KXqKMlfkg+HPMHPfZW/5wrqUv RPL05zE8tGvPCheAbATpzuQFJYalHOSLKS/T55rhnPP5zti9d8H5L8GGczkFA0Z8V2sf JtAKsq+y9q+KNc8JnD2+mJ7+K8gH8U5DmueVE8n6UOTtNdhCYAJCJVhSBG9q18fAZrK4 uEdi1rXbnSm+f1YtoI2NV3xBOg1YIZHh2FSbjGwjyzhn2ef1krzr0vDNBzCx0me7o5Qy WTWg== X-Gm-Message-State: AOAM532uks52t1RpSp3bjULdrNP0PflKQ7rg8yJM9gyzV5QxInFc1BVw B//H05ElqmmY+SXQ5wBHIvbL4RvQOBzymWlxbOw= X-Google-Smtp-Source: ABdhPJxQzS8hVJ0AYMHVxdh0cY0L8hVYy6/U95MBITk75g3JQI7JmApEOGDDpZSsc2jan577YXnozd/CPh1jKmR7Nk0= X-Received: by 2002:a17:902:904b:b0:143:73ff:eb7d with SMTP id w11-20020a170902904b00b0014373ffeb7dmr88504763plz.85.1639337437247; Sun, 12 Dec 2021 11:30:37 -0800 (PST) MIME-Version: 1.0 References: <20211211173447.4155374-1-hjl.tools@gmail.com> In-Reply-To: From: "H.J. Lu" Date: Sun, 12 Dec 2021 11:30:01 -0800 Message-ID: Subject: Re: [PATCH] fs/binfmt_elf.c: disallow zero entry point address To: Linus Torvalds Cc: Alexey Dobriyan , LKML , Andrew Morton Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Dec 12, 2021 at 11:15 AM Linus Torvalds wrote: > > On Sun, Dec 12, 2021 at 11:06 AM H.J. Lu wrote: > > > > According to the ELF specification, zero entry point value means > > there is no entry point. Such ELF binary doesn't conform to the > > ELF specification. > > Nobody cares about paper specifications. > > All that matters is REALITY. > > So let me quote my email again, since you clearly didn't actually read > it (read that "maybe it's not supposed to work" part): > > > That's not my main worry - what if somebody has a code section with a > > zero vaddr and intentionally put the entry at the beginning? > > > > Maybe it's not supposed to work by some paper standatd, but afaik > > currently it _would_ work. > > I'm not sure this can happen currently (maybe all tools effectively > make it so that the ELF headers etc are part of the loaded image). > > But no, paper specifications have absolutely no meaning if they don't > match realty. > > And the reality is that I don't think we've ever checked e_entry being > zero, which means that maybe people have used it. > > So convince me that the above cannot happen. I'm perfectly willing to > be convinced, but "some random paper standard that we've never > followed" is not the thing to quote. > On Linux, the start of the first PT_LOAD segment is the ELF header and the address 0 points to the ELF magic bytes which isn't a valid code sequence. -- H.J.