Updates for elf(5)
In revision 1.35 EI_BRAND was removed in conjunction with EI_OSABI and EI_ABIVERSION being added, but it looks like this has not been reflected in elf(5). The only place EI_BRAND appears in OpenBSD's current source tree is this man page, as such I think it's worth removing. For a quick comparison to other systems FreeBSD still mentions EI_BRAND but NetBSD does not (and never appeared to document this in any man page). With regards to EI_OSABI and EI_ABIVERSION FreeBSD covers the defined values whereas NetBSD does not as they note only ELFOSABI_SYSV is used. On the other hand FreeBSD does indeed mark native binaries as ELFOSABI_FREEBSD. Further afield in Linux EI_BRAND was removed, EI_OSABI and EI_ABIVERSION defined values are covered similar to FreeBSD. The diff below removes mention of EI_BRAND and uncomments the EI_OSABI and EI_ABIVERSION parts which appear to have been present since the initial appearance of this man page. In addition I've added the mention of the Modesto and OpenBSD EI_OSABI values as they are defined in sys/sys/exec_elf.h. diff --git a/share/man/man5/elf.5 b/share/man/man5/elf.5 index 57b0bf0da4d..6ce92ef9bb4 100644 --- a/share/man/man5/elf.5 +++ b/share/man/man5/elf.5 @@ -207,51 +207,56 @@ Invalid version. .It Dv EV_CURRENT Current version. .El -.\" .It Dv EI_OSABI -.\" This byte identifies the operating system -.\" and ABI to which the object is targeted. -.\" Some fields in other ELF structures have flags -.\" and values that have platform specific meanings; -.\" the interpretation of those fields is determined by the value of this byte. -.\" The following values are currently defined: -.\" .Pp -.\" .Bl -tag -width "ELFOSABI_STANDALONE" -compact -.\" .It Dv ELFOSABI_SYSV -.\" UNIX System V ABI. -.\" .It Dv ELFOSABI_HPUX -.\" HP-UX operating system ABI. -.\" .It Dv ELFOSABI_NETBSD -.\" .Nx -.\" operating system ABI. -.\" .It Dv ELFOSABI_LINUX -.\" GNU/Linux operating system ABI. -.\" .It Dv ELFOSABI_HURD -.\" GNU/Hurd operating system ABI. -.\" .It Dv ELFOSABI_86OPEN -.\" 86Open Common IA32 ABI. -.\" .It Dv ELFOSABI_SOLARIS -.\" Solaris operating system ABI. -.\" .It Dv ELFOSABI_MONTEREY -.\" Monterey project ABI. -.\" .It Dv ELFOSABI_IRIX -.\" IRIX operating system ABI. -.\" .It Dv ELFOSABI_FREEBSD -.\" .Fx -.\" operating system ABI. -.\" .It Dv ELFOSABI_TRU64 -.\" TRU64 UNIX operating system ABI. -.\" .It Dv ELFOSABI_ARM -.\" ARM architecture ABI. -.\" .It Dv ELFOSABI_STANDALONE -.\" Stand-alone (embedded) ABI. -.\" .El -.\" .It Dv EI_ABIVERSION -.\" This byte identifies the version of the ABI -.\" to which the object is targeted. -.\" This field is used to distinguish among incompatible versions of an ABI. -.\" The interpretation of this version number -.\" is dependent on the ABI identified by the EI_OSABI field. -.\" Applications conforming to this specification use the value 0. +.It Dv EI_OSABI +This byte identifies the operating system +and ABI to which the object is targeted. +Some fields in other ELF structures have flags +and values that have platform specific meanings; +the interpretation of those fields is determined by the value of this byte. +The following values are currently defined: +.Pp +.Bl -tag -width "ELFOSABI_STANDALONE" -compact +.It Dv ELFOSABI_SYSV +UNIX System V ABI. +.It Dv ELFOSABI_HPUX +HP-UX operating system ABI. +.It Dv ELFOSABI_NETBSD +.Nx +operating system ABI. +.It Dv ELFOSABI_LINUX +GNU/Linux operating system ABI. +.It Dv ELFOSABI_HURD +GNU/Hurd operating system ABI. +.It Dv ELFOSABI_86OPEN +86Open Common IA32 ABI. +.It Dv ELFOSABI_SOLARIS +Solaris operating system ABI. +.It Dv ELFOSABI_MONTEREY +Monterey project ABI. +.It Dv ELFOSABI_IRIX +IRIX operating system ABI. +.It Dv ELFOSABI_FREEBSD +.Fx +operating system ABI. +.It Dv ELFOSABI_TRU64 +TRU64 UNIX operating system ABI. +.It Dv ELFOSABI_MODESTO +Modesto operating system ABI. +.It Dv ELFOSABI_OPENBSD +.Ox +operating system ABI. +.It Dv ELFOSABI_ARM +ARM architecture ABI. +.It Dv ELFOSABI_STANDALONE +Stand-alone (embedded) ABI. +.El +.It Dv EI_ABIVERSION +This byte identifies the version of the ABI +to which the object is targeted. +This field is used to distinguish among incompatible versions of an ABI. +The interpretation of this version number +is dependent on the ABI identified by the EI_OSABI field. +Applications conforming to this specification use the value 0. .It Dv EI_PAD Start of padding. These bytes are reserved and set to zero. @@ -259,8 +264,6 @@ Programs which read them should ignore them. The value for EI_PAD will change in the future if currently unused bytes are given meanings. -.It Dv EI_BRAND -Start of architecture identification. .It Dv EI_NIDENT The size of the e_ident array. .El
Re: Clarifications about ELF(5)
> On Sat, Feb 27, 2021 at 07:26:42PM +0000, George Brown wrote: > > > hi. diff committed, with one change: we did not add "must" (just removed > > > "usually"). > > > > > > jmc > > > > Thanks Jason. Though browsing cvsweb it seems the commit did include the > > "must" not sure if the decision changed after sending your mail or the > > wrong diff got applied? > > > > thanks, i totally messed up my commit. i've fixed that now. sorry that i > also didn;t credit you as the author of the diff! > > thanks for your diff and the follow up. > jmc No worries! I seem to have fudged the subject in my last mail so it seems fat-fingers are abound. Thanks again.
Clarifications about ELF(5)
> hi. diff committed, with one change: we did not add "must" (just removed > "usually"). > > jmc Thanks Jason. Though browsing cvsweb it seems the commit did include the "must" not sure if the decision changed after sending your mail or the wrong diff got applied?
Clarifications about ELF(5)
Binaries without a .note.openbsd.ident section fail to execute. This note section is mentioned in the ELF man page as follows. > .note This section holds information in the note section format >described below. This section is of type SHT_NOTE. No >attribute types are used. OpenBSD native executables usually >contain a .note.openbsd.ident section to identify themselves, >for the kernel to bypass any compatibility ELF binary emula- >tion tests when loading the file. The use of the word "usually" makes this read ambiguously to me. In that it's not clear if this note is present and/or required in all binaries. Examining binaries on my system it seems this note is indeed always present and from practise does seem to be required (removing it from binaries with objcopy -R causes execution to fail). The mention of "emulation" made we wonder if perhaps this was referring to the old compat_linux layer. Reviewing the history it seems this part of the man page is largely unchanged from it's import in V 1.1 which pre-dates the removal of compat_linux. Is this indeed a remnant? If so should an update with firmer wording be made, perhaps something like the following? Though I'm not really sure what in the underlying implantation this note represents in a post compat_linux removal world? diff --git a/share/man/man5/elf.5 b/share/man/man5/elf.5 index d22279f6738..aece235de6b 100644 --- a/share/man/man5/elf.5 +++ b/share/man/man5/elf.5 @@ -1026,10 +1026,9 @@ This section is of type .Dv SHT_NOTE . No attribute types are used. .Ox -native executables usually contain a +native executables must contain a .Sy .note.openbsd.ident -section to identify themselves, for the kernel to bypass any compatibility -ELF binary emulation tests when loading the file. +section to identify themselves. .It .plt This section holds the procedure linkage table. This section is of type
Does rpki-client need to unveil(NULL, NULL)?
After pledge is immediately called without the unveil promise so this
seems redundant.
diff --git a/usr.sbin/rpki-client/main.c b/usr.sbin/rpki-client/main.c
index f05ec1c5837..53ee4223371 100644
--- a/usr.sbin/rpki-client/main.c
+++ b/usr.sbin/rpki-client/main.c
@@ -1498,8 +1498,6 @@ main(int argc, char *argv[])
/* Only allow access to BASE_DIR. */
if (unveil(BASE_DIR, "r") == -1)
err(1, "%s: unveil", BASE_DIR);
- if (unveil(NULL, NULL) == -1)
- err(1, "unveil");
if (pledge("stdio rpath", NULL) == -1)
err(1, "pledge");
proc_parser(fd[0], force);
Re: less -S does not "truncate" lines
Hi Ingo, Yes the usage of "truncate" and "chop" are unfortunate. I agree positive language is always better. Many thanks, George
less -S does not "truncate" lines
When viewing a file with "less -S" that has lines longer than $COLUMNS said lines are simply not wrapped. The contents of said lines is still available, one simply needs to scroll horizontally. I would have expected the contents displayed within less to be as if I had run something like "cut -c 1-$COLUMNS file". I came across this as I was wondering why "less -FS" was still paginating on inputs with long lines that would have otherwise fit on the screen. I have observed this behaviour on the following platforms. * OpenBSD 6.5 * OpenBSD 6.5 - current (snapshot 2019-07-19) * FreeBSD 12 * Ubunutu 19.04 * macOS 10.14.5 Given the consistent behaviour I would think it is my expectation that is wrong rather than the observed result. It could be argued this is a "visual truncation" from the current view. However in my mind the word "truncation" has a very specific meaning of dropping a remainder such that it is no longer available at all. As such I would suggest an alteration to the description in the man page. For reference the GNU less man page is the only one that doesn't use the word "truncate", instead describing it as "chopped rather than folded". diff --git a/usr.bin/less/less.1 b/usr.bin/less/less.1 index 52d2049562e..22c3324ea0f 100644 --- a/usr.bin/less/less.1 +++ b/usr.bin/less/less.1 @@ -499,10 +499,7 @@ each type of control character). Thus, various display problems may result, such as long lines being split in the wrong place. .It Fl S | -chop-long-lines -Causes lines longer than the screen width to be -chopped (truncated) rather than wrapped. -That is, the portion of a long line that does not fit in -the screen width is not shown. +Lines longer than the screen width will not be wrapped. The default is to wrap long lines; that is, display the remainder on the next line. .It Fl s | -squeeze-blank-lines
Remove commented out pledge in tsort
Removes commented out pledge with whitelist, this is the only instance I
found of this grep'ing through base.
diff --git usr.bin/tsort/tsort.c usr.bin/tsort/tsort.c
index 5caa733f4..cc1cba164 100644
--- usr.bin/tsort/tsort.c
+++ usr.bin/tsort/tsort.c
@@ -879,7 +879,6 @@ parse_args(int argc, char *argv[], struct ohash *pairs)
files[i] = NULL;
-/*if (pledge("stdio rpath", files) == -1) */
if (pledge("stdio rpath", NULL) == -1)
err(1, "pledge");
Mention start, stop, restart, reload, and check in rcctl.8
Arguably these options are fairly obvious but I was prompted by the fact that "check" is not mentioned in the man page and this differs from the nomenclature of "status" often used in other systems. This is the first time I've sent a diff so I've gone for minimal change only mentioning these in the synopsis and have not expanded up these in the description. This is akin to the FreeBSD man page for service(8). Arguably the fact "reload" sends SIGHUP could be worth mentioning but as a sysadmin it's the behavior I'd be expecting anyway. diff --git usr.sbin/rcctl/rcctl.8 usr.sbin/rcctl/rcctl.8 index cbce9623720..4188fd26f2c 100644 --- usr.sbin/rcctl/rcctl.8 +++ usr.sbin/rcctl/rcctl.8 @@ -22,6 +22,9 @@ .Nd configure and control daemons and services .Sh SYNOPSIS .Nm rcctl +.Cm start Ns | Ns Cm stop Ns | Ns Cm restart Ns | Ns Cm reload Ns | Ns Cm check +.Op Ar daemon ... +.Nm rcctl .Cm get Ns | Ns Cm getdef Ns | Ns Cm set .Ar service | daemon Op Ar variable Op Ar arguments .Nm rcctl
