Commit Graph

32 Commits

Author SHA1 Message Date
John Hood
dbdf2b52f5 loader: support.4th resets the read buffer incorrectly
Large nextboot.conf files (over 80 bytes) are not read correctly by the
Forth loader, causing file parsing to abort, and nextboot configuration
fails to apply.

Simple repro:

nextboot -e foo=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
shutdown -r now

That will cause the bug to cause a parse failure but shouldn't otherwise
affect the boot.  Depending on your loader configuration, you may also
have to set beastie_disable and/or reduce the number of modules loaded
to see the error on a small console screen.  12.0 or CURRENT users will
also have to explicitly use the Forth loader instead of the Lua loader.
The error will look something like:

Warning: syntax error on file /boot/loader.conf.local
foo="xxxxxxxxxxxxxxnextboot_enable="YES"
                                    ^
/boot/support.4th has crude file I/O buffering, which uses a buffer
'read_buffer', defined to be 80 bytes by the 'read_buffer_size'
constant.  The loader first tastes nextboot.conf, reading and parsing
the first line in it for nextboot_enable="YES".  If this is true, then
it reopens the file and parses it like other loader .conf files.

Unfortunately, the file I/O buffering code does not fully reset the
buffer state in the reset_line_reading word.  If the last file was read
to the end, that doesn't matter; the file buffer is treated as empty
anyway.  But in the nextboot.conf case, the loader will not read to the
end of file if it is over 80 bytes, and the file buffer may be reused
when reading the next file.  When the file is reread, the corrupt text
may cause file parsing to abort on bad syntax (if the corrupt line has
<>2 quotes in it), the wrong variable to be set, no variable to be set
at all, or (if the splice happens to land at a line ending) something
approximating normal operation.

The bug is very old, dating back to at least 2000 if not before, and is
still present in 12.0 and CURRENT r345863 (though it is now hidden by
the Lua loader by default).

Suggested one-line attached.  This does change the behavior of the
reset_line_reading word, which is exported in the line-reading
dictionary (though the export is not documented in loader man pages).
But repo history shows it was probably exported for the PNP support
code, which was never included in the loader build, and was removed 5
months ago.

One thing that puzzles me: how has this bug gone unnoticed/unfixed for
nearly 2 decades?  I find it hard to believe that nobody's tried to do
something interesting with nextboot, like load a kernel and filesystem,
which is what I'm doing.

Tested by:		Gary Jennejohn
PR:			239315
MFC After:		3 weeks
Reviewed by:		imp (and correctly applied this time)
Differential Revision:	https://reviews.freebsd.org/D31328
2021-07-28 13:50:38 -06:00
Warner Losh
4783fb730f Revert "loader: support.4th resets the read buffer incorrectly"
This reverts commit 9c1c02093b. It seems
to have broken all old nextboot.conf files causing hangs on boot.

Sponsored by:		Netflix
2021-07-26 16:40:41 -06:00
John Hood
9c1c02093b loader: support.4th resets the read buffer incorrectly
Large nextboot.conf files (over 80 bytes) are not read correctly by the
Forth loader, causing file parsing to abort, and nextboot configuration
fails to apply.

Simple repro:

nextboot -e foo=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
shutdown -r now

That will cause the bug to cause a parse failure but shouldn't otherwise
affect the boot.  Depending on your loader configuration, you may also
have to set beastie_disable and/or reduce the number of modules loaded
to see the error on a small console screen.  12.0 or CURRENT users will
also have to explicitly use the Forth loader instead of the Lua loader.
The error will look something like:

Warning: syntax error on file /boot/loader.conf.local
foo="xxxxxxxxxxxxxxnextboot_enable="YES"
                                    ^
/boot/support.4th has crude file I/O buffering, which uses a buffer
'read_buffer', defined to be 80 bytes by the 'read_buffer_size'
constant.  The loader first tastes nextboot.conf, reading and parsing
the first line in it for nextboot_enable="YES".  If this is true, then
it reopens the file and parses it like other loader .conf files.

