From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, FROM_LOCAL_NOVOWEL,HEADER_FROM_DIFFERENT_DOMAINS,HK_RANDOM_FROM, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 19DBB216D6 for ; Wed, 20 Mar 2024 16:55:21 +0100 (CET) Received: (qmail 15553 invoked by uid 550); 20 Mar 2024 15:50:48 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 15521 invoked from network); 20 Mar 2024 15:50:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1710950107; x=1711554907; darn=lists.openwall.com; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=QPc/l2eGp9sOda3ZgLj/kZG0cJIUTlA0rflW27X5tw4=; b=WguuaCabUBciVwomebUDj3HPIxXvuRilVauJ1xSIETwad23V64riIZwfoABYnDEAzt WZ54lG2ZpiXD054+4OaFeWEuCoPYCAUlx+DMzm8R6a4W7vxZrH6pukzbDvYyrQrOzpDi 9t2bz6fGZl1FkInQr/RTHFijRzPW8pSlK3nOodoFGUSrQYVlgPsOgN7qwV5C+K0NO7DM AfYEIZqQ6CTrssUphZF7mj69mIdVi1HwcJLIta5GK7L+EMz9A7Y+0gAdEEiA7mNmLDCR OEZl+B9x4wgFHYYggv5kX/TROh9YJhbB1P7IaJa6E7Z0TrE+DJag0gQy5dr9BgFNuBvZ PKmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710950107; x=1711554907; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=QPc/l2eGp9sOda3ZgLj/kZG0cJIUTlA0rflW27X5tw4=; b=C9w6LiYvI5p201s9hU/LsKGYcRKQw0AYwENl0BXuPcSZ7N+QbgOiMwHpiPHL8oDGgS SqgjTTUHYu3qeuHjDPdEodDEa6bHhTfjVoCrDaqmG9kewhnaj/eTx9ubylIid+LtLB7y X/vQp2OdWlpPbOy/xXoQ/pvesl3RGD6EUsjdeEyjM8da6VVB5NYL6qKK2jeilsY3vm2u mVil9VSHoN+1TwmUi/qAMdJHnjXX0PWYJ8xIrJleJCbIwp3LqAFS1ExgI+e+jeFs03w8 Sl5ziTFa54LQuTSwLvOIYAi7DjsKGyLtb3Rgtf0p3UtOh0ty+ljomz2X2vU4Wpy59Kyz Arhw== X-Gm-Message-State: AOJu0YwFhah12VgEKMNoTAAtZdHdLP1mfqjhVvQJkQcAz2tlDKvf/c1r OPI/A3g+iHDJD2bIUC7MeTEHsm39pegKGhwTZ1OjWalf7lkOukGYwCWc2LknxhTwZ3Ppb4gpiWB w4KPaCobyLNSSlrzDWf99B6zl2IM= X-Google-Smtp-Source: AGHT+IHY8mYyQg4oAwEwYAlzgh6c86yne7ATkl5Q0PI9zMXPlCl8CxFlvcdNCtVG7dYXPGgXQCvV2K1ryIk3cmL768I= X-Received: by 2002:a17:90b:4b4d:b0:29e:7f4:868f with SMTP id mi13-20020a17090b4b4d00b0029e07f4868fmr12052815pjb.18.1710950107305; Wed, 20 Mar 2024 08:55:07 -0700 (PDT) MIME-Version: 1.0 From: Max Filippov Date: Wed, 20 Mar 2024 08:54:56 -0700 Message-ID: To: Rich Felker Cc: musl@lists.openwall.com Content-Type: text/plain; charset="UTF-8" Subject: [musl] AT_EXECFN aux entry passed by the linux kernel is broken in NOMMU Hi Rich, I began testing xtensa FDPIC musl port in full system emulation and found that /sbin/init crashes inside __dls3() on the following line: if ((aux[0] & (1UL<p on its initialization in the __bprm_mm_init() here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/exec.c?h=v6.8#n352 moved backwards by the copy_string_kernel() call here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/exec.c?h=v6.8#n1958 copied to bprm->exec and then written to the aux vector unchanged here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/binfmt_elf_fdpic.c?h=v6.8#n661 I understand that in NOMMU kernel the bprm->p is the offset inside the temporary program arguments array maintained in separate pages in the linux_binprm::page and it needs translation to the actual address when that array is finally copied to the user stack. It seems that both the kernel code that creates aux[AT_EXECFN] and the musl code that examines it predate the SH FDPIC port, so somehow it worked for SH, I guess because on SH accessing the addresses below 0x20000 didn't cause a crash? Disabling the above reference to aux[AT_EXECFN] fixes the boot on xtensa NOMMU kernel for me. -- Thanks. -- Max