From nobody Fri Aug 12 01:45:02 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 4M3mhW49Qsz4ZMjf
for <dev-commits-src-all@mlmmj.nyi.freebsd.org>; Fri, 12 Aug 2022 01:45:15 +0000 (UTC)
(envelope-from wlosh@bsdimp.com)
Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b])
(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 4M3mhV5K28z462g
for <dev-commits-src-all@freebsd.org>; Fri, 12 Aug 2022 01:45:14 +0000 (UTC)
(envelope-from wlosh@bsdimp.com)
Received: by mail-vs1-xe2b.google.com with SMTP id 66so20023791vse.4
for <dev-commits-src-all@freebsd.org>; 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=pAaLjM8+mRFFTYFuMnE+0PcyInBdUlpXiDa0q3o9neETSaWNrrkFrnTXHgikPwT5eW
yQjEx6ubZ96lv+YLgCMPREmH5O364AKzuiOyD5DgU+nfTGqKjGN7GjWMFia00Y46WBv6
12/VW6YIjft1nrnOVlLcDFBYalAAmbfVEUnDjgsAyer4mdvlYkZ6D/heyTrxoUHAwauV
UEyidHS2DMJ3LVQyf6rqfbyniUqW+3EgGDtcdabHdXs9Pxcom8txrvRMlrRl7QaZdsa+
olvbARmqJhJ27E1kBgnsvVY80apDpO6Rdz7jABzOYnPALd/UCfScPfRnIetGMuXg3Ax1
c+dQ==
X-Gm-Message-State: ACgBeo3q795cqwWT1R2NC88xY/g+hBsuszDhflEQF8u7iV+KbPg1aap/
d2nHkWnnrXCu0QhUR6kaWS1qdOL+mZvXJU8J1cf9Hg==
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 all branches of the src repository <dev-commits-src-all.freebsd.org>
List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all
List-Help: <mailto:dev-commits-src-all+help@freebsd.org>
List-Post: <mailto:dev-commits-src-all@freebsd.org>
List-Subscribe: <mailto:dev-commits-src-all+subscribe@freebsd.org>
List-Unsubscribe: <mailto:dev-commits-src-all+unsubscribe@freebsd.org>
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> <CANCZdfo-CyHD0jj==14Cimy9g77MqEBjZV1ho=TC7qgoDz6eCg@mail.gmail.com>
<ad8467cd-bbc7-37cf-b085-72bf34256431@FreeBSD.org>
In-Reply-To: <ad8467cd-bbc7-37cf-b085-72bf34256431@FreeBSD.org>
From: Warner Losh <imp@bsdimp.com>
Date: Thu, 11 Aug 2022 19:45:02 -0600
Message-ID: <CANCZdfrVB7C=6PMcVxmEtDo92pNNZjbkrNSiTyTTJWFpW1n1nw@mail.gmail.com>
Subject: Re: git: 39fdad34e220 - main - stand: impose 510,000 byte limit for
/boot/loader and /boot/pxeldr
To: John Baldwin <jhb@freebsd.org>
Cc: Warner Losh <imp@freebsd.org>, src-committers <src-committers@freebsd.org>,
"<dev-commits-src-all@freebsd.org>" <dev-commits-src-all@freebsd.org>, dev-commits-src-main@freebsd.org
Content-Type: multipart/alternative; boundary="000000000000ecd6f805e6016e6b"
X-Rspamd-Queue-Id: 4M3mhV5K28z462g
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::e2b) 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::e2b: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
--000000000000ecd6f805e6016e6b
Content-Type: text/plain; charset="UTF-8"
On Thu, Aug 11, 2022 at 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. 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
<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Thu, Aug 11, 2022 at 6:24 PM John =
Baldwin <<a href=3D"mailto:jhb@freebsd.org">jhb@freebsd.org</a>> wrot=
e:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 8/11/22 11=
:18 AM, Warner Losh wrote:<br>
> On Thu, Aug 11, 2022 at 10:56 AM John Baldwin <<a href=3D"mailto:jh=
b@freebsd.org" target=3D"_blank">jhb@freebsd.org</a>> wrote:<br>
>> You really want to apply the size check to loader.bin, not loader.=
=C2=A0 The<br>
>> memory<br>
>> layout down in the first 1MB for boot loaders is roughly:<br>
>><br>
>> 0x0000: real-mode IDT<br>
>> 0x0400: BIOS data<br>
>> 0x7c00: where BIOS loads boot loaders such as /boot/mbr, etc.<br>
>> 0x1000: various BTX global data like GDT, TSS, IDT, stacks<br>
>> 0x9000: BTX kernel<br>
>> 0xa000: BTX client (loader.bin)<br>
>> 0xa0000: top of BTX client stack (though this can be a bit lower f=
or cases<br>
>> like<br>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 PXE booting)<br>
>><br>
>> The real size constraint is on the BTX client (loader.bin) and the=
fact<br>
>> that<br>
>> it's text/data/bss plus stack need to fit into that 576k windo=
w (give or<br>
>> take).<br>
>> btxldr isn't stored in low memory, so its size isn't relev=
ant, and BTX's<br>
>> code<br>
>> always takes up a full page even though it is much smaller.<br>
>><br>
> <br>
> Where does 576k come from? That's 589824 bytes, but a0000-a000 is =
614400<br>
> bytes. The delta is 24k (24576). My 'observed' value of about =
515,000 is<br>
> another<br>
> 75k below that, suggesting we are needing 100k of stack? Can that be r=
ight?<br>
> I knew<br>
> lua ate a lot of stack, but wow!<br>
<br>
Hmm, I converted 0xa000 to 64k instead of 40k in my head which is where<br>
the 576k came from.=C2=A0 Yeah, the total size is 600k.=C2=A0 100k stack do=
es seem<br>
like a lot.=C2=A0 It is possible that other BIOS ROMs besides just PXE migh=
t<br>
steal data from the stack top.=C2=A0 You could maybe try looking at some of=
<br>
your existing BIOS-boot machines to check the 16-bit word at physical<br>
address 0x413.=C2=A0 That gives you the actual top of the 640k window.=C2=
=A0 On<br>
my current desktop (albeit booted via UEFI and not BIOS) it is 629k:<br>
<br>
% sudo dd if=3D/dev/mem bs=3D1 iseek=3D0x413 count=3D2 | hd<br>
2+0 records in<br>
2+0 records out<br>
2 bytes transferred in 0.000026 secs (75643 bytes/sec)<br>
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.|<br>
00000002<br>
% gdb<br>
...<br>
(gdb) p/d 0x275<br>
$2 =3D 629<br>
Still, that's only 11k gone.<br></blockquote><div><br></div><div>So on =
the machine that I'm having issues with...</div><div><br></div><div># d=
d if=3D/dev/mem bs=3D1 iseek=3D0x413 count=3D2 | hd<br></div><div>00000000 =
=C2=A037 02</div><div># echo=C2=A0 $((0x237))</div><div>567</div><div><br><=
/div><div>Super Yikes!</div><div><br></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);=
padding-left:1ex">
I do think that when people have ran into trouble in the past it has been<b=
r>
in situations that can recurse, e.g. using psuedo-filesystems like gzipfs<b=
r>
where the gzipfs open routine tries to open the underlying "foo.gz&quo=
t; file,<br>
etc.<br></blockquote><div><br></div><div>Yea, I'm having trouble becaus=
e I'm missing 73k of stack...</div><div><br></div><div>Warner</div><div=
>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
-- <br>
John Baldwin<br>
</blockquote></div></div>
--000000000000ecd6f805e6016e6b--