From nobody Thu Aug 11 16:56:30 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 4M3XyS0c6gz4Z1K3; Thu, 11 Aug 2022 16:56:32 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 4M3XyS07hdz42S5; Thu, 11 Aug 2022 16:56:32 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1660236992; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=sn1wf9lPWrA1BJF1zakTAYFnoAe1H7u/1xT585GhDPk=; b=QES/kM1KZ97CBUKhz0Vj74RzirjEs/rT5QQXtYhJUuQpfPPcYK8eO91tA1+a0gs7j21JJi 1AB1jaxhOV3EaMJEGeTZBLfExAFHzZJgV3wxSZA/2UvfeD9L5n3vm7+7KES+rxoPRAFWOH Sz4DKyg/s/wSBoR0f/CeX4B2mR3a0sRPDqUqFNp24ywqo7uFOPM51kClAayJzz2chAXflb bX95ow4CA7xDp1+4GTyG1o88CRlWr98YZWeFkQUaWtaQhxW1fxQ3pXRK0kX1V71doTb+BL ReLfgagZgM76Dwd9pV/Uk6r0r/v0d+9Kjj74zYUcbWNtAMJnTzEcpJa55rRs/A== 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 4M3XyR2flJzxhD; Thu, 11 Aug 2022 16:56:31 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <727af1f3-7432-c038-a776-682ef161f6f9@FreeBSD.org> Date: Thu, 11 Aug 2022 09:56:30 -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 Content-Language: en-US To: Warner Losh , src-committers@FreeBSD.org, dev-commits-src-all@FreeBSD.org, dev-commits-src-main@FreeBSD.org References: <202208110331.27B3Va7M007335@gitrepo.freebsd.org> From: John Baldwin Subject: Re: git: 39fdad34e220 - main - stand: impose 510,000 byte limit for /boot/loader and /boot/pxeldr In-Reply-To: <202208110331.27B3Va7M007335@gitrepo.freebsd.org> 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=1660236992; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=sn1wf9lPWrA1BJF1zakTAYFnoAe1H7u/1xT585GhDPk=; b=mMU6/g171YAeuGpt0o/CG0IPr6A7rQQc7gxYOIqB589iopDqyzGZD1xFEAVAJIgPEm/9wo zIhTxPHPvH2hjJLMu/Q/MHXIeqI3SdUjnyBzE8GMNYM3FDabq6YSANvusLleIBFuSC0nGX asws7bVnZP/MN+W3b7P8r4C9aArheYghHqjcu71KFMSAF0MW7S9kxPcH9eUZIYAjHXZ6xp +nLTR+lj4xDZ3vW0I0NIfNQOgB4ZpMP18Es8sBP2zuCqSVjEjJsmB7L8jRNjiqPP58oKB3 YJBs2Qm7RTyER5jYdt9BOlZTMUIq+Bc/LtPGPFBC5h3owzmlX4qphvFIVj89Jg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1660236992; a=rsa-sha256; cv=none; b=p+cny/ebjFIp4DAmjLDG5IMHNh8/c2HhamcCBTVn9A8iMliYH9SQi9yEYM+4aGpIotTgj0 QBhl3cSYl90YP/aBYMRYwclUoYIxRjG7GJPlXpstTsVV1OFJ+alvmyj1qtCkCKsbvpdr/m BnyluLEmSwTlYiMtiLvcxsXOowN1aQarX9pehJQ4PBO9Q57cOhlcL/GIRDelv16ycdC8bQ 8Y+7FTH/3xTUgyl912nt+mh/Lz9wIzRbCWqQkKPYGE4sMu2+YYdbwXgcZzYlkbFcPQqVRo ZrtzuGkBxg6p5IATUkRUjuiynjDGQ0sL6BT2vktl6WuBs9XcP0khQcgEhmxrfw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 8/10/22 8:31 PM, Warner Losh wrote: > The branch main has been updated by imp: > > URL: https://cgit.FreeBSD.org/src/commit/?id=39fdad34e220c52a433e78f20c8c39412429014e > > commit 39fdad34e220c52a433e78f20c8c39412429014e > Author: Warner Losh > AuthorDate: 2022-08-11 03:19:01 +0000 > Commit: Warner Losh > CommitDate: 2022-08-11 03:29:20 +0000 > > stand: impose 510,000 byte limit for /boot/loader and /boot/pxeldr > > The BIOS method of booting imposes an absolute limit of 640k for the > size of the program being run due to btx. In practice, this means that > programs larger than about 500kiB will fail in odd ways as the stack / > heap will overflow. Technically the heap is now always above 1MB, the issue is the stack growing down and overwriting .bss. > Pick 510,000 as the cutoff line semi-arbitrarily. loader_lua is now > almost too big and we want to break the build when it crosses this > threshold. In my experience, below 500,000 always works, above 520,000 > always seems to fail with things getting bad somewhere between 512,000 > to 515,000. 510,000 is as close to the line as I think we can go, though > experience may dictate we need to lower this in the future. > > This is at-best a stop-breakage until we have a better way to subset the > boot loader for BIOS booting to allow better, more fined-tuned > /boot/loaders for the many different environments they have to run > in. This likely means we'll have a graphical loader than understands a > few filesystmes for installation, and a non-graphical loader that > understands the most filesystems possible for everything else in the > future. Our build infrastructure needs some work before we can do that, > however. > > At this late date, it likely isn't worth the efforts to move parts of > the loader into high memory. There's a number of assumptions about where > the stack is, where buffers reside, etc that are fulfilled when it lives > in the first 640k that would need bounce buffers and/or other counter > measures if we were to split it up. All BIOS calls are done in 16-bit > mode with SEG:OFF addresses, requiring them to be in the first 640k of > RAM. And nearly all machines in the last decade can boot with UEFI > (though there's some exceptions, so it isn't worth killing outright > yet). Fully agree that we just want to keep the BIOS loader on a sufficient feature diet. > Sponsored by: Netflix > Reviewed by: kevans > Differential Revision: https://reviews.freebsd.org/D36129 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. In theory pxeboot's total size needs to fit into the window at 0x7c00 - 0xa0000, but in practice that limit is much larger since the size of pxeldr plus the BTX kernel is much smaller than 0xa000 - 0x7c00. I would say that you might want the PXE size to be even lower (maybe 4k or so?) than the "plain" disk loader as PXE ROMs grab some of the memory ending at 0xa0000 to use for data buffers. I don't have a firm number I can recall of how much they grab hence my guess of about 4k or so. -- John Baldwin