From nobody Fri Aug 12 01:45:02 2022 X-Original-To: dev-commits-src-main@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 4M3mhW2Wjjz4ZMtc for ; Fri, 12 Aug 2022 01:45:15 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) (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 4M3mhV4l5fz4659 for ; Fri, 12 Aug 2022 01:45:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe31.google.com with SMTP id d126so15726403vsd.13 for ; Thu, 11 Aug 2022 18:45:14 -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=N8O6Ro+tAt8BgtD7+uZGshaCWI28OJcaIPhZKkP+mNQ=; b=apuFGeAmJzg5W5k9g6AW0tTmZTFh4UBz2ufJdFkXo877aZtqAJHXiDjLPA427tPy1q D5eQKJ9BkZnxMnS5YQt3H5ZfPWZVQt8bkrpBGz+zGJB3KybHNYggmb1LvkANm4O+D4Ej Z4MOreExPChCuu9wbprXOpkuzwmc4eThxavh43yBJwGxGXwMOXAeCOecNyL6MAMbBW+k 0Vowg07HZxeg8hvt00xl8rIZPRnW/CXdcQREJ54KDP0xEeszfNlp8GZqKo4cgj/leJdA uHoydjHNT5gIK414B9SVpoXrExNRg70jFkyL3kDlxAhJ4BifPV3dD/IpANRpm+YEKJz3 aTlQ== 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=N8O6Ro+tAt8BgtD7+uZGshaCWI28OJcaIPhZKkP+mNQ=; b=ShAd9fJuipxT/qcS+peAkAd1Eb1DB+xUk4BMVm59/Fz7iR9Z5nStZn1ZxWglUFurf2 TGRswnM7dFH560+0A7TDQB2sdeXRAu3urA+blWo6yNt1nvgUNkxmvRe5uhKRaktQmAV5 iyNUSE7ZdbET6yrLwoE4N4wvZVgIwoJmgz0a5WKqY813HoJJPxZpvteO1rThZQ2Wu/gu VOd0Z+BeGwN5lBXmkhfkg1Ttw4hB41NGJyCoLWkEu3CsxhIskCgiPktXhLLfpnNyA6PB eo2luWjiUGFQueXG+qqXKJmdZBZa+bmZcR/npKVQofNm0CDl7qGdvcrvpan2Jm7IJjjn OKJQ== X-Gm-Message-State: ACgBeo2zR5oRdQhmluJ9z5QgEkfTZV2cp5bL+b6N3Js6xkmJQziIRbqG 4hfU7FUwMrqRViHt2z//h85rb7K3TNFfrkICm4nZBA== X-Google-Smtp-Source: AA6agR7kUJE0doHrIPeDZUF3Tr1qhWYvZ5Kh6P0QsNzf8hw8A1KsfUfPVhB27Qx8jbcohtfYUTc3IMRKjkJ7+OHI/IY= X-Received: by 2002:a05:6102:1494:b0:37e:2dc5:870d with SMTP id d20-20020a056102149400b0037e2dc5870dmr973761vsv.6.1660268713917; Thu, 11 Aug 2022 18:45:13 -0700 (PDT) List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-main@freebsd.org X-BeenThere: dev-commits-src-main@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 19:45:02 -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="000000000000ecd6f805e6016e6b" X-Rspamd-Queue-Id: 4M3mhV4l5fz4659 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=apuFGeAm; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e31) 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::e31:from]; MLMMJ_DEST(0.00)[dev-commits-src-main@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-main@freebsd.org]; RCPT_COUNT_FIVE(0.00)[5]; DMARC_NA(0.00)[bsdimp.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --000000000000ecd6f805e6016e6b Content-Type: text/plain; charset="UTF-8" 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! 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. > Yea, I'm having trouble because I'm missing 73k of stack... Warner > -- > John Baldwin > --000000000000ecd6f805e6016e6b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Aug 11, 2022 at 6:24 PM John = Baldwin <jhb@freebsd.org> wrot= e:
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.

So on = the machine that I'm having issues with...

# d= d if=3D/dev/mem bs=3D1 iseek=3D0x413 count=3D2 | hd
00000000 = =C2=A037 02
# echo=C2=A0 $((0x237))
567

<= /div>
Super Yikes!

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.

Yea, I'm having trouble becaus= e I'm missing 73k of stack...

Warner
=C2=A0
--
John Baldwin
--000000000000ecd6f805e6016e6b--