Unfortunately, the file I/O buffering code does not fully reset the
buffer state in the reset_line_reading word.  If the last file was read
to the end, that doesn't matter; the file buffer is treated as empty
anyway.  But in the nextboot.conf case, the loader will not read to the
end of file if it is over 80 bytes, and the file buffer may be reused
when reading the next file.  When the file is reread, the corrupt text
may cause file parsing to abort on bad syntax (if the corrupt line has
<>2 quotes in it), the wrong variable to be set, no variable to be set
at all, or (if the splice happens to land at a line ending) something
approximating normal operation.

The bug is very old, dating back to at least 2000 if not before, and is
still present in 12.0 and CURRENT r345863 (though it is now hidden by
the Lua loader by default).

Suggested one-line attached.  This does change the behavior of the
reset_line_reading word, which is exported in the line-reading
dictionary (though the export is not documented in loader man pages).
But repo history shows it was probably exported for the PNP support
code, which was never included in the loader build, and was removed 5
months ago.

One thing that puzzles me: how has this bug gone unnoticed/unfixed for
nearly 2 decades?  I find it hard to believe that nobody's tried to do
something interesting with nextboot, like load a kernel and filesystem,
which is what I'm doing.

PR: 239315
Reviewed by: imp
2021-07-11 08:47:29 -06:00
Toomas Soome
4ba91fa073 loader: do not output empty menu title
As we output spaces around the menu title, we should also check,
if the title is actually empty string.

PR:		255299
Submitted by:	Jose Luis Duran
Reported by:	Jose Luis Duran
MFC after:	1 week
2021-04-21 14:50:23 +03:00
Toomas Soome
62ffcaab8f loader: insert spaces around menu title
Small visual nit, make menu title more clean

MFC after: 3 days
2021-03-23 09:31:36 +02:00
Toomas Soome
6a3095aa6d loader_4th: brand image is aligned right
With screen border removed, I forgot to update forth brand image
coordinates to avoid image alignment.
2021-03-06 10:59:35 +02:00
Toomas Soome
3630506b9d loader: implement framebuffer console
Draw console on efi.
Add vbe framebuffer for BIOS loader (vbe off, vbe on, vbe list,
vbe set xxx).
autoload font (/boot/fonts) based on resolution and font size.
Add command loadfont (set font by file) and
variable screen.font (set font by size). Pass loaded font to kernel.

Export variables:
screen.height
screen.width
screen.depth

Add gfx primitives to draw the screen and put png image on the screen.
Rework menu draw to iterate list of consoles to enamble device specific
output.

Probably something else I forgot...

Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D27420
2021-01-02 21:41:36 +02:00
Gordon Bergling
812b09037d Fix a few mandoc issues
- whitespace at end of input line
- skipping paragraph macro: Pp at the end of Sh
- new sentence, new line
- consider using OS macro: Fx
- AUTHORS section without An macro
- skipping paragraph macro: Pp before Ss
2020-10-09 15:14:19 +00:00
Toomas Soome
e307eb94ae loader: zfs should support bootonce an nextboot
bootonce feature is temporary, one time boot, activated by
"bectl activate -t BE", "bectl activate -T BE" will reset the bootonce flag.

By default, the bootonce setting is reset on attempt to boot and the next
boot will use previously active BE.

By setting zfs_bootonce_activate="YES" in rc.conf, the bootonce BE will
be set permanently active.

bootonce dataset name is recorded in boot pool labels, bootenv area.

in case of nextboot, the nextboot_enable boolean variable is recorded in
freebsd:nvstore nvlist, also stored in boot pool label bootenv area.
On boot, the loader will process /boot/nextboot.conf if nextboot_enable
is "YES", and will set nextboot_enable to "NO", preventing /boot/nextboot.conf
processing on next boot.

bootonce and nextboot features are usable in both UEFI and BIOS boot.

To use bootonce/nextboot features, the boot loader needs to be updated on disk;
if loader.efi is stored on ESP, then ESP needs to be updated and
for BIOS boot, stage2 (zfsboot or gptzfsboot) needs to be updated
(gpart or other tools).

At this time, only lua loader is updated.

