[diff] src/usr.sbin/smtpd: table_diff lacks some lookup kinds
Hellow,
The K_STRING and K_REGEX lookup kinds are missing from table_db even though
nothing prevents
them from working technically. The following diff is enough to allow db tables
to be used on
regex or string contexts.
Index: table_db.c
===
RCS file: /cvs/src/usr.sbin/smtpd/table_db.c,v
retrieving revision 1.22
diff -u -p -r1.22 table_db.c
--- table_db.c 23 Jan 2021 16:11:11 - 1.22
+++ table_db.c 29 Aug 2021 20:08:30 -
@@ -55,7 +55,9 @@ static char *table_db_get_entry_match(vo
struct table_backend table_backend_db = {
"db",
-
K_ALIAS|K_CREDENTIALS|K_DOMAIN|K_NETADDR|K_USERINFO|K_SOURCE|K_MAILADDR|K_ADDRNAME|K_MAILADDRMAP,
+ K_ALIAS|K_CREDENTIALS|K_DOMAIN|K_NETADDR|K_USERINFO|
+ K_SOURCE|K_MAILADDR|K_ADDRNAME|K_MAILADDRMAP|K_RELAYHOST|
+ K_STRING|K_REGEX,
table_db_config,
NULL,
NULL,
OpenSSH: RSA/SHA1 disabled by default
Hi, RSA/SHA1, a.k.a the "ssh-rsa" signature type is now disabled by default in OpenSSH. While The SSH protocol confusingly uses overlapping names for key and signature algorithms, this does not stop the use of RSA keys and there is no need to regenerate "ssh-rsa" keys - most servers released in the last five years will automatically negotiate the use of RSA/SHA-256/512 signatures. This has been coming for a long time, but I do expect it will be distruptive for some people as there are likely to be some devices out there that cannot be upgraded to support the safer algorithms. In these cases, it is possible to selectively re-enable RSA/SHA1 support by specifying PubkeyAcceptedAlgorithms=+ssh-rsa in the ssh_config(5) or sshd_config(5) for the endpoint. Please report any problems here, to bugs@ or to openssh@ Thanks, Damien -- Forwarded message -- Date: Mon, 30 Aug 2021 09:53:10 From: Damien Miller To: source-chan...@cvs.openbsd.org Subject: CVS: cvs.openbsd.org: src CVSROOT:/cvs Module name:src Changes by: d...@cvs.openbsd.org2021/08/29 17:53:10 Modified files: usr.bin/ssh: myproposal.h Log message: After years of forewarning, disable the RSA/SHA-1 signature algorithm by default. It is feasible to create colliding SHA1 hashes, so we need to deprecate its use. RSA/SHA-256/512 remains available and will be transparently selected instead of RSA/SHA1 for most SSH servers released in the last five+ years. There is no need to regenerate RSA keys. The use of RSA/SHA1 can be re-enabled by adding "ssh-rsa" to the PubkeyAcceptedAlgorithms directives on the client and server. ok dtucker deraadt
Re: DANE in libressl?
> On 29 Aug 2021, at 16:14, Peter J. Philipp wrote: > > On Sun, Aug 29, 2021 at 07:16:20AM -0600, Theo de Raadt wrote: >> Is there a strong reason why this has to be in that specific library? > > Not really. I did see gnutls has dane functions and openssl has them too. > I can stick to just rolling the needed functionality in the syslogd. > > Noone out there is doing this already right? > Hello, I had started working on a standalone dane resolver based upon asr but I decided not to move it forward: OpenSSL has an interface for DANE and !OpenBSD projects are more likely to implement that interface, so I thought my plan of a standalone implementation would be inferior to a LibreSSL implementation that could be picked by ports and a libtls interface that could be picked by base daemons. I don’t have much code but I can share if you’re still interested.
vmm(4) testers needed: add IPI for vmclear and unlock kernel
tech@,
I'm looking for testers for the following diff that's designed to
address race conditions in vmm(4)'s VMCS state handling.
In short, there exists a probability that when a guest migrates to
another CPU core that the VMCS state hasn't been persisted to memory and
what *is* in memory does not match what's loaded on the current
CPU. (This probability increases as you have more sockets/cores, so if
you have larger workstations or servers, even if you run 1-2 guests this
should still be testable!)
If you use Intel hardware and have experienced spurious guest crashes
with errors similar to:
vcpu_run_vmx: failed vmlaunch...
or
vcpu_run_vmx: can't {read,write} procbased ctls on exit
please give this diff a spin. It should remove such crashes.
This diff makes changes that *might affect* AMD SVM users, so even if
you are not an Intel user, I'd appreciate your testing. You should see
no changes, but you will be running a different code, so keep an eye
open for regressions!
To summarize what changes, this diff:
- adds a new amd64 IPI that requests a remote CPU to issue a vmclear
instruction to flush the loaded VMCS state from the CPU to memory
(this requires tracking a physical address on cpu_info, so it also
adds a vmm specific lock around the cpu_info)
- adds a per-vcpu lock, required for guarding vcpu state to prevent
corruption due to interrupt requests from vmd(8)'s emulated hardware
event thread
- unlocks the kernel prior to dispatching the ioctl and relocks on exit
or only when needed (e.g. uvm changes) (Don't get exciting thinking
this makes things "faster," it's honestly more helpful for surfacing
race conditions we've had that remained hidden underneath the lock.)
- simplifies the VMX run loop pulling some host state persistence out of
the run loop
- removes the IPI kick when a guest injects an interrupt
- removes the yield calls from the vmx and svm run loops...if we
"should" yield simply exit to vmd instead of trying to track cpu
I've tested on my X270 (i7-7500U) and my X13 Gen 1 (AMD Ryzen 5 PRO
4650U). My usual Nix-based/Linux stress test has failed to trigger
crashes.
Please consider compiling with "option VMM_DEBUG" set in your
config. There are extra state corruption checks (via the vmptsrt
instructions) that can help us track down any issues seen on Intel
machines via panicking the kernel.
TIA,
dv
Index: sys/arch/amd64/amd64/cpu.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/cpu.c,v
retrieving revision 1.153
diff -u -p -r1.153 cpu.c
--- sys/arch/amd64/amd64/cpu.c 11 Mar 2021 11:16:55 - 1.153
+++ sys/arch/amd64/amd64/cpu.c 4 Aug 2021 13:31:05 -
@@ -789,6 +789,8 @@ cpu_init_vmm(struct cpu_info *ci)
if (!pmap_extract(pmap_kernel(), (vaddr_t)ci->ci_vmxon_region,
>ci_vmxon_region_pa))
panic("Can't locate VMXON region in phys mem");
+ ci->ci_vmcs_pa = VMX_VMCS_PA_CLEAR;
+ rw_init(>ci_vmcs_lock, "vmcslock");
}
}
#endif /* NVMM > 0 */
Index: sys/arch/amd64/amd64/ipifuncs.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/ipifuncs.c,v
retrieving revision 1.35
diff -u -p -r1.35 ipifuncs.c
--- sys/arch/amd64/amd64/ipifuncs.c 13 Sep 2020 11:53:16 - 1.35
+++ sys/arch/amd64/amd64/ipifuncs.c 4 Aug 2021 13:31:05 -
@@ -63,6 +63,7 @@ void x86_64_ipi_halt(struct cpu_info *);
void x86_64_ipi_wbinvd(struct cpu_info *);
#if NVMM > 0
+void x86_64_ipi_vmclear_vmm(struct cpu_info *);
void x86_64_ipi_start_vmm(struct cpu_info *);
void x86_64_ipi_stop_vmm(struct cpu_info *);
#endif /* NVMM > 0 */
@@ -85,7 +86,11 @@ void (*ipifunc[X86_NIPI])(struct cpu_inf
{
x86_64_ipi_halt,
x86_64_ipi_nop,
+#if NVMM > 0
+ x86_64_ipi_vmclear_vmm,
+#else
NULL,
+#endif
NULL,
x86_64_ipi_reload_pctr,
x86_64_ipi_reload_mtrr,
@@ -137,6 +142,12 @@ x86_64_ipi_reload_mtrr(struct cpu_info *
#endif
#if NVMM > 0
+void
+x86_64_ipi_vmclear_vmm(struct cpu_info *ci)
+{
+ vmclear_on_cpu(ci);
+}
+
void
x86_64_ipi_start_vmm(struct cpu_info *ci)
{
Index: sys/arch/amd64/amd64/vmm.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/vmm.c,v
retrieving revision 1.286
diff -u -p -r1.286 vmm.c
--- sys/arch/amd64/amd64/vmm.c 8 Jun 2021 23:18:43 - 1.286
+++ sys/arch/amd64/amd64/vmm.c 4 Aug 2021 13:31:05 -
@@ -135,7 +135,7 @@ int vcpu_writeregs_svm(struct vcpu *, ui
int vcpu_reset_regs(struct vcpu *, struct vcpu_reg_state *);
int vcpu_reset_regs_vmx(struct vcpu *, struct vcpu_reg_state *);
int vcpu_reset_regs_svm(struct vcpu *, struct vcpu_reg_state *);
-int vcpu_reload_vmcs_vmx(uint64_t *);
+int vcpu_reload_vmcs_vmx(struct vcpu *);
int vcpu_init(struct vcpu *);
int vcpu_init_vmx(struct vcpu *);
int vcpu_init_svm(struct vcpu *);
Re: averse to lisp in base?
Hi, Tomasz Rola wrote on Sun, Aug 29, 2021 at 08:21:03PM +0200: > On Sun, Aug 29, 2021 at 03:27:27AM +0200, mayur...@kathe.in wrote: >> Would the core team consider including a minimalist lisp in the base? >> e.g. http://t3x.org/klisp/index.html [...] > If I would want to propose any Lisp into the base system, I would > point at s9fes (Scheme 9 from Empty Space), also by Nils Holm. As a general rule of thumb: if some program * is maintained by a person who is not an OpenBSD developer, * and/or is maintained in a repository outside of cvs.openbsd.org, * and is not required for building or running anything contained in the base system, then it is usually better maintained in ports than in base. For users, typing "doas pkg_add my_loveliest_lisp" once is negligible effort, so it really doesn't matter for them. For developers, regularly synching a piece of third-party software into base is quite tedious and wastes considerable working time, whereas keeping a port up to date causes orders of magnitude less work. For example, synching to base is a royal pain for essential stuff like clang and Perl and drm. It causes non-trivial work even for smaller stuff like unbound and nsd. In several caaes, it was such a nightmare that developers just gave up in those cases - for example, just think of nginx and sqlite. In any case, this thread is wildly off-topic on tech@. If you have additional questions related to this topic, please start a new thread on misc@, or post a port or a port update to ports@. Yours, Ingo
Re: averse to lisp in base?
On Sun, Aug 29, 2021 at 03:27:27AM +0200, mayur...@kathe.in wrote: > Would the core team consider including a minimalist lisp in the base? e.g. > http://t3x.org/klisp/index.html Hi. I am not the one to decide about such things but I have two cents to drop. I have skimmed the manual page for klisp and I suppose it does not offer interface to system calls. In essence, it seems to be of same usefullness as a Lisp interpreter written in, say, awk. If I would want to propose any Lisp into the base system, I would point at s9fes (Scheme 9 from Empty Space), also by Nils Holm. It is bigger than klisp, but at least gives some Unix/POSIX functions to use in the scripts. Also, it is Scheme, so in theory one can at least try to make use of some freely available Scheme code from the net. Much more useful in a Unix-like environment, I would say. http://t3x.org/s9fes/index.html But I am not proposing - I have no idea how many people would find this thing helpful in their life. As far as I know, there is not many (it any) scripts in Scheme that cater to Unix users. If one would like to have it on base, it is as easy as procuring shar archive which takes care of compiling and installing this stuff when needed and keeping it on some pendrive. -- Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_r...@bigfoot.com **
Re: Atomic signal flags for vi(1)
Hi Theo, Theo de Raadt wrote on Sun, Aug 29, 2021 at 11:38:18AM -0600: > Ingo Schwarze wrote: >> *If* more than one GS object ever existed and/or the .gp pointers >> in different SCR objects could point to different GS objects, this >> patch might change behaviour. > If such multiple GS condition ever existed, since signals are (global), > the handler is only indicating a signal has happened. And the code > observing non-zero of these signal-indicating variables would be > responsible to determine which event it applies to. Absolutely, that is the sane way to code such stuff. However, we have all seen signal handlers making complicated decisions by navigating complex, non-trivial data structures, even in our own tree. Of course, those need to be fixed. But before changing the code, i still need to figure out whether the seemingly non-trivial data structure is indeed non-trivial, and which higher-level code must be made smarter to preserve the functionality, or whether the apparent complexity merely hides the fact that the data is actually trivial, as i think it is in this case. > It is too hard to do this kind of work safely/atomically in a > signal handler. 100% correct. And yet, people do try to, and then it even works. Well, kind of. Most of the time. Until it suddenly doesn't. And when it suddenly doesn't, people are used to blaming cosmic muons (and yes, there is indeed about one of those per square centimeter per minute, on average) rather than thinking something might be wrong with their code. Yours, Ingo
Re: Atomic signal flags for vi(1)
> *If* more than one GS object ever existed and/or the .gp pointers > in different SCR objects could point to different GS objects, this > patch might change behaviour. If such multiple GS condition ever existed, since signals are (global), the handler is only indicating a signal has happened. And the code observing non-zero of these signal-indicating variables would be responsible to determine which event it applies to. It is too hard to do this kind of work safely/atomically in a signal handler.
Re: DANE in libressl?
On Sun, Aug 29, 2021, Peter J. Philipp wrote: > I can stick to just rolling the needed functionality in the syslogd. Maybe you can start with the code from Viktor Dukhovni https://github.com/vdukhovni/ssl_dane THIS CODE IS IN THE PUBLIC DOMAIN. so it can be freely used. It would be nice to have the full functionality in LibreSSL. -- Address is valid for this mailing list only, please do not reply to it direcly, but to the list.
Re: Atomic signal flags for vi(1)
Hi,
Theo de Raadt wrote on Sun, Aug 29, 2021 at 02:54:57AM -0600:
> This does look better.
>
> I appreciate that you are fixing this underlying problem first, before
> overlaying your timer diff.
Indeed.
> Is this working for the vi crowd?
*If* more than one GS object ever existed and/or the .gp pointers
in different SCR objects could point to different GS objects, this
patch might change behaviour. So the hardest part about veryfying
it is to make sure that only one single GS object exists at any
given time and all .gp pointers in all SCR objects always point to
that one GS object. GS and [.>]gs are used at hundreds of places,
but i only managed to find a single place where GS is instantiated
(gs_init() in cl/cl_main.c, which is called inly once at the very
beginning of main()), and only a single place where the .gp member
of SCR is ever changed, in screen_init() in common/screen.c, which
is called from a handful of places, but always with a pointer to
that one particular GS object.
So yes, i do think changing members of GS to static globals is safe
and testing with a single screen is sufficient. After the patch,
* SIGHUP prints "Hangup" and exits as expected;
* SIGINT prints "Interrupted" in the status line and exits insert
mode, but stays in vi(1);
* SIGTERM prints "Terminated" and exits as expected;
* window size changes work as expected both in the forground and
in the background while suspended with Ctrl-Z, and sending
SIGWINCH manually has no effect, as expected.
Note that the patch is incomplete. The signal handler functions
h_hup() and h_term() still aren't safe because they still write to
GCLP(__global_list)->killersig. But this patch performs one
well-defined step and is hard enough to audit already, so let's get
it committed, then take care of killersig in a second step.
So if someone wants to commit, this patch is OK schwarze@.
Alternatively, provide an OK and tell me to commit.
Be careful that the original author of this patch signed as "Tim"
but is not tim@ for all i can tell.
Yours,
Ingo
> trondd wrote:
>
> > "Theo de Raadt" wrote:
> >
> > > +h_alrm(int signo)
> > > +{
> > > + GLOBAL_CLP;
> > > +
> > > + F_SET(clp, CL_SIGALRM);
> > >
> > > F_SET is |=, which is not atomic.
> > >
> > > This is unsafe. Safe signal handlers need to make single stores to
> > > atomic-sized variables, which tend to be int-sized, easier to declare
> > > as sig_atomic_t. Most often these are global scope with the following
> > > type:
> > >
> > > volatile sig_atomic_t variable
> > >
> > > I can see you copied an existing practice. Sadly all the other
> > > signal handlers are also broken in the same way.
> > >
> > > The flag bits should be replaced with seperate sig_atomic_t variables.
> >
> > Ok. Took a swing at converting the signal handling to sig_atomic_t flags.
> > No additional changes added other than removing a redundant check of the
> > flags in cl_read.c. Seemed to be a pretty straight-forward conversion and
> > I haven't found any change in behavior.
> >
> > Tim.
> >
> >
> > Index: cl/cl.h
> > ===
> > RCS file: /cvs/src/usr.bin/vi/cl/cl.h,v
> > retrieving revision 1.10
> > diff -u -p -r1.10 cl.h
> > --- cl/cl.h 27 May 2016 09:18:11 - 1.10
> > +++ cl/cl.h 24 Aug 2021 23:34:27 -
> > @@ -11,6 +11,11 @@
> > * @(#)cl.h10.19 (Berkeley) 9/24/96
> > */
> >
> > +extern volatile sig_atomic_t cl_sighup;
> > +extern volatile sig_atomic_t cl_sigint;
> > +extern volatile sig_atomic_t cl_sigterm;
> > +extern volatile sig_atomic_t cl_sigwinch;
> > +
> > typedef struct _cl_private {
> > CHAR_T ibuf[256]; /* Input keys. */
> >
> > @@ -45,11 +50,7 @@ typedef struct _cl_private {
> > #defineCL_RENAME_OK0x0004 /* User wants the windows renamed. */
> > #defineCL_SCR_EX_INIT 0x0008 /* Ex screen initialized. */
> > #defineCL_SCR_VI_INIT 0x0010 /* Vi screen initialized. */
> > -#defineCL_SIGHUP 0x0020 /* SIGHUP arrived. */
> > -#defineCL_SIGINT 0x0040 /* SIGINT arrived. */
> > -#defineCL_SIGTERM 0x0080 /* SIGTERM arrived. */
> > -#defineCL_SIGWINCH 0x0100 /* SIGWINCH arrived. */
> > -#defineCL_STDIN_TTY0x0200 /* Talking to a terminal. */
> > +#defineCL_STDIN_TTY0x0020 /* Talking to a terminal. */
> > u_int32_t flags;
> > } CL_PRIVATE;
> >
> > Index: cl/cl_funcs.c
> > ===
> > RCS file: /cvs/src/usr.bin/vi/cl/cl_funcs.c,v
> > retrieving revision 1.20
> > diff -u -p -r1.20 cl_funcs.c
> > --- cl/cl_funcs.c 27 May 2016 09:18:11 - 1.20
> > +++ cl/cl_funcs.c 24 Aug 2021 23:34:27 -
> > @@ -601,7 +601,7 @@ cl_suspend(SCR *sp, int *allowedp)
> > if (cl_ssize(sp, 1, NULL, NULL, ))
> > return (1);
> > if (changed)
> > - F_SET(CLP(sp), CL_SIGWINCH);
> > +
Re: DANE in libressl?
On Sun, Aug 29, 2021 at 07:16:20AM -0600, Theo de Raadt wrote: > Is there a strong reason why this has to be in that specific library? Not really. I did see gnutls has dane functions and openssl has them too. I can stick to just rolling the needed functionality in the syslogd. Noone out there is doing this already right? Best Regards, -peter > Peter J. Philipp wrote: > > > Hi, > > > > I was wondering if anyone has wanted to implement DANE functions into > > OpenBSD? > > And LibreSSL perhaps? I want this for syslogd with TLS, but not sure if I'd > > be on someones toes here, if I start implementing... > > > > With unwind we can make use of things such as DANE due to validation of > > DNSSEC. > > > > Best Regards, > > -peter > >
Re: allow KARL with config(8)'d kernels
Ingo Schwarze wrote: > One - admittedly completely unUNIXy - way would be to invent a long, > descriptive name like /etc/kernel.config.commands or even /bsd.config.cmd > in the root rather than the /etc directory, which is more discoverable > because it is right next to the kernel itself. The UNIXy way > is not necessarily better: Ken would have invented a very short, > pronouncable name that is not an English word but similar to one, > like /etc/sycoc (for SYstem COnfiguration Commands). I have no idea why you talk about Ken, how obscure back in those days it wasn't called /kernel, either. the pathname "kernel.something" which is supposed to be somewhat related to a non-existant pathname "kernel", is what I object to. perhaps /etc/bsd.re-config but certainly the sub-phrase "kernel" is not discoverable.
Re: Atomic signal flags for vi(1)
I'll see if I can fit this one in in the next few days.
Feel free to remind me :-)
martijn@
On Sun, 2021-08-29 at 02:54 -0600, Theo de Raadt wrote:
> This does look better.
>
> I appreciate that you are fixing this underlying problem first, before
> overlaying your timer diff.
>
> Is this working for the vi crowd?
>
>
> trondd wrote:
>
> > "Theo de Raadt" wrote:
> >
> > > +h_alrm(int signo)
> > > +{
> > > + GLOBAL_CLP;
> > > +
> > > + F_SET(clp, CL_SIGALRM);
> > >
> > > F_SET is |=, which is not atomic.
> > >
> > > This is unsafe. Safe signal handlers need to make single stores to
> > > atomic-sized variables, which tend to be int-sized, easier to declare
> > > as sig_atomic_t. Most often these are global scope with the following
> > > type:
> > >
> > > volatile sig_atomic_t variable
> > >
> > > I can see you copied an existing practice. Sadly all the other
> > > signal handlers are also broken in the same way.
> > >
> > > The flag bits should be replaced with seperate sig_atomic_t variables.
> >
> > Ok. Took a swing at converting the signal handling to sig_atomic_t flags.
> > No additional changes added other than removing a redundant check of the
> > flags in cl_read.c. Seemed to be a pretty straight-forward conversion and
> > I haven't found any change in behavior.
> >
> > Tim.
> >
> >
> > Index: cl/cl.h
> > ===
> > RCS file: /cvs/src/usr.bin/vi/cl/cl.h,v
> > retrieving revision 1.10
> > diff -u -p -r1.10 cl.h
> > --- cl/cl.h 27 May 2016 09:18:11 - 1.10
> > +++ cl/cl.h 24 Aug 2021 23:34:27 -
> > @@ -11,6 +11,11 @@
> > * @(#)cl.h10.19 (Berkeley) 9/24/96
> > */
> >
> > +extern volatile sig_atomic_t cl_sighup;
> > +extern volatile sig_atomic_t cl_sigint;
> > +extern volatile sig_atomic_t cl_sigterm;
> > +extern volatile sig_atomic_t cl_sigwinch;
> > +
> > typedef struct _cl_private {
> > CHAR_T ibuf[256]; /* Input keys. */
> >
> > @@ -45,11 +50,7 @@ typedef struct _cl_private {
> > #defineCL_RENAME_OK0x0004 /* User wants the windows renamed. */
> > #defineCL_SCR_EX_INIT 0x0008 /* Ex screen initialized. */
> > #defineCL_SCR_VI_INIT 0x0010 /* Vi screen initialized. */
> > -#defineCL_SIGHUP 0x0020 /* SIGHUP arrived. */
> > -#defineCL_SIGINT 0x0040 /* SIGINT arrived. */
> > -#defineCL_SIGTERM 0x0080 /* SIGTERM arrived. */
> > -#defineCL_SIGWINCH 0x0100 /* SIGWINCH arrived. */
> > -#defineCL_STDIN_TTY0x0200 /* Talking to a terminal. */
> > +#defineCL_STDIN_TTY0x0020 /* Talking to a terminal. */
> > u_int32_t flags;
> > } CL_PRIVATE;
> >
> > Index: cl/cl_funcs.c
> > ===
> > RCS file: /cvs/src/usr.bin/vi/cl/cl_funcs.c,v
> > retrieving revision 1.20
> > diff -u -p -r1.20 cl_funcs.c
> > --- cl/cl_funcs.c 27 May 2016 09:18:11 - 1.20
> > +++ cl/cl_funcs.c 24 Aug 2021 23:34:27 -
> > @@ -601,7 +601,7 @@ cl_suspend(SCR *sp, int *allowedp)
> > if (cl_ssize(sp, 1, NULL, NULL, ))
> > return (1);
> > if (changed)
> > - F_SET(CLP(sp), CL_SIGWINCH);
> > + cl_sigwinch = 1;
> >
> > return (0);
> > }
> > Index: cl/cl_main.c
> > ===
> > RCS file: /cvs/src/usr.bin/vi/cl/cl_main.c,v
> > retrieving revision 1.33
> > diff -u -p -r1.33 cl_main.c
> > --- cl/cl_main.c5 May 2016 20:36:41 - 1.33
> > +++ cl/cl_main.c24 Aug 2021 23:34:27 -
> > @@ -33,6 +33,11 @@
> >
> > GS *__global_list; /* GLOBAL: List of screens. */
> >
> > +volatile sig_atomic_t cl_sighup;
> > +volatile sig_atomic_t cl_sigint;
> > +volatile sig_atomic_t cl_sigterm;
> > +volatile sig_atomic_t cl_sigwinch;
> > +
> > static void cl_func_std(GS *);
> > static CL_PRIVATE *cl_init(GS *);
> > static GS*gs_init(void);
> > @@ -217,16 +222,14 @@ h_hup(int signo)
> > {
> > GLOBAL_CLP;
> >
> > - F_SET(clp, CL_SIGHUP);
> > + cl_sighup = 1;
> > clp->killersig = SIGHUP;
> > }
> >
> > static void
> > h_int(int signo)
> > {
> > - GLOBAL_CLP;
> > -
> > - F_SET(clp, CL_SIGINT);
> > + cl_sigint = 1;
> > }
> >
> > static void
> > @@ -234,16 +237,14 @@ h_term(int signo)
> > {
> > GLOBAL_CLP;
> >
> > - F_SET(clp, CL_SIGTERM);
> > + cl_sigterm = 1;
> > clp->killersig = SIGTERM;
> > }
> >
> > static void
> > h_winch(int signo)
> > {
> > - GLOBAL_CLP;
> > -
> > - F_SET(clp, CL_SIGWINCH);
> > + cl_sigwinch = 1;
> > }
> > #undef GLOBAL_CLP
> >
> > @@ -259,6 +260,11 @@ sig_init(GS *gp, SCR *sp)
> > CL_PRIVATE *clp;
> >
> > clp = GCLP(gp);
> > +
> > + cl_sighup = 0;
> > + cl_sigint = 0;
> > + cl_sigterm = 0;
> > + cl_sigwinch = 0;
> >
> > if (sp == NULL) {
> > if (setsig(SIGHUP, >oact[INDX_HUP],
Re: allow KARL with config(8)'d kernels
Hi,
Theo de Raadt wrote on Sun, Aug 29, 2021 at 07:15:34AM -0600:
> I am not thrilled with the name "kernel.conf".
> It does not seem intuitively discoverable.
What would be a canonical name?
It is a command file for config(8).
Note that the "config-file" for config is something else, and that
other thing is also called a "kernel configuration file", and it
is located in places like /sys/arch/luna88k/conf/GENERIC iiuc.
For command files, we normally use the name of the programming
language as a suffix (*.sh, *.pl, *.py, *.awk, *.sed, ...). But
here, the domain specific language is really config(8), and *.config
does not work as a suffix because it is next to indistinguishable
from *.conf, and we just saw this is *not* a configuration but a
command file.
The root cause of the terminologic mess here is that the choice of
the name config(8) for the kernel configuration program was too
generic in the first place, but we are almost exactly 40 years late
for fixing that.
One - admittedly completely unUNIXy - way would be to invent a long,
descriptive name like /etc/kernel.config.commands or even /bsd.config.cmd
in the root rather than the /etc directory, which is more discoverable
because it is right next to the kernel itself. The UNIXy way
is not necessarily better: Ken would have invented a very short,
pronouncable name that is not an English word but similar to one,
like /etc/sycoc (for SYstem COnfiguration Commands).
Is /bsd.config.cmd good enough?
Yours,
Ingo
> Paul de Weerd wrote:
>> Index: distrib/miniroot/install.sub
[...]
>> chroot /mnt /bin/ksh -e -c "cd ${_kernel_dir#/mnt}/$_kernel; \
>> -make newbsd; make newinstall"
>> +make newbsd; \
>> +[ -e /etc/kernel.conf ] && \
>> +config -e -c /etc/kernel.conf -f bsd; \
>> +make newinstall"
>> ) >/dev/null 2>&1 && echo " done." || echo " failed."
Re: netstart debugging
On Sun, Aug 29, 2021 at 03:24:26PM +0200, Alexander Bluhm wrote: > Not much feedback for my netstart rdomain diff. So let's split it > up and improve dubgging first. > > - enable debugging in ifcreate > - add debugging output for ipv6 routes > - make locahost and multicast code aware of print only > - allow netstart -n also if no interface is given OK kn
Re: allow KARL with config(8)'d kernels
man -k kernel, and man -k ukc, both suggest these are poor names
for different reasons.
maybe if you write some diffs to hint at the existance of this mechanism
in the config(8) and boot_config(8) manual pages, a better name will
sneak up on us.
Paul de Weerd wrote:
> Hi Theo,
>
> That's a good point, but I have no better alternative. kernel.conf
> was the best I could come up with, as it is a configuration file for
> the (installed) kernel. I briefly considered:
>
> - config.conf (after config(8), but seems hilariously worse to me)
> - ukc.conf (has similar (perhaps even stronger) issues as kernel.conf)
>
> Do others have a good suggestion for the color of this particular bike
> shed? Open to suggestions!
>
> Paul
>
> On Sun, Aug 29, 2021 at 07:15:34AM -0600, Theo de Raadt wrote:
> | I am not thrilled with the name "kernel.conf".
> |
> | It does not seem intuitively discoverable.
> |
> | Paul de Weerd wrote:
> |
> | > Got some more positive feedback off-list, which reminded me that
> | > there's a small piece missing:
> | >
> | > Index: changelist
> | > ===
> | > RCS file: /home/OpenBSD/cvs/src/etc/changelist,v
> | > retrieving revision 1.128
> | > diff -u -p -r1.128 changelist
> | > --- changelist30 Jul 2021 07:00:02 - 1.128
> | > +++ changelist29 Aug 2021 12:12:04 -
> | > @@ -56,6 +56,7 @@
> | > +/etc/isakmpd/isakmpd.policy
> | > /etc/isakmpd/local.pub
> | > +/etc/isakmpd/private/local.key
> | > +/etc/kernel.conf
> | > /etc/ksh.kshrc
> | > /etc/ldapd.conf
> | > /etc/ldpd.conf
> | >
> | > Full diff (including the original diff, the diff to install.sub and
> | > the above changelist diff) below. Anything else I overlooked?
> | >
> | > Paul
> | >
> | > Index: distrib/miniroot/install.sub
> | > ===
> | > RCS file: /home/OpenBSD/cvs/src/distrib/miniroot/install.sub,v
> | > retrieving revision 1.1172
> | > diff -u -p -r1.1172 install.sub
> | > --- distrib/miniroot/install.sub 9 Aug 2021 13:56:17 - 1.1172
> | > +++ distrib/miniroot/install.sub 25 Aug 2021 19:42:49 -
> | > @@ -2857,7 +2857,10 @@ finish_up() {
> | > tar -C $_kernel_dir -xzf $_kernel_dir.tgz $_kernel
> | > rm -f $_kernel_dir.tgz
> | > chroot /mnt /bin/ksh -e -c "cd ${_kernel_dir#/mnt}/$_kernel; \
> | > - make newbsd; make newinstall"
> | > + make newbsd; \
> | > + [ -e /etc/kernel.conf ] && \
> | > + config -e -c /etc/kernel.conf -f bsd; \
> | > + make newinstall"
> | > ) >/dev/null 2>&1 && echo " done." || echo " failed."
> | > fi
> | >
> | > Index: etc/changelist
> | > ===
> | > RCS file: /home/OpenBSD/cvs/src/etc/changelist,v
> | > retrieving revision 1.128
> | > diff -u -p -r1.128 changelist
> | > --- etc/changelist30 Jul 2021 07:00:02 - 1.128
> | > +++ etc/changelist29 Aug 2021 12:12:04 -
> | > @@ -56,6 +56,7 @@
> | > +/etc/isakmpd/isakmpd.policy
> | > /etc/isakmpd/local.pub
> | > +/etc/isakmpd/private/local.key
> | > +/etc/kernel.conf
> | > /etc/ksh.kshrc
> | > /etc/ldapd.conf
> | > /etc/ldpd.conf
> | > Index: libexec/reorder_kernel/Makefile
> | > ===
> | > RCS file: /home/OpenBSD/cvs/src/libexec/reorder_kernel/Makefile,v
> | > retrieving revision 1.1
> | > diff -u -p -r1.1 Makefile
> | > --- libexec/reorder_kernel/Makefile 21 Aug 2017 21:24:11 -
> 1.1
> | > +++ libexec/reorder_kernel/Makefile 24 Aug 2021 07:23:38 -
> | > @@ -1,6 +1,7 @@
> | > #$OpenBSD: Makefile,v 1.1 2017/08/21 21:24:11 rpe Exp $
> | >
> | > SCRIPT= reorder_kernel.sh
> | > +MAN= kernel.conf.5
> | >
> | > realinstall:
> | > ${INSTALL} ${INSTALL_COPY} -o ${BINOWN} -g ${BINGRP} -m ${BINMODE} \
> | > Index: libexec/reorder_kernel/kernel.conf.5
> | > ===
> | > RCS file: libexec/reorder_kernel/kernel.conf.5
> | > diff -N libexec/reorder_kernel/kernel.conf.5
> | > --- /dev/null 1 Jan 1970 00:00:00 -
> | > +++ libexec/reorder_kernel/kernel.conf.5 24 Aug 2021 07:23:07 -
> | > @@ -0,0 +1,46 @@
> | > +.\" $OpenBSD$
> | > +.\"
> | > +.\" Copyright (c) 2021 Paul de Weerd
> | > +.\"
> | > +.\" Permission to use, copy, modify, and distribute this software for any
> | > +.\" purpose with or without fee is hereby granted, provided that the
> above
> | > +.\" copyright notice and this permission notice appear in all copies.
> | > +.\"
> | > +.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL
> WARRANTIES
> | > +.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> | > +.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE
> FOR
> | >
Re: netstart debugging
On Wed, Aug 18, 2021 at 04:28:13PM +0200, Alexander Bluhm wrote:
> Also more debug output for /etc/netstart -n is necessary to understand
> what is going on.
Not much feedback for my netstart rdomain diff. So let's split it
up and improve dubgging first.
- enable debugging in ifcreate
- add debugging output for ipv6 routes
- make locahost and multicast code aware of print only
- allow netstart -n also if no interface is given
ok?
bluhm
Index: netstart
===
RCS file: /data/mirror/openbsd/cvs/src/etc/netstart,v
retrieving revision 1.214
diff -u -p -r1.214 netstart
--- netstart6 Aug 2021 07:06:35 - 1.214
+++ netstart29 Aug 2021 12:06:20 -
@@ -86,7 +86,11 @@ parse_hn_line() {
ifcreate() {
local _if=$1
- { ifconfig $_if || ifconfig $_if create; } >/dev/null 2>&1
+ if $PRINT_ONLY; then
+ print -r -- "{ ifconfig $_if || ifconfig $_if create; }"
+ else
+ { ifconfig $_if || ifconfig $_if create; } >/dev/null 2>&1
+ fi
}
# Create interfaces for network pseudo-devices referred to by hostname.if
files.
@@ -130,9 +134,7 @@ ifstart() {
fi
# Check for ifconfig'able interface, except if -n option is specified.
- if ! $PRINT_ONLY; then
- ifcreate $_if || return
- fi
+ ifcreate $_if || return
# Parse the hostname.if(5) file and fill _cmds array with interface
# configuration commands.
@@ -210,6 +212,63 @@ defaultroute() {
set +o noglob
}
+# add all the routes needed for IPv6
+ip6routes() {
+ local _i=0
+ set -A _cmds
+
+ # Disallow link-local unicast dest without outgoing scope identifiers.
+ _cmds[_i++]="route -qn add -inet6 fe80:: -prefixlen 10 ::1 -reject"
+
+ # Disallow site-local unicast dest without outgoing scope identifiers.
+ # If you configure site-locals without scope id (it is permissible
+ # config for routers that are not on scope boundary), you may want
+ # to comment the line out.
+ _cmds[_i++]="route -qn add -inet6 fec0:: -prefixlen 10 ::1 -reject"
+
+ # Disallow "internal" addresses to appear on the wire.
+ _cmds[_i++]="route -qn add -inet6 :::0.0.0.0 -prefixlen 96 ::1
-reject"
+
+ # Disallow packets to malicious 6to4 prefix.
+ _cmds[_i++]="route -qn add -inet6 2002:e000:: -prefixlen 20 ::1 -reject"
+ _cmds[_i++]="route -qn add -inet6 2002:7f00:: -prefixlen 24 ::1 -reject"
+ _cmds[_i++]="route -qn add -inet6 2002::: -prefixlen 24 ::1 -reject"
+ _cmds[_i++]="route -qn add -inet6 2002:ff00:: -prefixlen 24 ::1 -reject"
+
+ # Disallow packets without scope identifier.
+ _cmds[_i++]="route -qn add -inet6 ff01:: -prefixlen 16 ::1 -reject"
+ _cmds[_i++]="route -qn add -inet6 ff02:: -prefixlen 16 ::1 -reject"
+
+ # Completely disallow packets to IPv4 compatible prefix.
+ #
+ # This may conflict with RFC1933 under following circumstances:
+ # (1) An IPv6-only KAME node tries to originate packets to IPv4
+ # compatible destination. The KAME node has no IPv4 compatible
+ # support. Under RFC1933, it should transmit native IPv6
+ # packets toward IPv4 compatible destination, hoping it would
+ # reach a router that forwards the packet toward auto-tunnel
+ # interface.
+ # (2) An IPv6-only node originates a packet to an IPv4 compatible
+ # destination. A KAME node is acting as an IPv6 router, and
+ # asked to forward it.
+ #
+ # Due to rare use of IPv4 compatible addresses, and security issues
+ # with it, we disable it by default.
+ _cmds[_i++]="route -qn add -inet6 ::0.0.0.0 -prefixlen 96 ::1 -reject"
+
+ # Apply the interface configuration commands stored in _cmds array.
+ _i=0
+ while ((_i < ${#_cmds[*]})); do
+ if $PRINT_ONLY; then
+ print -r -- "${_cmds[_i]}"
+ else
+ eval "${_cmds[_i]}"
+ fi
+ ((_i++))
+ done
+ unset _cmds
+}
+
# Make sure the invoking user has the right privileges. Check for presence of
# id(1) to avoid problems with diskless setups.
if [[ -x /usr/bin/id ]] && (($(id -u) != 0)); then
@@ -233,9 +292,6 @@ while getopts ":n" opt; do
done
shift $((OPTIND-1))
-# Option -n is only supported if interface names are specified as parameters.
-$PRINT_ONLY && (($# == 0)) && usage
-
# Load key material for the generation of IPv6 Semantically Opaque Interface
# Identifiers (SOII) used for link local and SLAAC addresses.
$PRINT_ONLY || [[ ! -f /etc/soii.key ]] ||
@@ -253,50 +309,16 @@ fi
# Set the address for the loopback interface. Bringing the interface up,
# automatically invokes the IPv6 address ::1.
-ifconfig lo0 inet 127.0.0.1/8
+if $PRINT_ONLY; then
+ print -r -- "ifconfig
Re: allow KARL with config(8)'d kernels
Hi Theo,
That's a good point, but I have no better alternative. kernel.conf
was the best I could come up with, as it is a configuration file for
the (installed) kernel. I briefly considered:
- config.conf (after config(8), but seems hilariously worse to me)
- ukc.conf (has similar (perhaps even stronger) issues as kernel.conf)
Do others have a good suggestion for the color of this particular bike
shed? Open to suggestions!
Paul
On Sun, Aug 29, 2021 at 07:15:34AM -0600, Theo de Raadt wrote:
| I am not thrilled with the name "kernel.conf".
|
| It does not seem intuitively discoverable.
|
| Paul de Weerd wrote:
|
| > Got some more positive feedback off-list, which reminded me that
| > there's a small piece missing:
| >
| > Index: changelist
| > ===
| > RCS file: /home/OpenBSD/cvs/src/etc/changelist,v
| > retrieving revision 1.128
| > diff -u -p -r1.128 changelist
| > --- changelist 30 Jul 2021 07:00:02 - 1.128
| > +++ changelist 29 Aug 2021 12:12:04 -
| > @@ -56,6 +56,7 @@
| > +/etc/isakmpd/isakmpd.policy
| > /etc/isakmpd/local.pub
| > +/etc/isakmpd/private/local.key
| > +/etc/kernel.conf
| > /etc/ksh.kshrc
| > /etc/ldapd.conf
| > /etc/ldpd.conf
| >
| > Full diff (including the original diff, the diff to install.sub and
| > the above changelist diff) below. Anything else I overlooked?
| >
| > Paul
| >
| > Index: distrib/miniroot/install.sub
| > ===
| > RCS file: /home/OpenBSD/cvs/src/distrib/miniroot/install.sub,v
| > retrieving revision 1.1172
| > diff -u -p -r1.1172 install.sub
| > --- distrib/miniroot/install.sub9 Aug 2021 13:56:17 - 1.1172
| > +++ distrib/miniroot/install.sub25 Aug 2021 19:42:49 -
| > @@ -2857,7 +2857,10 @@ finish_up() {
| > tar -C $_kernel_dir -xzf $_kernel_dir.tgz $_kernel
| > rm -f $_kernel_dir.tgz
| > chroot /mnt /bin/ksh -e -c "cd ${_kernel_dir#/mnt}/$_kernel; \
| > - make newbsd; make newinstall"
| > + make newbsd; \
| > + [ -e /etc/kernel.conf ] && \
| > + config -e -c /etc/kernel.conf -f bsd; \
| > + make newinstall"
| > ) >/dev/null 2>&1 && echo " done." || echo " failed."
| > fi
| >
| > Index: etc/changelist
| > ===
| > RCS file: /home/OpenBSD/cvs/src/etc/changelist,v
| > retrieving revision 1.128
| > diff -u -p -r1.128 changelist
| > --- etc/changelist 30 Jul 2021 07:00:02 - 1.128
| > +++ etc/changelist 29 Aug 2021 12:12:04 -
| > @@ -56,6 +56,7 @@
| > +/etc/isakmpd/isakmpd.policy
| > /etc/isakmpd/local.pub
| > +/etc/isakmpd/private/local.key
| > +/etc/kernel.conf
| > /etc/ksh.kshrc
| > /etc/ldapd.conf
| > /etc/ldpd.conf
| > Index: libexec/reorder_kernel/Makefile
| > ===
| > RCS file: /home/OpenBSD/cvs/src/libexec/reorder_kernel/Makefile,v
| > retrieving revision 1.1
| > diff -u -p -r1.1 Makefile
| > --- libexec/reorder_kernel/Makefile 21 Aug 2017 21:24:11 - 1.1
| > +++ libexec/reorder_kernel/Makefile 24 Aug 2021 07:23:38 -
| > @@ -1,6 +1,7 @@
| > # $OpenBSD: Makefile,v 1.1 2017/08/21 21:24:11 rpe Exp $
| >
| > SCRIPT=reorder_kernel.sh
| > +MAN= kernel.conf.5
| >
| > realinstall:
| > ${INSTALL} ${INSTALL_COPY} -o ${BINOWN} -g ${BINGRP} -m ${BINMODE} \
| > Index: libexec/reorder_kernel/kernel.conf.5
| > ===
| > RCS file: libexec/reorder_kernel/kernel.conf.5
| > diff -N libexec/reorder_kernel/kernel.conf.5
| > --- /dev/null 1 Jan 1970 00:00:00 -
| > +++ libexec/reorder_kernel/kernel.conf.524 Aug 2021 07:23:07 -
| > @@ -0,0 +1,46 @@
| > +.\"$OpenBSD$
| > +.\"
| > +.\" Copyright (c) 2021 Paul de Weerd
| > +.\"
| > +.\" Permission to use, copy, modify, and distribute this software for any
| > +.\" purpose with or without fee is hereby granted, provided that the above
| > +.\" copyright notice and this permission notice appear in all copies.
| > +.\"
| > +.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL
WARRANTIES
| > +.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
| > +.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
| > +.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
| > +.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
| > +.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
| > +.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
| > +.\"
| > +.Dd $Mdocdate: August 24 2021 $
| > +.Dt KERNEL.CONF 5
| > +.Os
| > +.Sh NAME
| > +.Nm kernel.conf
| > +.Nd kernel configuration file
| > +.Sh DESCRIPTION
| > +The
| > +.Nm
| >
Re: DANE in libressl?
Is there a strong reason why this has to be in that specific library? Peter J. Philipp wrote: > Hi, > > I was wondering if anyone has wanted to implement DANE functions into OpenBSD? > And LibreSSL perhaps? I want this for syslogd with TLS, but not sure if I'd > be on someones toes here, if I start implementing... > > With unwind we can make use of things such as DANE due to validation of > DNSSEC. > > Best Regards, > -peter >
Re: allow KARL with config(8)'d kernels
I am not thrilled with the name "kernel.conf".
It does not seem intuitively discoverable.
Paul de Weerd wrote:
> Got some more positive feedback off-list, which reminded me that
> there's a small piece missing:
>
> Index: changelist
> ===
> RCS file: /home/OpenBSD/cvs/src/etc/changelist,v
> retrieving revision 1.128
> diff -u -p -r1.128 changelist
> --- changelist30 Jul 2021 07:00:02 - 1.128
> +++ changelist29 Aug 2021 12:12:04 -
> @@ -56,6 +56,7 @@
> +/etc/isakmpd/isakmpd.policy
> /etc/isakmpd/local.pub
> +/etc/isakmpd/private/local.key
> +/etc/kernel.conf
> /etc/ksh.kshrc
> /etc/ldapd.conf
> /etc/ldpd.conf
>
> Full diff (including the original diff, the diff to install.sub and
> the above changelist diff) below. Anything else I overlooked?
>
> Paul
>
> Index: distrib/miniroot/install.sub
> ===
> RCS file: /home/OpenBSD/cvs/src/distrib/miniroot/install.sub,v
> retrieving revision 1.1172
> diff -u -p -r1.1172 install.sub
> --- distrib/miniroot/install.sub 9 Aug 2021 13:56:17 - 1.1172
> +++ distrib/miniroot/install.sub 25 Aug 2021 19:42:49 -
> @@ -2857,7 +2857,10 @@ finish_up() {
> tar -C $_kernel_dir -xzf $_kernel_dir.tgz $_kernel
> rm -f $_kernel_dir.tgz
> chroot /mnt /bin/ksh -e -c "cd ${_kernel_dir#/mnt}/$_kernel; \
> - make newbsd; make newinstall"
> + make newbsd; \
> + [ -e /etc/kernel.conf ] && \
> + config -e -c /etc/kernel.conf -f bsd; \
> + make newinstall"
> ) >/dev/null 2>&1 && echo " done." || echo " failed."
> fi
>
> Index: etc/changelist
> ===
> RCS file: /home/OpenBSD/cvs/src/etc/changelist,v
> retrieving revision 1.128
> diff -u -p -r1.128 changelist
> --- etc/changelist30 Jul 2021 07:00:02 - 1.128
> +++ etc/changelist29 Aug 2021 12:12:04 -
> @@ -56,6 +56,7 @@
> +/etc/isakmpd/isakmpd.policy
> /etc/isakmpd/local.pub
> +/etc/isakmpd/private/local.key
> +/etc/kernel.conf
> /etc/ksh.kshrc
> /etc/ldapd.conf
> /etc/ldpd.conf
> Index: libexec/reorder_kernel/Makefile
> ===
> RCS file: /home/OpenBSD/cvs/src/libexec/reorder_kernel/Makefile,v
> retrieving revision 1.1
> diff -u -p -r1.1 Makefile
> --- libexec/reorder_kernel/Makefile 21 Aug 2017 21:24:11 - 1.1
> +++ libexec/reorder_kernel/Makefile 24 Aug 2021 07:23:38 -
> @@ -1,6 +1,7 @@
> #$OpenBSD: Makefile,v 1.1 2017/08/21 21:24:11 rpe Exp $
>
> SCRIPT= reorder_kernel.sh
> +MAN= kernel.conf.5
>
> realinstall:
> ${INSTALL} ${INSTALL_COPY} -o ${BINOWN} -g ${BINGRP} -m ${BINMODE} \
> Index: libexec/reorder_kernel/kernel.conf.5
> ===
> RCS file: libexec/reorder_kernel/kernel.conf.5
> diff -N libexec/reorder_kernel/kernel.conf.5
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ libexec/reorder_kernel/kernel.conf.5 24 Aug 2021 07:23:07 -
> @@ -0,0 +1,46 @@
> +.\" $OpenBSD$
> +.\"
> +.\" Copyright (c) 2021 Paul de Weerd
> +.\"
> +.\" Permission to use, copy, modify, and distribute this software for any
> +.\" purpose with or without fee is hereby granted, provided that the above
> +.\" copyright notice and this permission notice appear in all copies.
> +.\"
> +.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
> +.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> +.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
> +.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> +.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> +.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> +.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> +.\"
> +.Dd $Mdocdate: August 24 2021 $
> +.Dt KERNEL.CONF 5
> +.Os
> +.Sh NAME
> +.Nm kernel.conf
> +.Nd kernel configuration file
> +.Sh DESCRIPTION
> +The
> +.Nm
> +file contains configuration information for the kernel.
> +If present, it is used during system startup to configure the kernel
> +that will be running at the next boot.
> +It can be used to enable or disable specific devices in the kernel.
> +.Sh EXAMPLES
> +To enable the
> +.Xr ipmi 4
> +driver, add the following line to
> +.Nm :
> +.Pp
> +.Dl enable ipmi
> +.Pp
> +See
> +.Xr config 8
> +for more details on how to configure the kernel.
> +.Sh FILES
> +.Bl -tag -width /etc/kernel.conf -compact
> +.It Pa /etc/kernel.conf
> +Kernel configuration file.
> +.Sh SEE ALSO
> +.Xr config 8
> Index: libexec/reorder_kernel/reorder_kernel.sh
>
Re: openssl(1): implement naccept
This builds fine and works good.
ok inoguchi@
I have one comment additionally what jmc@ mentioned.
On Sun, Aug 29, 2021 at 01:10:56PM +0100, Jason McIntyre wrote:
> On Sun, Aug 29, 2021 at 02:00:44PM +0200, Theo Buehler wrote:
> > Terminate the s_server after n clients connected to it. This is
> > occasionally useful, matches OpenSSL's behavior and should help
> > simplifying regress/usr.bin/openssl/x509.
> >
>
> hi.
>
> > Index: openssl.1
> > ===
> > RCS file: /cvs/src/usr.bin/openssl/openssl.1,v
> > retrieving revision 1.129
> > diff -u -p -r1.129 openssl.1
> > --- openssl.1 17 Mar 2021 18:08:32 - 1.129
> > +++ openssl.1 28 Aug 2021 17:12:59 -
> > @@ -4607,6 +4607,7 @@ will be used.
> > .Op Fl keymatexportlen Ar len
> > .Op Fl msg
> > .Op Fl mtu Ar mtu
> > +.Op Fl naccept Ar arg
>
> i guess "arg" should be "num".
> also i think it needs to be added to sv_usage in s_server.c.
>
> otherwise doc parts ok.
>
> jmc
>
> > .Op Fl named_curve Ar arg
> > .Op Fl nbio
> > .Op Fl nbio_test
> > @@ -4807,6 +4808,10 @@ Export len bytes of keying material (def
> > Show all protocol messages with hex dump.
> > .It Fl mtu Ar mtu
> > Set the link layer MTU.
> > +.It Fl naccept Ar num
> > +Terminate server after
> > +.Ar num
> > +connections.
> > .It Fl named_curve Ar arg
> > Specify the elliptic curve name to use for ephemeral ECDH keys.
> > This option is deprecated; use
> > Index: s_apps.h
> > ===
> > RCS file: /cvs/src/usr.bin/openssl/s_apps.h,v
> > retrieving revision 1.5
> > diff -u -p -r1.5 s_apps.h
> > --- s_apps.h25 Apr 2018 07:12:33 - 1.5
> > +++ s_apps.h28 Aug 2021 17:12:59 -
> > @@ -120,7 +120,7 @@ extern int verify_return_error;
> >
> > int do_server(int port, int type, int *ret,
> > int (*cb)(char *hostname, int s, unsigned char *context),
> > -unsigned char *context);
> > +unsigned char *context, int naccept);
> > #ifdef HEADER_X509_H
> > int verify_callback(int ok, X509_STORE_CTX *ctx);
> > #endif
> > Index: s_server.c
> > ===
> > RCS file: /cvs/src/usr.bin/openssl/s_server.c,v
> > retrieving revision 1.47
> > diff -u -p -r1.47 s_server.c
> > --- s_server.c 17 Mar 2021 18:11:01 - 1.47
> > +++ s_server.c 28 Aug 2021 17:17:38 -
> > @@ -267,6 +267,7 @@ static struct {
> > uint16_t min_version;
> > const SSL_METHOD *meth;
> > int msg;
> > + int naccept;
> > char *named_curve;
> > int nbio;
> > int nbio_test;
> > @@ -741,6 +742,13 @@ static const struct option s_server_opti
> > },
> > #endif
> > {
> > + .name = "naccept",
> > + .argname = "num",
> > + .desc = "terminate after num connections",
Other .desc begins with capital letter, so "Terminate" would be better.
> > + .type = OPTION_ARG_INT,
> > + .opt.value = _server_config.naccept
> > + },
> > + {
> > .name = "named_curve",
> > .argname = "arg",
> > .type = OPTION_ARG,
> > @@ -1084,6 +1092,7 @@ s_server_main(int argc, char *argv[])
> > memset(_server_config, 0, sizeof(s_server_config));
> > s_server_config.keymatexportlen = 20;
> > s_server_config.meth = TLS_server_method();
> > + s_server_config.naccept = -1;
> > s_server_config.port = PORT;
> > s_server_config.cert_file = TEST_CERT;
> > s_server_config.cert_file2 = TEST_CERT2;
> > @@ -1465,10 +1474,12 @@ s_server_main(int argc, char *argv[])
> > (void) BIO_flush(bio_s_out);
> > if (s_server_config.www)
> > do_server(s_server_config.port, s_server_config.socket_type,
> > - _socket, www_body, s_server_config.context);
> > + _socket, www_body, s_server_config.context,
> > + s_server_config.naccept);
> > else
> > do_server(s_server_config.port, s_server_config.socket_type,
> > - _socket, sv_body, s_server_config.context);
> > + _socket, sv_body, s_server_config.context,
> > + s_server_config.naccept);
> > print_stats(bio_s_out, ctx);
> > ret = 0;
> > end:
> > Index: s_socket.c
> > ===
> > RCS file: /cvs/src/usr.bin/openssl/s_socket.c,v
> > retrieving revision 1.11
> > diff -u -p -r1.11 s_socket.c
> > --- s_socket.c 28 Jun 2019 13:35:02 - 1.11
> > +++ s_socket.c 28 Aug 2021 17:12:59 -
> > @@ -132,7 +132,7 @@ init_client(int *sock, char *host, char
> > int
> > do_server(int port, int type, int *ret,
> > int (*cb) (char *hostname, int s, unsigned char *context),
> > -unsigned char *context)
> > +unsigned char *context, int naccept)
> > {
> > int sock;
> > char *name = NULL;
> > @@ -161,7 +161,9 @@ do_server(int port, int
Re: allow KARL with config(8)'d kernels
Got some more positive feedback off-list, which reminded me that
there's a small piece missing:
Index: changelist
===
RCS file: /home/OpenBSD/cvs/src/etc/changelist,v
retrieving revision 1.128
diff -u -p -r1.128 changelist
--- changelist 30 Jul 2021 07:00:02 - 1.128
+++ changelist 29 Aug 2021 12:12:04 -
@@ -56,6 +56,7 @@
+/etc/isakmpd/isakmpd.policy
/etc/isakmpd/local.pub
+/etc/isakmpd/private/local.key
+/etc/kernel.conf
/etc/ksh.kshrc
/etc/ldapd.conf
/etc/ldpd.conf
Full diff (including the original diff, the diff to install.sub and
the above changelist diff) below. Anything else I overlooked?
Paul
Index: distrib/miniroot/install.sub
===
RCS file: /home/OpenBSD/cvs/src/distrib/miniroot/install.sub,v
retrieving revision 1.1172
diff -u -p -r1.1172 install.sub
--- distrib/miniroot/install.sub9 Aug 2021 13:56:17 - 1.1172
+++ distrib/miniroot/install.sub25 Aug 2021 19:42:49 -
@@ -2857,7 +2857,10 @@ finish_up() {
tar -C $_kernel_dir -xzf $_kernel_dir.tgz $_kernel
rm -f $_kernel_dir.tgz
chroot /mnt /bin/ksh -e -c "cd ${_kernel_dir#/mnt}/$_kernel; \
- make newbsd; make newinstall"
+ make newbsd; \
+ [ -e /etc/kernel.conf ] && \
+ config -e -c /etc/kernel.conf -f bsd; \
+ make newinstall"
) >/dev/null 2>&1 && echo " done." || echo " failed."
fi
Index: etc/changelist
===
RCS file: /home/OpenBSD/cvs/src/etc/changelist,v
retrieving revision 1.128
diff -u -p -r1.128 changelist
--- etc/changelist 30 Jul 2021 07:00:02 - 1.128
+++ etc/changelist 29 Aug 2021 12:12:04 -
@@ -56,6 +56,7 @@
+/etc/isakmpd/isakmpd.policy
/etc/isakmpd/local.pub
+/etc/isakmpd/private/local.key
+/etc/kernel.conf
/etc/ksh.kshrc
/etc/ldapd.conf
/etc/ldpd.conf
Index: libexec/reorder_kernel/Makefile
===
RCS file: /home/OpenBSD/cvs/src/libexec/reorder_kernel/Makefile,v
retrieving revision 1.1
diff -u -p -r1.1 Makefile
--- libexec/reorder_kernel/Makefile 21 Aug 2017 21:24:11 - 1.1
+++ libexec/reorder_kernel/Makefile 24 Aug 2021 07:23:38 -
@@ -1,6 +1,7 @@
# $OpenBSD: Makefile,v 1.1 2017/08/21 21:24:11 rpe Exp $
SCRIPT=reorder_kernel.sh
+MAN= kernel.conf.5
realinstall:
${INSTALL} ${INSTALL_COPY} -o ${BINOWN} -g ${BINGRP} -m ${BINMODE} \
Index: libexec/reorder_kernel/kernel.conf.5
===
RCS file: libexec/reorder_kernel/kernel.conf.5
diff -N libexec/reorder_kernel/kernel.conf.5
--- /dev/null 1 Jan 1970 00:00:00 -
+++ libexec/reorder_kernel/kernel.conf.524 Aug 2021 07:23:07 -
@@ -0,0 +1,46 @@
+.\"$OpenBSD$
+.\"
+.\" Copyright (c) 2021 Paul de Weerd
+.\"
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" purpose with or without fee is hereby granted, provided that the above
+.\" copyright notice and this permission notice appear in all copies.
+.\"
+.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+.\"
+.Dd $Mdocdate: August 24 2021 $
+.Dt KERNEL.CONF 5
+.Os
+.Sh NAME
+.Nm kernel.conf
+.Nd kernel configuration file
+.Sh DESCRIPTION
+The
+.Nm
+file contains configuration information for the kernel.
+If present, it is used during system startup to configure the kernel
+that will be running at the next boot.
+It can be used to enable or disable specific devices in the kernel.
+.Sh EXAMPLES
+To enable the
+.Xr ipmi 4
+driver, add the following line to
+.Nm :
+.Pp
+.Dl enable ipmi
+.Pp
+See
+.Xr config 8
+for more details on how to configure the kernel.
+.Sh FILES
+.Bl -tag -width /etc/kernel.conf -compact
+.It Pa /etc/kernel.conf
+Kernel configuration file.
+.Sh SEE ALSO
+.Xr config 8
Index: libexec/reorder_kernel/reorder_kernel.sh
===
RCS file: /home/OpenBSD/cvs/src/libexec/reorder_kernel/reorder_kernel.sh,v
retrieving revision 1.9
diff -u -p -r1.9 reorder_kernel.sh
--- libexec/reorder_kernel/reorder_kernel.sh28 Sep 2019 17:30:07 -
1.9
+++ libexec/reorder_kernel/reorder_kernel.sh24 Aug 2021 07:01:10 -
@@ -63,6 +63,7 @@ fi
cd
DANE in libressl?
Hi, I was wondering if anyone has wanted to implement DANE functions into OpenBSD? And LibreSSL perhaps? I want this for syslogd with TLS, but not sure if I'd be on someones toes here, if I start implementing... With unwind we can make use of things such as DANE due to validation of DNSSEC. Best Regards, -peter
Re: openssl(1): implement naccept
On Sun, Aug 29, 2021 at 02:00:44PM +0200, Theo Buehler wrote:
> Terminate the s_server after n clients connected to it. This is
> occasionally useful, matches OpenSSL's behavior and should help
> simplifying regress/usr.bin/openssl/x509.
>
hi.
> Index: openssl.1
> ===
> RCS file: /cvs/src/usr.bin/openssl/openssl.1,v
> retrieving revision 1.129
> diff -u -p -r1.129 openssl.1
> --- openssl.1 17 Mar 2021 18:08:32 - 1.129
> +++ openssl.1 28 Aug 2021 17:12:59 -
> @@ -4607,6 +4607,7 @@ will be used.
> .Op Fl keymatexportlen Ar len
> .Op Fl msg
> .Op Fl mtu Ar mtu
> +.Op Fl naccept Ar arg
i guess "arg" should be "num".
also i think it needs to be added to sv_usage in s_server.c.
otherwise doc parts ok.
jmc
> .Op Fl named_curve Ar arg
> .Op Fl nbio
> .Op Fl nbio_test
> @@ -4807,6 +4808,10 @@ Export len bytes of keying material (def
> Show all protocol messages with hex dump.
> .It Fl mtu Ar mtu
> Set the link layer MTU.
> +.It Fl naccept Ar num
> +Terminate server after
> +.Ar num
> +connections.
> .It Fl named_curve Ar arg
> Specify the elliptic curve name to use for ephemeral ECDH keys.
> This option is deprecated; use
> Index: s_apps.h
> ===
> RCS file: /cvs/src/usr.bin/openssl/s_apps.h,v
> retrieving revision 1.5
> diff -u -p -r1.5 s_apps.h
> --- s_apps.h 25 Apr 2018 07:12:33 - 1.5
> +++ s_apps.h 28 Aug 2021 17:12:59 -
> @@ -120,7 +120,7 @@ extern int verify_return_error;
>
> int do_server(int port, int type, int *ret,
> int (*cb)(char *hostname, int s, unsigned char *context),
> -unsigned char *context);
> +unsigned char *context, int naccept);
> #ifdef HEADER_X509_H
> int verify_callback(int ok, X509_STORE_CTX *ctx);
> #endif
> Index: s_server.c
> ===
> RCS file: /cvs/src/usr.bin/openssl/s_server.c,v
> retrieving revision 1.47
> diff -u -p -r1.47 s_server.c
> --- s_server.c17 Mar 2021 18:11:01 - 1.47
> +++ s_server.c28 Aug 2021 17:17:38 -
> @@ -267,6 +267,7 @@ static struct {
> uint16_t min_version;
> const SSL_METHOD *meth;
> int msg;
> + int naccept;
> char *named_curve;
> int nbio;
> int nbio_test;
> @@ -741,6 +742,13 @@ static const struct option s_server_opti
> },
> #endif
> {
> + .name = "naccept",
> + .argname = "num",
> + .desc = "terminate after num connections",
> + .type = OPTION_ARG_INT,
> + .opt.value = _server_config.naccept
> + },
> + {
> .name = "named_curve",
> .argname = "arg",
> .type = OPTION_ARG,
> @@ -1084,6 +1092,7 @@ s_server_main(int argc, char *argv[])
> memset(_server_config, 0, sizeof(s_server_config));
> s_server_config.keymatexportlen = 20;
> s_server_config.meth = TLS_server_method();
> + s_server_config.naccept = -1;
> s_server_config.port = PORT;
> s_server_config.cert_file = TEST_CERT;
> s_server_config.cert_file2 = TEST_CERT2;
> @@ -1465,10 +1474,12 @@ s_server_main(int argc, char *argv[])
> (void) BIO_flush(bio_s_out);
> if (s_server_config.www)
> do_server(s_server_config.port, s_server_config.socket_type,
> - _socket, www_body, s_server_config.context);
> + _socket, www_body, s_server_config.context,
> + s_server_config.naccept);
> else
> do_server(s_server_config.port, s_server_config.socket_type,
> - _socket, sv_body, s_server_config.context);
> + _socket, sv_body, s_server_config.context,
> + s_server_config.naccept);
> print_stats(bio_s_out, ctx);
> ret = 0;
> end:
> Index: s_socket.c
> ===
> RCS file: /cvs/src/usr.bin/openssl/s_socket.c,v
> retrieving revision 1.11
> diff -u -p -r1.11 s_socket.c
> --- s_socket.c28 Jun 2019 13:35:02 - 1.11
> +++ s_socket.c28 Aug 2021 17:12:59 -
> @@ -132,7 +132,7 @@ init_client(int *sock, char *host, char
> int
> do_server(int port, int type, int *ret,
> int (*cb) (char *hostname, int s, unsigned char *context),
> -unsigned char *context)
> +unsigned char *context, int naccept)
> {
> int sock;
> char *name = NULL;
> @@ -161,7 +161,9 @@ do_server(int port, int type, int *ret,
> shutdown(sock, SHUT_RDWR);
> close(sock);
> }
> - if (i < 0) {
> + if (naccept != -1)
> + naccept--;
> + if (i < 0 || naccept == 0) {
> shutdown(accept_socket, SHUT_RDWR);
> close(accept_socket);
> return (i);
>
openssl(1): implement naccept
Terminate the s_server after n clients connected to it. This is
occasionally useful, matches OpenSSL's behavior and should help
simplifying regress/usr.bin/openssl/x509.
Index: openssl.1
===
RCS file: /cvs/src/usr.bin/openssl/openssl.1,v
retrieving revision 1.129
diff -u -p -r1.129 openssl.1
--- openssl.1 17 Mar 2021 18:08:32 - 1.129
+++ openssl.1 28 Aug 2021 17:12:59 -
@@ -4607,6 +4607,7 @@ will be used.
.Op Fl keymatexportlen Ar len
.Op Fl msg
.Op Fl mtu Ar mtu
+.Op Fl naccept Ar arg
.Op Fl named_curve Ar arg
.Op Fl nbio
.Op Fl nbio_test
@@ -4807,6 +4808,10 @@ Export len bytes of keying material (def
Show all protocol messages with hex dump.
.It Fl mtu Ar mtu
Set the link layer MTU.
+.It Fl naccept Ar num
+Terminate server after
+.Ar num
+connections.
.It Fl named_curve Ar arg
Specify the elliptic curve name to use for ephemeral ECDH keys.
This option is deprecated; use
Index: s_apps.h
===
RCS file: /cvs/src/usr.bin/openssl/s_apps.h,v
retrieving revision 1.5
diff -u -p -r1.5 s_apps.h
--- s_apps.h25 Apr 2018 07:12:33 - 1.5
+++ s_apps.h28 Aug 2021 17:12:59 -
@@ -120,7 +120,7 @@ extern int verify_return_error;
int do_server(int port, int type, int *ret,
int (*cb)(char *hostname, int s, unsigned char *context),
-unsigned char *context);
+unsigned char *context, int naccept);
#ifdef HEADER_X509_H
int verify_callback(int ok, X509_STORE_CTX *ctx);
#endif
Index: s_server.c
===
RCS file: /cvs/src/usr.bin/openssl/s_server.c,v
retrieving revision 1.47
diff -u -p -r1.47 s_server.c
--- s_server.c 17 Mar 2021 18:11:01 - 1.47
+++ s_server.c 28 Aug 2021 17:17:38 -
@@ -267,6 +267,7 @@ static struct {
uint16_t min_version;
const SSL_METHOD *meth;
int msg;
+ int naccept;
char *named_curve;
int nbio;
int nbio_test;
@@ -741,6 +742,13 @@ static const struct option s_server_opti
},
#endif
{
+ .name = "naccept",
+ .argname = "num",
+ .desc = "terminate after num connections",
+ .type = OPTION_ARG_INT,
+ .opt.value = _server_config.naccept
+ },
+ {
.name = "named_curve",
.argname = "arg",
.type = OPTION_ARG,
@@ -1084,6 +1092,7 @@ s_server_main(int argc, char *argv[])
memset(_server_config, 0, sizeof(s_server_config));
s_server_config.keymatexportlen = 20;
s_server_config.meth = TLS_server_method();
+ s_server_config.naccept = -1;
s_server_config.port = PORT;
s_server_config.cert_file = TEST_CERT;
s_server_config.cert_file2 = TEST_CERT2;
@@ -1465,10 +1474,12 @@ s_server_main(int argc, char *argv[])
(void) BIO_flush(bio_s_out);
if (s_server_config.www)
do_server(s_server_config.port, s_server_config.socket_type,
- _socket, www_body, s_server_config.context);
+ _socket, www_body, s_server_config.context,
+ s_server_config.naccept);
else
do_server(s_server_config.port, s_server_config.socket_type,
- _socket, sv_body, s_server_config.context);
+ _socket, sv_body, s_server_config.context,
+ s_server_config.naccept);
print_stats(bio_s_out, ctx);
ret = 0;
end:
Index: s_socket.c
===
RCS file: /cvs/src/usr.bin/openssl/s_socket.c,v
retrieving revision 1.11
diff -u -p -r1.11 s_socket.c
--- s_socket.c 28 Jun 2019 13:35:02 - 1.11
+++ s_socket.c 28 Aug 2021 17:12:59 -
@@ -132,7 +132,7 @@ init_client(int *sock, char *host, char
int
do_server(int port, int type, int *ret,
int (*cb) (char *hostname, int s, unsigned char *context),
-unsigned char *context)
+unsigned char *context, int naccept)
{
int sock;
char *name = NULL;
@@ -161,7 +161,9 @@ do_server(int port, int type, int *ret,
shutdown(sock, SHUT_RDWR);
close(sock);
}
- if (i < 0) {
+ if (naccept != -1)
+ naccept--;
+ if (i < 0 || naccept == 0) {
shutdown(accept_socket, SHUT_RDWR);
close(accept_socket);
return (i);
Re: arm64 rpi4 upgrade, "Failed to install bootblocks" at end
Mark Kettenis wrote: > Should installboot(8) handle the case where the filesystem is already > mounted? Yes. I guess now that fsck_msdos is on the media, it will be run against a mounted partition, with is yet another weird problem
Re: arm64 rpi4 upgrade, "Failed to install bootblocks" at end
> Date: Sun, 29 Aug 2021 11:20:06 +0100 > From: Stuart Henderson > > On 2021/08/28 22:28, Stuart Henderson wrote: > > Spotted this at the end of a sysupgrade run. No issue with the reboot but > > it doesn't look quite right, in particular the newfs_msdos is a bit scary. > > > > [...] > > Installing xshare70.tgz 100% |**| 4505 KB00:36 > > > > Installing xfont70.tgz 100% |**| 39344 KB01:47 > > > > Installing xserv70.tgz 100% |**| 12346 KB00:11 > > > > Location of sets? (disk http nfs or 'done') [done] done > > Making all device nodes... done. > > sh: /sbin/fsck_msdos: not found > > newfs_msdos: /dev/rsd0i is mounted on /mnt/boot > > Oh and I see why I hit it now, I have this from when I was trying various > u-boot changes (to make it easier to update the files from the booted system). > > $ grep boot /etc/fstab > a3d7f93f60aec212.i /boot msdos rw,noatime 1 1 Yeah, that'll break things. The missing fsck itself isn't fatal since msdos filesystems don't have a bit to mark them clean and can always be mounted rw even if they weren't unmounted cleanly. Should installboot(8) handle the case where the filesystem is already mounted?
Re: arm64 rpi4 upgrade, "Failed to install bootblocks" at end
On 2021/08/28 22:28, Stuart Henderson wrote: > Spotted this at the end of a sysupgrade run. No issue with the reboot but > it doesn't look quite right, in particular the newfs_msdos is a bit scary. > > [...] > Installing xshare70.tgz 100% |**| 4505 KB00:36 > > Installing xfont70.tgz 100% |**| 39344 KB01:47 > > Installing xserv70.tgz 100% |**| 12346 KB00:11 > > Location of sets? (disk http nfs or 'done') [done] done > Making all device nodes... done. > sh: /sbin/fsck_msdos: not found > newfs_msdos: /dev/rsd0i is mounted on /mnt/boot Oh and I see why I hit it now, I have this from when I was trying various u-boot changes (to make it easier to update the files from the booted system). $ grep boot /etc/fstab a3d7f93f60aec212.i /boot msdos rw,noatime 1 1
Re: Atomic signal flags for vi(1)
This does look better.
I appreciate that you are fixing this underlying problem first, before
overlaying your timer diff.
Is this working for the vi crowd?
trondd wrote:
> "Theo de Raadt" wrote:
>
> > +h_alrm(int signo)
> > +{
> > + GLOBAL_CLP;
> > +
> > + F_SET(clp, CL_SIGALRM);
> >
> > F_SET is |=, which is not atomic.
> >
> > This is unsafe. Safe signal handlers need to make single stores to
> > atomic-sized variables, which tend to be int-sized, easier to declare
> > as sig_atomic_t. Most often these are global scope with the following
> > type:
> >
> > volatile sig_atomic_t variable
> >
> > I can see you copied an existing practice. Sadly all the other
> > signal handlers are also broken in the same way.
> >
> > The flag bits should be replaced with seperate sig_atomic_t variables.
>
> Ok. Took a swing at converting the signal handling to sig_atomic_t flags.
> No additional changes added other than removing a redundant check of the
> flags in cl_read.c. Seemed to be a pretty straight-forward conversion and
> I haven't found any change in behavior.
>
> Tim.
>
>
> Index: cl/cl.h
> ===
> RCS file: /cvs/src/usr.bin/vi/cl/cl.h,v
> retrieving revision 1.10
> diff -u -p -r1.10 cl.h
> --- cl/cl.h 27 May 2016 09:18:11 - 1.10
> +++ cl/cl.h 24 Aug 2021 23:34:27 -
> @@ -11,6 +11,11 @@
> * @(#)cl.h10.19 (Berkeley) 9/24/96
> */
>
> +extern volatile sig_atomic_t cl_sighup;
> +extern volatile sig_atomic_t cl_sigint;
> +extern volatile sig_atomic_t cl_sigterm;
> +extern volatile sig_atomic_t cl_sigwinch;
> +
> typedef struct _cl_private {
> CHAR_T ibuf[256]; /* Input keys. */
>
> @@ -45,11 +50,7 @@ typedef struct _cl_private {
> #define CL_RENAME_OK0x0004 /* User wants the windows renamed. */
> #define CL_SCR_EX_INIT 0x0008 /* Ex screen initialized. */
> #define CL_SCR_VI_INIT 0x0010 /* Vi screen initialized. */
> -#define CL_SIGHUP 0x0020 /* SIGHUP arrived. */
> -#define CL_SIGINT 0x0040 /* SIGINT arrived. */
> -#define CL_SIGTERM 0x0080 /* SIGTERM arrived. */
> -#define CL_SIGWINCH 0x0100 /* SIGWINCH arrived. */
> -#define CL_STDIN_TTY0x0200 /* Talking to a terminal. */
> +#define CL_STDIN_TTY0x0020 /* Talking to a terminal. */
> u_int32_t flags;
> } CL_PRIVATE;
>
> Index: cl/cl_funcs.c
> ===
> RCS file: /cvs/src/usr.bin/vi/cl/cl_funcs.c,v
> retrieving revision 1.20
> diff -u -p -r1.20 cl_funcs.c
> --- cl/cl_funcs.c 27 May 2016 09:18:11 - 1.20
> +++ cl/cl_funcs.c 24 Aug 2021 23:34:27 -
> @@ -601,7 +601,7 @@ cl_suspend(SCR *sp, int *allowedp)
> if (cl_ssize(sp, 1, NULL, NULL, ))
> return (1);
> if (changed)
> - F_SET(CLP(sp), CL_SIGWINCH);
> + cl_sigwinch = 1;
>
> return (0);
> }
> Index: cl/cl_main.c
> ===
> RCS file: /cvs/src/usr.bin/vi/cl/cl_main.c,v
> retrieving revision 1.33
> diff -u -p -r1.33 cl_main.c
> --- cl/cl_main.c 5 May 2016 20:36:41 - 1.33
> +++ cl/cl_main.c 24 Aug 2021 23:34:27 -
> @@ -33,6 +33,11 @@
>
> GS *__global_list; /* GLOBAL: List of screens. */
>
> +volatile sig_atomic_t cl_sighup;
> +volatile sig_atomic_t cl_sigint;
> +volatile sig_atomic_t cl_sigterm;
> +volatile sig_atomic_t cl_sigwinch;
> +
> static void cl_func_std(GS *);
> static CL_PRIVATE *cl_init(GS *);
> static GS *gs_init(void);
> @@ -217,16 +222,14 @@ h_hup(int signo)
> {
> GLOBAL_CLP;
>
> - F_SET(clp, CL_SIGHUP);
> + cl_sighup = 1;
> clp->killersig = SIGHUP;
> }
>
> static void
> h_int(int signo)
> {
> - GLOBAL_CLP;
> -
> - F_SET(clp, CL_SIGINT);
> + cl_sigint = 1;
> }
>
> static void
> @@ -234,16 +237,14 @@ h_term(int signo)
> {
> GLOBAL_CLP;
>
> - F_SET(clp, CL_SIGTERM);
> + cl_sigterm = 1;
> clp->killersig = SIGTERM;
> }
>
> static void
> h_winch(int signo)
> {
> - GLOBAL_CLP;
> -
> - F_SET(clp, CL_SIGWINCH);
> + cl_sigwinch = 1;
> }
> #undef GLOBAL_CLP
>
> @@ -259,6 +260,11 @@ sig_init(GS *gp, SCR *sp)
> CL_PRIVATE *clp;
>
> clp = GCLP(gp);
> +
> + cl_sighup = 0;
> + cl_sigint = 0;
> + cl_sigterm = 0;
> + cl_sigwinch = 0;
>
> if (sp == NULL) {
> if (setsig(SIGHUP, >oact[INDX_HUP], h_hup) ||
> Index: cl/cl_read.c
> ===
> RCS file: /cvs/src/usr.bin/vi/cl/cl_read.c,v
> retrieving revision 1.21
> diff -u -p -r1.21 cl_read.c
> --- cl/cl_read.c 27 May 2016 09:18:11 - 1.21
> +++ cl/cl_read.c 24 Aug 2021 23:34:27 -
> @@ -54,34 +54,32 @@ cl_event(SCR *sp, EVENT
