From nobody Fri Aug 12 17:05:29 2022 X-Original-To: dev-commits-src-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M496L6FlWz4Z6rg; Fri, 12 Aug 2022 17:05:30 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M496L5kKQz3H2V; Fri, 12 Aug 2022 17:05:30 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1660323930; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=cpj7zdkTpYvbfb7Viq9tG3CPqOIdafAfUclC2HJL5Ac=; b=MK/B08epzH2qfCvMTA9YmQnpHLEzYZLPQxyXwpDqwGuH1+aiOuNUXTatZYylxDkJohMqBI sQhqbfYDzHkV11pQyVjH0d8ndjY8sRWToVutSa2JhoXe2yGwqDmIA2M20P5F6bADiLrXlE DrKT0RQwmByVfq8K11pGEVygMLScWKoyfti+BZh2H0fc1pHcmZqaddFoHD0qt2uF/HPvf2 jaJewSUVRKOyjkJsXx7EBx5Cp5pjZJUHwde3q99gRv9Imxbw1OvEav/rRXP42g+4+8ufq8 esoEQpzN+A6lwLREEM71btpbWRovEDrxtjpYzLBWoJHM390K/ROSCRKkt919qg== Received: from [10.0.1.4] (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 4M496L0pYVz1LY0; Fri, 12 Aug 2022 17:05:30 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: Date: Fri, 12 Aug 2022 10:05:29 -0700 List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-all@freebsd.org X-BeenThere: dev-commits-src-all@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: git: 39fdad34e220 - main - stand: impose 510,000 byte limit for /boot/loader and /boot/pxeldr Content-Language: en-US To: Warner Losh Cc: Warner Losh , src-committers , dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org References: <202208110331.27B3Va7M007335@gitrepo.freebsd.org> <727af1f3-7432-c038-a776-682ef161f6f9@FreeBSD.org> From: John Baldwin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1660323930; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=cpj7zdkTpYvbfb7Viq9tG3CPqOIdafAfUclC2HJL5Ac=; b=Q0pMg4xOBxzffYRUW4PALxt9T4O2yT8BrFyUrNdGrFKJrpQZA/pBMAokjE5WozvDS2utLr 9NaCgGKsD2jlzFZ7NEKDh/+kfYoBWxQILivsn/02jEZlWiDrhAwwGJvS7WoLkxiaBUmooo 919bXGDGJVf1ERI+IZ2wc0lTgj1eJxK2mzXn9yRH7FKdxxF1be01vC1b0+2+4IrThZzKEp OZgSl6WdrzVL9mnA4JKY6h0T/0VrcWRoN50W5URCalodGddrF5s6LFDCTfhooUYU7uMbG3 E4s/mdxAzW49vdKFNp+Wx4ydE75JN2SOmbgirZVW3A/8b2X1Mfcxj+SJ4K8Yqg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1660323930; a=rsa-sha256; cv=none; b=Ml6fpHCNMhI0clP/qE/xPiK1NRYFbr7V+hapuf++GoKTbrKabFjC3asf1ECr5oTfZK+o9b 6ps+XzESDuF+lgJn1uFL3wCcfaFjBtGkJh9RtfP378d9pRD1fkCnwNG76lIqo1oF32lJYd DS8dHwc0K97y6HZCezGogwAsvLwOogrTZkScQ6rHsecAAM4dgQJdkjfuYWjuofyj/M7cgM OA+h4HIRY6n86+CmnavNxN5cAYqenHO9vESkExwTmysBkA6KHrvLqg6JwaXjIyftyH2peE 2wSjUIKdbtxsHu3Cu5etRP2gTB2lAgIFxQH7ODj0IUqULs9uDkncnpVexOvWJQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 8/11/22 6:45 PM, Warner Losh wrote: > On Thu, Aug 11, 2022 at 6:24 PM John Baldwin wrote: > >> On 8/11/22 11:18 AM, Warner Losh wrote: >>> On Thu, Aug 11, 2022 at 10:56 AM John Baldwin wrote: >>>> You really want to apply the size check to loader.bin, not loader. The >>>> memory >>>> layout down in the first 1MB for boot loaders is roughly: >>>> >>>> 0x0000: real-mode IDT >>>> 0x0400: BIOS data >>>> 0x7c00: where BIOS loads boot loaders such as /boot/mbr, etc. >>>> 0x1000: various BTX global data like GDT, TSS, IDT, stacks >>>> 0x9000: BTX kernel >>>> 0xa000: BTX client (loader.bin) >>>> 0xa0000: top of BTX client stack (though this can be a bit lower for >> cases >>>> like >>>> PXE booting) >>>> >>>> The real size constraint is on the BTX client (loader.bin) and the fact >>>> that >>>> it's text/data/bss plus stack need to fit into that 576k window (give or >>>> take). >>>> btxldr isn't stored in low memory, so its size isn't relevant, and BTX's >>>> code >>>> always takes up a full page even though it is much smaller. >>>> >>> >>> Where does 576k come from? That's 589824 bytes, but a0000-a000 is 614400 >>> bytes. The delta is 24k (24576). My 'observed' value of about 515,000 is >>> another >>> 75k below that, suggesting we are needing 100k of stack? Can that be >> right? >>> I knew >>> lua ate a lot of stack, but wow! >> >> Hmm, I converted 0xa000 to 64k instead of 40k in my head which is where >> the 576k came from. Yeah, the total size is 600k. 100k stack does seem >> like a lot. It is possible that other BIOS ROMs besides just PXE might >> steal data from the stack top. You could maybe try looking at some of >> your existing BIOS-boot machines to check the 16-bit word at physical >> address 0x413. That gives you the actual top of the 640k window. On >> my current desktop (albeit booted via UEFI and not BIOS) it is 629k: >> >> % sudo dd if=/dev/mem bs=1 iseek=0x413 count=2 | hd >> 2+0 records in >> 2+0 records out >> 2 bytes transferred in 0.000026 secs (75643 bytes/sec) >> 00000000 75 02 |u.| >> 00000002 >> % gdb >> ... >> (gdb) p/d 0x275 >> $2 = 629 >> Still, that's only 11k gone. >> > > So on the machine that I'm having issues with... > > # dd if=/dev/mem bs=1 iseek=0x413 count=2 | hd > 00000000 37 02 > # echo $((0x237)) > 567 > > Super Yikes! Dear goodness what in the world. There must be a 64k bounce buffer or something weird. Maybe for an HBA ROM of some sort? Oof. That would explain why you are seeing issues that we aren't normally seeing from other users though. -- John Baldwin