From owner-freebsd-ia64 Mon Jun 17 6:10:11 2002 Delivered-To: freebsd-ia64@hub.freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id CC29D37B40D for ; Mon, 17 Jun 2002 06:10:01 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g5HDA1936460; Mon, 17 Jun 2002 06:10:01 -0700 (PDT) (envelope-from gnats) Received: from iraun2.uka.de (iraun2.uka.de [129.13.10.91]) by hub.freebsd.org (Postfix) with ESMTP id C30B537B40D for ; Mon, 17 Jun 2002 06:01:21 -0700 (PDT) Received: from i30nb20.ira.uka.de ([129.13.30.70]) by iraun2.uka.de with esmtp (Exim 3.30 #7 (Debian)) id 17Jw8G-0002V0-01 for ; Mon, 17 Jun 2002 15:01:20 +0200 Received: from i30nb20.ira.uka.de (localhost [127.0.0.1]) by i30nb20.ira.uka.de (8.12.3/8.12.3) with ESMTP id g5EKWwMK016169 for ; Fri, 14 Jun 2002 22:32:58 +0200 (CEST) (envelope-from esk@i30nb20.ira.uka.de) Received: (from esk@localhost) by i30nb20.ira.uka.de (8.12.3/8.12.3/Submit) id g5EKWwk2016168; Fri, 14 Jun 2002 22:32:58 +0200 (CEST) Message-Id: <200206142032.g5EKWwk2016168@i30nb20.ira.uka.de> Date: Fri, 14 Jun 2002 22:32:58 +0200 (CEST) From: Espen Skoglund Reply-To: esk@ira.uka.de To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.2 Subject: ia64/39415: Bootloader assuming 8KB buffer when only 4KB is allocated Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >Number: 39415 >Category: ia64 >Synopsis: Bootloader assuming 8KB buffer when only 4KB is allocated >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-ia64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Jun 17 06:10:01 PDT 2002 >Closed-Date: >Last-Modified: >Originator: Espen Skoglund >Release: FreeBSD 5.0-CURRENT ia64 >Organization: Karlsruhe University >Environment: >Description: The AllocatePages() call in sys/boot/efi/libefi/elf_freebsd.c only allocate one 4KB page. The bi_load() in sys/boot/efi/libefi/bootinfo.c, however, assumes that 8KB has been allocated when stashing the EFI memory map behind the bootinfo. This could lead to "interesting" behaviour in certain (albeit probably unlikely) scenarios. >How-To-Repeat: >Fix: Make sure that 8KB are allocated instead of only 4KB. --- elf_freebsd.c.orig Fri Jun 14 22:21:42 2002 +++ elf_freebsd.c Fri Jun 14 22:22:13 2002 @@ -151,7 +151,7 @@ hdr = (Elf_Ehdr *)&(md->md_data); status = BS->AllocatePages(AllocateAnyPages, EfiLoaderData, - EFI_SIZE_TO_PAGES(sizeof(struct bootinfo)), (void*)&bi); + 8192/4096, (void*)&bi); if (EFI_ERROR(status)) { printf("unable to create bootinfo block (status=0x%lx)\n", (long)status); >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Tue Jun 18 19:30:22 2002 Delivered-To: freebsd-ia64@freebsd.org Received: from overcee.wemm.org (12-232-114-102.client.attbi.com [12.232.114.102]) by hub.freebsd.org (Postfix) with ESMTP id 8174837B407 for ; Tue, 18 Jun 2002 19:30:20 -0700 (PDT) Received: from wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (Postfix) with ESMTP id 1825A3811 for ; Tue, 18 Jun 2002 19:30:22 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: ia64@freebsd.org Subject: Yay! Date: Tue, 18 Jun 2002 19:30:22 -0700 From: Peter Wemm Message-Id: <20020619023022.1825A3811@overcee.wemm.org> Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Yeehar! I discovered the problem that was breaking dynamic binaries and sometimes static binaries: ia64# mkdir -p /compat/ia32/usr/libexec/ ia64# cp /tmp/ld-elf.so.1 /compat/ia32/usr/libexec/ ia64# mkdir -p /compat/ia32/usr/lib ia64# cp /tmp/libc.so.5 /compat/ia32/usr/lib ia64# file /tmp/id /tmp/id: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), dynamically linked (uses shared libs), stripped ia64# /tmp/id uid=0(root) gid=0(wheel) groups=0(wheel), 2(kmem), 3(sys), 4(tty), 5(operator), 20(staff), 31(guest) Commit coming up... Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Tue Jun 18 21:20:12 2002 Delivered-To: freebsd-ia64@hub.freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id EE38437B40C for ; Tue, 18 Jun 2002 21:20:04 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g5J4K4U83572; Tue, 18 Jun 2002 21:20:04 -0700 (PDT) (envelope-from gnats) Date: Tue, 18 Jun 2002 21:20:04 -0700 (PDT) Message-Id: <200206190420.g5J4K4U83572@freefall.freebsd.org> To: freebsd-ia64@FreeBSD.org Cc: From: Marcel Moolenaar Subject: Re: ia64/39415: Bootloader assuming 8KB buffer when only 4KB is allocated Reply-To: Marcel Moolenaar Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The following reply was made to PR ia64/39415; it has been noted by GNATS. From: Marcel Moolenaar To: Espen Skoglund Cc: FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: ia64/39415: Bootloader assuming 8KB buffer when only 4KB is allocated Date: Tue, 18 Jun 2002 21:10:23 -0700 On Fri, Jun 14, 2002 at 10:32:58PM +0200, Espen Skoglund wrote: > > >Description: > > The AllocatePages() call in sys/boot/efi/libefi/elf_freebsd.c only > allocate one 4KB page. The bi_load() in sys/boot/efi/libefi/bootinfo.c, > however, assumes that 8KB has been allocated when stashing the EFI memory > map behind the bootinfo. This could lead to "interesting" behaviour > in certain (albeit probably unlikely) scenarios. Espen, It looks to me that rounding to a multiple of the EFI page size is more natural for an EFI application. I would probably fix bootinfo.c instead of elf_freebsd.c. A second reason for fixing bootinfo.c is that elf_freebsd.c works with arbitrary large bootinfo blocks, while bootinfo.c only works if the bootinfo block is smaller than 8KB. A second order fix would be to allocate enough; not just for the bootinfo blocks, but also for the memory map... Thoughts? -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Wed Jun 19 12:40:16 2002 Delivered-To: freebsd-ia64@hub.freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id CBB5937B407 for ; Wed, 19 Jun 2002 12:40:02 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g5JJe2G76445; Wed, 19 Jun 2002 12:40:02 -0700 (PDT) (envelope-from gnats) Date: Wed, 19 Jun 2002 12:40:02 -0700 (PDT) Message-Id: <200206191940.g5JJe2G76445@freefall.freebsd.org> To: freebsd-ia64@FreeBSD.org Cc: From: Espen Skoglund Subject: Re: ia64/39415: Bootloader assuming 8KB buffer when only 4KB is allocated Reply-To: Espen Skoglund Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The following reply was made to PR ia64/39415; it has been noted by GNATS. From: Espen Skoglund To: Marcel Moolenaar Cc: Espen Skoglund , FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: ia64/39415: Bootloader assuming 8KB buffer when only 4KB is allocated Date: Wed, 19 Jun 2002 21:29:23 +0200 [Marcel Moolenaar] > It looks to me that rounding to a multiple of the EFI page size is > more natural for an EFI application. I would probably fix bootinfo.c > instead of elf_freebsd.c. A second reason for fixing bootinfo.c is > that elf_freebsd.c works with arbitrary large bootinfo blocks, while > bootinfo.c only works if the bootinfo block is smaller than 8KB. > A second order fix would be to allocate enough; not just for the > bootinfo blocks, but also for the memory map... > Thoughts? You're right. It makes more sense to fix it properly. Here's a better fix. It gets the size of the memmap and uses it for determining the allocation size. The size of the allocated memory behind the bootinfo is then passed on to bootinfo.c (the size of memmap itself is not passed since it may increase due to an AllocatePages() call). eSk ================================================================ --- elf_freebsd.c.orig Wed Jun 19 21:14:43 2002 +++ elf_freebsd.c Wed Jun 19 21:16:04 2002 @@ -143,15 +143,22 @@ struct ia64_pte pte; struct bootinfo *bi; u_int64_t psr; - UINTN mapkey; + UINTN mapkey, size, dummy1; + UINT32 dummy2; EFI_STATUS status; if ((md = file_findmetadata(fp, MODINFOMD_ELFHDR)) == NULL) return(EFTYPE); /* XXX actually EFUCKUP */ hdr = (Elf_Ehdr *)&(md->md_data); + /* Get size of EFI memory map */ + size = 0; + BS->GetMemoryMap(&size, (EFI_MEMORY_DESCRIPTOR *)&dummy1, + &mapkey, &dummy1, &dummy2); + + size = EFI_SIZE_TO_PAGES(sizeof(struct bootinfo) + size); status = BS->AllocatePages(AllocateAnyPages, EfiLoaderData, - EFI_SIZE_TO_PAGES(sizeof(struct bootinfo)), (void*)&bi); + size, (void*)&bi); if (EFI_ERROR(status)) { printf("unable to create bootinfo block (status=0x%lx)\n", (long)status); @@ -159,7 +166,8 @@ } bzero(bi, sizeof(struct bootinfo)); - bi_load(bi, fp, &mapkey); + bi_load(bi, fp, &mapkey, + (size << EFI_PAGE_SHIFT) - sizeof(struct bootinfo)); printf("Entering %s at 0x%lx...\n", fp->f_name, hdr->e_entry); --- bootinfo.c.orig Wed Jun 19 21:14:50 2002 +++ bootinfo.c Wed Jun 19 21:15:46 2002 @@ -242,7 +242,8 @@ * - Module metadata are formatted and placed in kernel space. */ int -bi_load(struct bootinfo *bi, struct preloaded_file *fp, UINTN *mapkey) +bi_load(struct bootinfo *bi, struct preloaded_file *fp, UINTN *mapkey, + UINTN alloced_size) { char *rootdevname; struct efi_devdesc *rootdev; @@ -331,7 +332,7 @@ /* read memory map and stash it after bootinfo */ bi->bi_memmap = (u_int64_t)(bi + 1); - bi->bi_memmap_size = 8192 - sizeof(struct bootinfo); + bi->bi_memmap_size = alloced_size; status = BS->GetMemoryMap(&bi->bi_memmap_size, (EFI_MEMORY_DESCRIPTOR *)bi->bi_memmap, &key, To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message From owner-freebsd-ia64 Fri Jun 21 10: 2:46 2002 Delivered-To: freebsd-ia64@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id B82BE37B442 for ; Fri, 21 Jun 2002 10:00:28 -0700 (PDT) Received: (from fenner@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g5LH0DG12807 for freebsd-ia64@freebsd.org; Fri, 21 Jun 2002 10:00:13 -0700 (PDT) (envelope-from fenner) Date: Fri, 21 Jun 2002 10:00:13 -0700 (PDT) From: Message-Id: <200206211700.g5LH0DG12807@freefall.freebsd.org> To: freebsd-ia64@freebsd.org Subject: FreeBSD ports: 1 unfetchable distfiles: emulators/ski Sender: owner-freebsd-ia64@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Dear freebsd-ia64@freebsd.org, You are listed as the FreeBSD port maintainer for 1 port whose distfiles [or main web pages] are not fetchable from their MASTER_SITES. Could you please visit http://people.freebsd.org/~fenner/portsurvey/freebsd-ia64@freebsd.org.html and correct the problems listed there? The individual port with a problem is emulators/ski. Note that the main port web page, as listed in the WWW: line of the pkg-descr, is checked just as though it was a port distfile. This is an unfortunate side effect of the architecture of the distfile survey reporting tool, but if you see a distfile being reported as not fetchable that's not actually a distfile, see if it's from the pkg-descr. If you have already corrected the problems and submitted a PR, please accept my thanks and apologies for the delay in getting the fixes into the tree. This reminder is created automatically and does not (yet) have a way to know if a PR fixing the problem has been submitted. Please do *NOT* send your response to me directly; I do not always have time to commit your fix; please instead submit a PR via 'send-pr' so it doesn't get lost. Problems are usually of two types: 1. The software package has been upgraded and the version in the port has been removed. The best solution to this problem is to upgrade the port to the most current version of the software package. If you are a FreeBSD committer, then you can just upgrade the port directly. If not, you should create the updated port on your own machine, test it (and maybe even run "portlint" on it), and then use "send-pr" to submit a "diff -uNr old-port updated-port". If you added or deleted any files, please make an explicit note of it. 2. The mirror site being used no longer contains the software package in question, or no longer exists. Solutions include: a) If there are other mirror sites, just remove the bad site from the list. (Make sure that what appears to be a bad site isn't actually a problem of type 1, upgrade) b) If the README or other support files in the software documentation mention where to get the software package, use one of those sites. c) Use ftpsearch (http://ftpsearch.ntnu.no/ftpsearch) or other search engines to find another place to get the original DISTFILES. Make sure that you don't pick a FreeBSD distfiles mirror -- if you can't find any other places where the file exists, it can be a LOCAL_PORT or you can simply comment out the MASTER_SITES= line, with a comment explaining why. Once you have a solution, use "send-pr" to submit a "diff -u" of the Makefile. Note that this isn't an urgent issue, as people who try to build the port now will just fall back to the FreeBSD distfiles mirror. Please just put it on your list to do and get to it when you have time. These messages will continue to arrive twice a month until the fix is committed, as a reminder. Thanks, Bill "distfiles" Fenner. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ia64" in the body of the message