From nobody Fri Aug 12 00:44:07 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 4M3lLF1nm4z4Z5lB for ; Fri, 12 Aug 2022 00:44:21 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x929.google.com (mail-ua1-x929.google.com [IPv6:2607:f8b0:4864:20::929]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M3lLD25Hmz3xGs for ; Fri, 12 Aug 2022 00:44:20 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x929.google.com with SMTP id cd25so5085735uab.8 for ; Thu, 11 Aug 2022 17:44:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=MhsodOfyLYwQbCxivWb7sgAWgsp7rtruMS+mEaZlsSs=; b=d2bbCkRH8QoKv9cTld95tHTQe6ZfpNorslB6UwIPxWQcCqiQ/VPJW8d8CCMJn3zeQs PXsYbtb4Kkn5Tv+81ROdXzQ8MRF6IKWPgrNyzRLmiCMW6IVVisOVETOnZ8L8mqhh6/FL WZBSRm0jVuSF6g2gvbiH0eDOGNEAFIZgaPExhADJKzSjpopQRTH8OxJt6PpZq1sxghOk 4WGfEF1NVsTDBawfmQ00k4gu/wieZsdVW6Vu5ZjsjSq3f+UobqsAJEqx9K4A+AZzxyiu McQBdGautRDl4Gmk+FrT7HozmRJIQsI3YSzC8zwkVpjJk2blYEGsU31rQ3FkuPxC62bS 3Gwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=MhsodOfyLYwQbCxivWb7sgAWgsp7rtruMS+mEaZlsSs=; b=wMDCl+m0Xx4Mhp85r07QHsV4IPz2yWGyfqC0kaVUfwBYEu8kV93f2w+9CUY0D+f/HW cvBdjazuOG3KMEm0KwSXNB1OiS/b/XJHkiwHKYMPusGx80a8SseMntrjUYgmHWaOEdlU wxNFSjpCzs58GiNP1Q9DT7ySYPbWBnGy15VsoC0EHS2zCyTbmN6yCeI+5kjXR3L1iSoA ZYFth3nRlS0hnrC9E3gLc+V2YcM8PKdKLc1nB2SCQ3grNGdNBz5hH6AQr80C7xuF2afk b/tK2M35BjlZmLK5SemQvp/TIWjYWHxtM9wzelQlXcDBBmNmr33q2Txr6GtYw2sPmZ7F dMzQ== X-Gm-Message-State: ACgBeo0+hgOVaZczzt0HG8wN8Bxy+fdIi+PtvbgxCe0QnlllOIB7QmaN M/DCRxBJxyMtV6eVmK7B08BZDRo2OrZ0xpNsGHEv6w== X-Google-Smtp-Source: AA6agR6RZv8WiyIiFXDfE50aezD4g/aCvuDlKnhOMQLJ/Cx1vJTPxP6k856dpIxB6nKF3o5rXpFwGuiiNEu92B8JCWA= X-Received: by 2002:ab0:3bc6:0:b0:381:c4db:ef5 with SMTP id q6-20020ab03bc6000000b00381c4db0ef5mr902798uaw.81.1660265059514; Thu, 11 Aug 2022 17:44:19 -0700 (PDT) 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 References: <202208110331.27B3Va7M007335@gitrepo.freebsd.org> <727af1f3-7432-c038-a776-682ef161f6f9@FreeBSD.org> In-Reply-To: From: Warner Losh Date: Thu, 11 Aug 2022 18:44:07 -0600 Message-ID: Subject: Re: git: 39fdad34e220 - main - stand: impose 510,000 byte limit for /boot/loader and /boot/pxeldr To: John Baldwin Cc: Warner Losh , src-committers , "" , dev-commits-src-main@freebsd.org Content-Type: multipart/alternative; boundary="0000000000001b0ffa05e60095a4" X-Rspamd-Queue-Id: 4M3lLD25Hmz3xGs X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=d2bbCkRH; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::929) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.999]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::929:from]; MLMMJ_DEST(0.00)[dev-commits-src-all@freebsd.org]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; R_SPF_NA(0.00)[no SPF record]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; TO_DN_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; PREVIOUSLY_DELIVERED(0.00)[dev-commits-src-all@freebsd.org]; RCPT_COUNT_FIVE(0.00)[5]; DMARC_NA(0.00)[bsdimp.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --0000000000001b0ffa05e60095a4 Content-Type: text/plain; charset="UTF-8" On Thu, Aug 11, 2022, 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. > > I do think that when people have ran into trouble in the past it has been > in situations that can recurse, e.g. using psuedo-filesystems like gzipfs > where the gzipfs open routine tries to open the underlying "foo.gz" file, > etc. > I ran into problems with a simple system... with lots of disks (10) visible to the BIOS. And that was at 518kB. Just UFS. GZIP and BZIP2 were configured bur not active. Warner -- > John Baldwin > --0000000000001b0ffa05e60095a4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Aug 11, 2022, 6:24 PM John Baldwin <jhb@freebsd.org> wrote:
On 8/11/22 11:18 AM, Warner Losh wrote:
> On Thu, Aug 11, 2022 at 10:56 AM John Baldwin <jhb@freebsd.org>= wrote:
>> You really want to apply the size check to loader.bin, not loader.= =C2=A0 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 f= or cases
>> like
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 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 windo= w (give or
>> take).
>> btxldr isn't stored in low memory, so its size isn't relev= ant, 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 r= ight?
> 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.=C2=A0 Yeah, the total size is 600k.=C2=A0 100k stack do= es seem
like a lot.=C2=A0 It is possible that other BIOS ROMs besides just PXE migh= t
steal data from the stack top.=C2=A0 You could maybe try looking at some of=
your existing BIOS-boot machines to check the 16-bit word at physical
address 0x413.=C2=A0 That gives you the actual top of the 640k window.=C2= =A0 On
my current desktop (albeit booted via UEFI and not BIOS) it is 629k:

% sudo dd if=3D/dev/mem bs=3D1 iseek=3D0x413 count=3D2 | hd
2+0 records in
2+0 records out
2 bytes transferred in 0.000026 secs (75643 bytes/sec)
00000000=C2=A0 75 02=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|u.|
00000002
% gdb
...
(gdb) p/d 0x275
$2 =3D 629

Still, that's only 11k gone.

I do think that when people have ran into trouble in the past it has been in situations that can recurse, e.g. using psuedo-filesystems like gzipfs where the gzipfs open routine tries to open the underlying "foo.gz&quo= t; file,
etc.

I ran into problems with a simple system... with lots of disks (10) vis= ible to the BIOS. And that was at 518kB. Just UFS. GZIP and BZIP2 were conf= igured bur not active.

W= arner

--
John Baldwin
--0000000000001b0ffa05e60095a4--