Re: kernel_relinking failed
On Thu, 23 Nov 2017, Kevin Chadwick wrote: [...] It is not like systemd that is replacing an existing system in a more complex way. I think, initialisation got always more complex. BSD init is simpler than Sys V init, systemd went to the extrem. But rc scripts seem also got always more complex. Even FreeBSD scripts got, in my opinion, unreadable. For me is even a surprise to see a call "cc" in an rc script. [...] Personally I believe security should be the focus of almost all software development, This is definitively not my opinion, because I do not hold internet connection (and networking) as escential in computing. Rodrigo.
Re: kernel_relinking failed
On Thu, 23 Nov 2017 08:26:52 + (UTC) > On Wed, 22 Nov 2017, Kevin Chadwick wrote: > > > If you do it manually you are unlikely to do it when you should. > > From time to time I type: sync. I am more afraid of hardware failure, > electricity blackout, my own errors, than of hacker attacks. > Yeah, so that is additional, you wouldn't want to have to run sync manually every time, right? > > Even on an 366mhz i386 it does not take very long?? > > % time /usr/libexec/reorder_kernel > 15.430u 2.700s 0:35.24 51.4%0+0k 1392+2984io 10429pf+0w > > This was an Intel Atom N270. I have much weaker processors. > I guess our definition of long considering the benefit differs, ;) > > Fair enough I get that but personally I would dump the 10,000 write > > flash memory. > > It is not only that with many writings EEPROM becomes ROM, but > that it is very slow, specially writing, specialy when attached > to USB, perhaps USB 1. > I have noticed that though it hasn't bothered me. However, perhaps it should be run under nice? Wondering about whether that gives a panic equipped attacker more opportunity. I guess it is a small window but not sure it is worth the risk? I feel like this is preference and not a problem that e.g. sleep may solve? > >> comment out its call in rc. The reordering of libraries can be > >> disabled, but the definition of the procedure is embedded in rc > >> and cannot be run manually. > > > > Of course it can, check out the log maybe. I had to get a fresh > > tarball from base62.tgz one time when I screwed it up though. > > I am speaking of the reordering of libraries, not KARL. > Just see reorder_libs() in rc script. You can disable it > in rc.conf, but you cannot run it manually. KARL cannot > be disabled in rc.conf. Right, I see. I presume because they are already in use so a reboot would then be needed anyway. Library re-ordering takes even less time, so I really don't see the problem. It is not like systemd that is replacing an existing system in a more complex way. There is real security benefit and that is OpenBSDs focus. Personally I believe security should be the focus of almost all software development, which would have prevented systemd in the first place. I am not a developer by the way. In case you think I speak for the project.
Re: kernel_relinking failed
On Wed, 22 Nov 2017, Kevin Chadwick wrote: If you do it manually you are unlikely to do it when you should. From time to time I type: sync. I am more afraid of hardware failure, electricity blackout, my own errors, than of hacker attacks. Even on an 366mhz i386 it does not take very long?? % time /usr/libexec/reorder_kernel 15.430u 2.700s 0:35.24 51.4%0+0k 1392+2984io 10429pf+0w This was an Intel Atom N270. I have much weaker processors. Fair enough I get that but personally I would dump the 10,000 write flash memory. It is not only that with many writings EEPROM becomes ROM, but that it is very slow, specially writing, specialy when attached to USB, perhaps USB 1. Actually it is a separate forked process ran at the very end, so not really. Yes, it will not spoil the booting if it fails, one can compare it with the starting of daemons, but the last do not make anymore than wait for connections. On the other side, the reordering of libraries does not run in the background, sure for a good reason: to use reordered libs from the beginning, to run daemons with reordered libraries. But one could do it as KARK: reorder now for the next boot. comment out its call in rc. The reordering of libraries can be disabled, but the definition of the procedure is embedded in rc and cannot be run manually. Of course it can, check out the log maybe. I had to get a fresh tarball from base62.tgz one time when I screwed it up though. I am speaking of the reordering of libraries, not KARL. Just see reorder_libs() in rc script. You can disable it in rc.conf, but you cannot run it manually. KARL cannot be disabled in rc.conf. Rodrigo.
Re: kernel_relinking failed
On Wed, 22 Nov 2017 17:58:48 + (UTC) > Of course, it is senseless to reorder kernel more than one time when > the computer is up. But for the above reason, it is obviously > not necessary to do it after any boot. You can do it manually > from time to time, when the computer is up and you do not need it. > I disagree, in fact rebooting servers after say an unexpected behaviour or to get a reorder is a good thing. If you do it manually you are unlikely to do it when you should. I still don't see why exactly. > The question that remains, is, if it is not a problem to do it > at any reboot. It depends on your hardware and on how you > use OpenBSD. > Even on an 366mhz i386 it does not take very long?? > I like silent, slow computers. reorder_kernel is > disabled when /usr/share is on a nfs mounted, namely, for a diskless > machine, but there are other situations, for example when you > boot from slow flash memory attached to USB and want it also > readonly. > Fair enough I get that but personally I would dump the 10,000 write flash memory. > > I mean something else: the complexity of the booting process. > And of course I want to have the computer booted as soon as > possible, and the slow reorder_kernel and library reordering > is now part of the booting process. > Actually it is a separate forked process ran at the very end, so not really. > > The script is in /usr/libexec if you must but to quote Theo to me a > > number of times. "You own the pieces" > > If I disable KARL changing the file with the checksum, running > /usr/libexec/reorder_kernel.sh has no effect. It remains to > comment out its call in rc. The reordering of libraries can be > disabled, but the definition of the procedure is embedded in rc > and cannot be run manually. Of course it can, check out the log maybe. I had to get a fresh tarball from base62.tgz one time when I screwed it up though.
Re: kernel_relinking failed
On Wed, 22 Nov 2017, Kevin Chadwick wrote: I would preffer to run the script for relinking kernel from time to time manually, and not run it at boot time. The same for reordering libraries. Why exactly? A laptop that does not go to the internet is rebooted more than a home PC with internet connection behind a router, the home PC more than a server continously and directly exposed to the internet. The less you need security, the most you are enjoying the security benefit of KARL. Of course, it is senseless to reorder kernel more than one time when the computer is up. But for the above reason, it is obviously not necessary to do it after any boot. You can do it manually from time to time, when the computer is up and you do not need it. The question that remains, is, if it is not a problem to do it at any reboot. It depends on your hardware and on how you use OpenBSD. I like silent, slow computers. reorder_kernel is disabled when /usr/share is on a nfs mounted, namely, for a diskless machine, but there are other situations, for example when you boot from slow flash memory attached to USB and want it also readonly. Fair enough but doesn't apply here. Systemd sacrifices in many usability areas for boot speed which is rarely faster I mean something else: the complexity of the booting process. And of course I want to have the computer booted as soon as possible, and the slow reorder_kernel and library reordering is now part of the booting process. The script is in /usr/libexec if you must but to quote Theo to me a number of times. "You own the pieces" If I disable KARL changing the file with the checksum, running /usr/libexec/reorder_kernel.sh has no effect. It remains to comment out its call in rc. The reordering of libraries can be disabled, but the definition of the procedure is embedded in rc and cannot be run manually. Rodrigo.
Re: kernel_relinking failed
On Tue, 21 Nov 2017 17:11:34 + (UTC) > I would preffer to run the script for relinking kernel from > time to time manually, and not run it at boot time. The same > for reordering libraries. > Why exactly? If you shutdown straight away and the relinking works next time then the window of investigating your gadget layout is as insignificant as it can be. Doing it another way only increases that risk. > I also avoid to start deamons at boot time that I not need > at the moment. See it as the opposite of the systemd ideology. Fair enough but doesn't apply here. Systemd sacrifices in many usability areas for boot speed which is rarely faster (propaganda to get support?) especially with concurrency on HDD (single head arm). I don't see an issue with relinking that decreases boot speed slightly but may SAVE YOUR BUTT, when you least expect it to. The script is in /usr/libexec if you must but to quote Theo to me a number of times. "You own the pieces" Remember, any issues with the current system like xenodm being held up will be maintained and personally I don't see the benefit?
Re: kernel_relinking failed
Can you show us the relink.log when it fails? It does not fail since a while. I think, the problem is the following: I booted and rebooted immediately, and tested doing that again, but the script for relinking kernel runs in underground and takes a lot of time. I wondered why I got the message at the end, perhaps because I shuted down before the script ended. I would preffer to run the script for relinking kernel from time to time manually, and not run it at boot time. The same for reordering libraries. I also avoid to start deamons at boot time that I not need at the moment. See it as the opposite of the systemd ideology. Rodrigo.
Re: kernel_relinking failed
On 11/18/17 15:38, Roderick wrote:
>
> Dear Sirs,
>
> At about every second shutdown I get at the end the message:
>
> ---
> reorder_kernel: kernel relinking failed; see
> /usr/share/compile/GENERIC.MP/relink.org
> ---
>
> The contents of last file is at the end of this Email.
>
> It is a just installed OpenBSD 6.2 (no upgrade). What does this
> error mean?
>
> Thanks
> Rodrigo.
>
>
>
> relink.log
> ---
> (SHA256) /bsd: OK
> LD="ld" sh makegap.sh 0x
> ld -T ld.script -X --warn-common -nopie -o newbsd ${SYSTEM_HEAD} vers.o
> ${OBJS}
> text databss dec hex
> 8222884 2448464 1093632 11764980b384f4
> mv newbsd newbsd.gdb
> ctfstrip -S -o newbsd newbsd.gdb
> mv -f newbsd bsd
> cmp -s bsd /bsd || ln -f /bsd /obsd
> umask 077 && cp bsd /nbsd && mv /nbsd /bsd && sha256 -h
> /var/db/kernel.SHA256 /bsd
>
> Kernel has been relinked and is active on next reboot.
>
> SHA256 (/bsd) =
> 9426f77b6d313f8f5e07ab1d1fc9bde9ef3975ac5b64ed9540cbd3fda9091884
> ---
Looks like you showed us the relink.log file from the successful times,
as that's pretty much saying, "it worked, it's installed", etc.
Can you show us the relink.log when it fails?
Nick.