Sponsored by:	Netflix, Klara Inc.
Differential Revision:	https://reviews.freebsd.org/D25512
2020-09-21 09:01:10 +00:00
Ryan Moeller
73531a2abd loader: Fully reset terminal settings, not just colors
Reviewed by:	kevans
Reviewed by:	tsoome
Approved by:	mav (mentor)
MFC after:	1 week
Sponsored by:	iXsystems, Inc.
Differential Revision:	https://reviews.freebsd.org/D21733
2020-03-27 17:37:31 +00:00
Toomas Soome
2de5a21edc loader_4th: menu items need to reset color attribute, not switch to white
Forth menu kernel and BE entries, instead of resetting the color attribute,
are switching to white color.
2019-09-22 16:10:25 +00:00
Kyle Evans
bb7b569d36 loader: Respect loader_color=YES for serial consoles
It's not uncommon these days for the terminals attached to serial consoles
to support ANSI escape sequences. However, we assume escape sequences may
break some serial consoles and default to not using them when boot_serial or
boot_multicons (or if console contains "comconsole" in the forth loader) for
broader compatibility. We also have loader_color which can be explicitly set
to "NO" to disable the use of ANSI escape sequences.

The problem is that loader_color=YES gets ignored when boot_serial=YES or
boot_multicons=YES (or when console contains "comconsole" in the forth
loader).

To fix, the existing default behavior remains unchanged when loader_color is
unset, loader_color=NO explicitly disables the use of ANSI escape sequences
still, and the change is that loader_color=YES can now be used to explicitly
allow ANSI escapes when a serial console is enabled.

Submitted by:	Ryan Moeller <ryan@ixsystems.com>
Reviewed by:	tsoome (forth), kevans (lua)
MFC after:	1 week
Sponsored by:	iXsystems, Inc. (Ryan)
Differential Revision:	https://reviews.freebsd.org/D21732
2019-09-20 19:43:40 +00:00
Toomas Soome
68861a62f5 loader: provide u> and xemit words if needed
We have external interpreter (userboot.so) which may be lagging behind
with updates and may be missing u> xemit words.
2019-09-17 18:05:33 +00:00
Toomas Soome
1781ad707e loader_4th: scan_buffer can leave empty string on stack
When the file processing is done, we will have string with lenght 0 in stack and we will attempt to
allocate 0 bytes.
2019-09-16 20:26:53 +00:00
Toomas Soome
56758831fe loader: use teken teminal emulator for x86 and uefi
Replace mini cons25 emulator with teken, this does enable us proper console
terminal for loader and will make it possible to implement different
back end callbacks to draw to screen.

At this time we still only "draw" in text mode.
2019-09-05 22:15:50 +00:00
Warner Losh
52467047aa Regularize the Netflix copyright
Use recent best practices for Copyright form at the top of
the license:
1. Remove all the All Rights Reserved clauses on our stuff. Where we
   piggybacked others, use a separate line to make things clear.
2. Use "Netflix, Inc." everywhere.
3. Use a single line for the copyright for grep friendliness.
4. Use date ranges in all places for our stuff.

Approved by: Netflix Legal (who gave me the form), adrian@ (pmc files)
2019-02-04 21:28:25 +00:00
Devin Teske
ff9154be8b Restore the ability to prevent the user from interrupting the boot process
without first entering the password stored in loader.conf(5).

PR:		kern/207069
Reported by:	david@dcrosstech.com
MFC after:	3 days
Sponsored by:	Smule, Inc.
2018-10-21 00:15:51 +00:00
Devin Teske
5cc9fabecf check-password.4th(8): Fix manual [in]accuracy
SVN r280384 updated the maximum password length from 16 bytes to 255. The
manual was not updated to reflect this. Found while working on kern/207069.

MFC after:	3 days
X-MFC-to:	stable/11 stable/10
Sponsored by:	Smule, Inc.
2018-06-24 19:29:29 +00:00
Kyle Evans
fb205d37d7 forthloader: Remove "EFI boot environment message"
Contrary to what the message says, this is not only executed in an EFI
context- it provides functions for use in an EFI environment. I don't think
there's much reason to broadcast this fact when we haven't in the past, so
just remove it.

Reported by:	emaste (a while ago), cperciva
2018-04-25 02:42:57 +00:00
Warner Losh
7afc7a8717 Revert r332275, r332272, r332270
There's problems with them. The order of efi stuff isn't quite right,
and there's various problems. Revert until thos problems can be fixed.

Reviewed by: kevans@
2018-04-11 18:02:13 +00:00
Toomas Soome
ff77d7a560 loader: 332270 did use wrong path for efi.4th
The correct  path is still /boot/efi.4th
2018-04-08 11:55:27 +00:00
Toomas Soome
cae0ecf693 loader: include efi.4th only if we do have uefi
Also simplify efi.4th.
2018-04-08 11:39:27 +00:00
Kyle Evans
9afece1e2f forthloader: Don't break BIOS boots...
I thought I tested this scenario, but clearly I failed to. =(

BIOS boots won't have efi-autoresizecons, so trying to use it as a forth
word fails during include. Use evaluate on "efi-autoresizecons" as a string
instead to move any potential errors to runtime- safely after we've already
checked that we're booting UEFI.

Pointy hat to:	me
Reported by:	cy
2018-03-22 04:16:14 +00:00
Kyle Evans
5ef2174a50 Forth version of EFI autoresizing
r331321 delegated autoresizing to an efi-autoresizecons command that
currently is expected to be done in forth/lua prior to drawing anything
useful.

Add the Forth version of the lua addition in r331321, hook efi.4th up to be
installed.

efiboot? was written by dteske@; anything outside of that may be blamed on
me.
2018-03-21 22:01:51 +00:00
Warner Losh
89181f2038 These two directories build man pages, so it's incorrect to tag them
NO_OBJ. Also, make sure the loader.conf.5 man gets built and installed.
2018-02-26 15:41:20 +00:00
Warner Losh
b6955dfd92 Go back to one loader.conf
We really only need one loader.conf. The other loader.conf was created
because the current one took forever to parse in FORTH. That will be
fixed in the next commit.
2018-02-26 03:16:47 +00:00
Warner Losh
0c38f15ac7 Add NO_OBJ to those directories that don't make anything.
For directories that don't many anything, add NO_OBJ=t just before we
include bsd.init.mk. This prevents them from creating an OBJ
directory. In addition, prevent defs.mk from creating the machine
related links in these cases. They aren't needed and break, at least
on stable, the read-only src tree build.
2018-02-26 03:16:04 +00:00
Warner Losh
c15e695270 Remove pcibios forth support.
I had thought that this would be useful. However it was committed too
late, and wound up being unused. It's in the way of future work now,
so retire it rather than bring it forward.
2018-02-02 15:01:49 +00:00
Warner Losh
b28421d5f1 These 4th words were an attempt to allow integration into the boot
loader scripts. However, that path won't be taken after all it
seems. Remove this code before it decays into uselessness. Also remove
build dependencies on forth no longer needed.
2018-02-02 15:01:44 +00:00
Warner Losh
74bb0b0e9a Retire pnp.4th and the code needed only for 4th words used here.
This has never been installed. It was added to the tree disconnected
to the build in FreeBSD 5 (17 years ago) and has never been used as
far as I can tell. The desired improvements never really happened
(despite a couple minor cleanups along the way). It's relevance is
long past, so better to retire it.
2018-02-02 15:01:33 +00:00
Kyle Evans
db180ae55c stand: Add /boot/overlays to allow separation of overlays from base FDT
This matches directory structure used commonly in Linux-land, and it's
cleaner than mixing overlays into the existing module paths. Overlays are
still mixed in by specifying fdt_overlays in loader.conf(5).

Reviewed by:	manu
Differential Revision:	https://reviews.freebsd.org/D13922
2018-01-18 04:58:54 +00:00
Warner Losh
ca987d4641 Move sys/boot to stand. Fix all references to new location
Sponsored by:	Netflix
2017-11-14 23:02:19 +00:00