Re: kernel relink segfaults on ALIX

[Jan Stary]

On Apr 19 08:52:38, h...@stare.cz wrote:
> This is a fresh upgrade of current/i386 on an ALIX 2D3.
> Upon start, kernel relinking fails, with relink.log saying:
> 
> (SHA256) /bsd: OK
> LD="ld" LDFLAGS="-g" sh makegap.sh 0x
> ld -T ld.script -X --warn-common -nopie -o newbsd ${SYSTEM_HEAD} vers.o 
> ${OBJS}
> Segmentation fault (core dumped) 
> *** Error 139 in /usr/share/relink/kernel/GENERIC (Makefile:1045 'newbsd': 
> @echo ld -T ld.script -X --warn-common -nopie -o newbsd '${SYSTEM...)
> 
> /usr/share/relink is empty, with
> /dev/wd0d 1001M801M150M84%/usr

On Apr 19 17:16:45, dtuc...@dtucker.net wrote:
> Do you have any swap configured?  Relinking takes a reasonable amount
> of ram and the ALIX doesn't have a lot.

That was it, thank you. With some swap added
it relinks the kernel fine. Right after boot, it's

$ swapctl -s
total: 4192960 512-blocks allocated, 127768 used, 4065192 available

Jan

Re: kernel relink segfaults on ALIX

[Patrick Dohman]

> ed...@pettijohn-web.com wrote:
> 
> One step further would be to put that in your rc.local so it survives an 
> upgrade.
> 

An even more insecure option is:
chmod 000 /usr/libexec/reorder_kernel
doas chflags schg /usr/libexec/reorder_kernel
Beware securelevel 0 is required to clear the "schg” file flag.

Mamma mia!
Patrick

Re: kernel relink segfaults on ALIX

[IL Ka]

> commented out the call to
> reorder_kernel in rc.

I still believe that  ``chmod -x /usr/libexec/reorder_kernel`` is much
better and safer  than patching ``/etc/rc``,
but it is up to you)

Re: kernel relink segfaults on ALIX

[Roderick]

On Thu, 19 Apr 2018, IL Ka wrote:


We can disable  library_aslr, but there is no same option for kernel..


I disabled library_aslr and commented out the call to
reorder_kernel in rc.

I can manually reorder kernel by calling reorder_kernel
when I consider it necessary, unfortunately I cannot do
the same with library_aslr: the code is embedded in rc.

BTW. By changing /var/db/kernel.SHA256 you disable kernel 
reordering, but then calling reorder_kernel has no effect.


Rodrigo.

Re: kernel relink segfaults on ALIX

[IL Ka]

I am sorry, I skipped your last line:
> Just comment in rc -_- for kernel

You are right. But it is safer to "chmod -x" reorder_kernel (touching rc is
not good)

On Thu, Apr 19, 2018 at 9:58 PM, sven falempin 
wrote:

> On Thu, Apr 19, 2018 at 1:01 PM, IL Ka  wrote:
>
> > Upgrade may affect kernel, so you need to reorder it at least once after
> > upgrade!
> >
> > I am not sure which policy do OpenBSD use, but generally if something is
> > not documented it is subject to be changed in minor upgrade.
> >
> > The only reference to this script is ``/etc/rc`` (line 620) without of
> any
> > variable, and since "reorder_kernel" is
> > not documented it would be absolutelly legal to rename it and update
> > /etc/rc accordingly.
> >
> > So, this little hack may be broken after upgrade anyway.
> >
> > I wish there were ``man reorder_kernel(8)`` and ``reorder_kernel=NO``
> > documented in ``rc.conf(8)``
> > But if I understood everything correct, developers say we should not
> > disable this script,
> > that is why they do not document it nor create an option in rc.conf.
> >
> >
> > On Thu, Apr 19, 2018 at 7:42 PM,  wrote:
> >
> > > One step further would be to put that in your rc.local so it survives
> an
> > > upgrade.
> > > On Apr 19, 2018 9:44 AM, IL Ka  wrote:
> > > >
> > > > Ancient UNIX way to disable anything: ``doas chmod -x
> > > > /usr/libexec/reorder_kernel`` ;)
> > > >
> > > > Although ``reorder_kernel`` is very simple ksh script, I agree it
> > should
> > > be
> > > > documented.
> > > >
> > >
> >
>
> grep aslr /etc/rc.conf  >> /etc/rc.conf.local
>
> When you reboot often on crap drive, or if you are not exposed (test
> device), relinking is waste of time
> IF you are online , keep it .
>
> Just comment in rc -_- for kernel
>
> --
> --
> 
> -
> Knowing is not enough; we must apply. Willing is not enough; we must do
>

Re: kernel relink segfaults on ALIX

[IL Ka]

You are speaking about ``library_aslr`` which is documented by ``man
rc.conf``.
But it is not the same thing as kernel reordering: it reorders libs, so
they'll
be loaded at different memory address next time.
And kernel relink does same for kernel itself (relinks kernel from its
objects in random manner).

We can disable  library_aslr, but there is no same option for kernel..


On Thu, Apr 19, 2018 at 9:58 PM, sven falempin 
wrote:

> On Thu, Apr 19, 2018 at 1:01 PM, IL Ka  wrote:
>
> > Upgrade may affect kernel, so you need to reorder it at least once after
> > upgrade!
> >
> > I am not sure which policy do OpenBSD use, but generally if something is
> > not documented it is subject to be changed in minor upgrade.
> >
> > The only reference to this script is ``/etc/rc`` (line 620) without of
> any
> > variable, and since "reorder_kernel" is
> > not documented it would be absolutelly legal to rename it and update
> > /etc/rc accordingly.
> >
> > So, this little hack may be broken after upgrade anyway.
> >
> > I wish there were ``man reorder_kernel(8)`` and ``reorder_kernel=NO``
> > documented in ``rc.conf(8)``
> > But if I understood everything correct, developers say we should not
> > disable this script,
> > that is why they do not document it nor create an option in rc.conf.
> >
> >
> > On Thu, Apr 19, 2018 at 7:42 PM,  wrote:
> >
> > > One step further would be to put that in your rc.local so it survives
> an
> > > upgrade.
> > > On Apr 19, 2018 9:44 AM, IL Ka  wrote:
> > > >
> > > > Ancient UNIX way to disable anything: ``doas chmod -x
> > > > /usr/libexec/reorder_kernel`` ;)
> > > >
> > > > Although ``reorder_kernel`` is very simple ksh script, I agree it
> > should
> > > be
> > > > documented.
> > > >
> > >
> >
>
> grep aslr /etc/rc.conf  >> /etc/rc.conf.local
>
> When you reboot often on crap drive, or if you are not exposed (test
> device), relinking is waste of time
> IF you are online , keep it .
>
> Just comment in rc -_- for kernel
>
> --
> --
> 
> -
> Knowing is not enough; we must apply. Willing is not enough; we must do
>

Re: kernel relink segfaults on ALIX

[sven falempin]

On Thu, Apr 19, 2018 at 1:01 PM, IL Ka  wrote:

> Upgrade may affect kernel, so you need to reorder it at least once after
> upgrade!
>
> I am not sure which policy do OpenBSD use, but generally if something is
> not documented it is subject to be changed in minor upgrade.
>
> The only reference to this script is ``/etc/rc`` (line 620) without of any
> variable, and since "reorder_kernel" is
> not documented it would be absolutelly legal to rename it and update
> /etc/rc accordingly.
>
> So, this little hack may be broken after upgrade anyway.
>
> I wish there were ``man reorder_kernel(8)`` and ``reorder_kernel=NO``
> documented in ``rc.conf(8)``
> But if I understood everything correct, developers say we should not
> disable this script,
> that is why they do not document it nor create an option in rc.conf.
>
>
> On Thu, Apr 19, 2018 at 7:42 PM,  wrote:
>
> > One step further would be to put that in your rc.local so it survives an
> > upgrade.
> > On Apr 19, 2018 9:44 AM, IL Ka  wrote:
> > >
> > > Ancient UNIX way to disable anything: ``doas chmod -x
> > > /usr/libexec/reorder_kernel`` ;)
> > >
> > > Although ``reorder_kernel`` is very simple ksh script, I agree it
> should
> > be
> > > documented.
> > >
> >
>

grep aslr /etc/rc.conf  >> /etc/rc.conf.local

When you reboot often on crap drive, or if you are not exposed (test
device), relinking is waste of time
IF you are online , keep it .

Just comment in rc -_- for kernel

-- 
--

-
Knowing is not enough; we must apply. Willing is not enough; we must do

Re: kernel relink segfaults on ALIX

[IL Ka]

Upgrade may affect kernel, so you need to reorder it at least once after
upgrade!

I am not sure which policy do OpenBSD use, but generally if something is
not documented it is subject to be changed in minor upgrade.

The only reference to this script is ``/etc/rc`` (line 620) without of any
variable, and since "reorder_kernel" is
not documented it would be absolutelly legal to rename it and update
/etc/rc accordingly.

So, this little hack may be broken after upgrade anyway.

I wish there were ``man reorder_kernel(8)`` and ``reorder_kernel=NO``
documented in ``rc.conf(8)``
But if I understood everything correct, developers say we should not
disable this script,
that is why they do not document it nor create an option in rc.conf.


On Thu, Apr 19, 2018 at 7:42 PM,  wrote:

> One step further would be to put that in your rc.local so it survives an
> upgrade.
> On Apr 19, 2018 9:44 AM, IL Ka  wrote:
> >
> > Ancient UNIX way to disable anything: ``doas chmod -x
> > /usr/libexec/reorder_kernel`` ;)
> >
> > Although ``reorder_kernel`` is very simple ksh script, I agree it should
> be
> > documented.
> >
>

Re: kernel relink segfaults on ALIX

[edgar]

One step further would be to put that in your rc.local so it survives an 
upgrade.
On Apr 19, 2018 9:44 AM, IL Ka  wrote:
>
> Ancient UNIX way to disable anything: ``doas chmod -x
> /usr/libexec/reorder_kernel`` ;)
>
> Although ``reorder_kernel`` is very simple ksh script, I agree it should be
> documented.
>
>
>
> On Thu, Apr 19, 2018 at 12:15 PM, Z Ero  wrote:
>
> > Coincidently I just logged in to write the misc  list about relinking
> > on boot. Is it possible to disable it? What about just relinking on
> > the first boot after install? So then every kernel image is different
> > but not re-randomized each boot! There are some low memory / slow CPU
> > embedded systems like Alix / Soekris where the benefit, in my opinion,
> > of re-linking every single boot is not worth the cost. That said
> > granted these systems should not be rebooted frequently anyway once in
> > production during normal use. I had a soekris recently that performed
> > well for the task I needed it for but that I chose to install OpenBSD
> > version 5.8 on...because I did not want to put up with the
> > relinking...I would have rather used 6.2...would it be possible to
> > give users a "switch" to turn off relinking if they want without
> > recompiling the kernel...please forgive my ignorance (or flame
> > away...) if this already exists.
> >
> > Thanks.
> >
> > On Thu, Apr 19, 2018 at 2:16 AM, Darren Tucker 
> > wrote:
> > > On 19 April 2018 at 16:52, Jan Stary  wrote:
> > >> This is a fresh upgrade of current/i386 on an ALIX 2D3.
> > >> Upon start, kernel relinking fails, with relink.log saying:
> > >
> > > Do you have any swap configured?  Relinking takes a reasonable amount
> > > of ram and the ALIX doesn't have a lot.
> > >
> > > --
> > > Darren Tucker (dtucker at dtucker.net)
> > > GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA
> > (new)
> > > Good judgement comes with experience. Unfortunately, the experience
> > > usually comes from bad judgement.
> > >
> >
> >

Re: kernel relink segfaults on ALIX

[IL Ka]

Ancient UNIX way to disable anything: ``doas chmod -x
/usr/libexec/reorder_kernel`` ;)

Although ``reorder_kernel`` is very simple ksh script, I agree it should be
documented.



On Thu, Apr 19, 2018 at 12:15 PM, Z Ero  wrote:

> Coincidently I just logged in to write the misc  list about relinking
> on boot. Is it possible to disable it? What about just relinking on
> the first boot after install? So then every kernel image is different
> but not re-randomized each boot! There are some low memory / slow CPU
> embedded systems like Alix / Soekris where the benefit, in my opinion,
> of re-linking every single boot is not worth the cost. That said
> granted these systems should not be rebooted frequently anyway once in
> production during normal use. I had a soekris recently that performed
> well for the task I needed it for but that I chose to install OpenBSD
> version 5.8 on...because I did not want to put up with the
> relinking...I would have rather used 6.2...would it be possible to
> give users a "switch" to turn off relinking if they want without
> recompiling the kernel...please forgive my ignorance (or flame
> away...) if this already exists.
>
> Thanks.
>
> On Thu, Apr 19, 2018 at 2:16 AM, Darren Tucker 
> wrote:
> > On 19 April 2018 at 16:52, Jan Stary  wrote:
> >> This is a fresh upgrade of current/i386 on an ALIX 2D3.
> >> Upon start, kernel relinking fails, with relink.log saying:
> >
> > Do you have any swap configured?  Relinking takes a reasonable amount
> > of ram and the ALIX doesn't have a lot.
> >
> > --
> > Darren Tucker (dtucker at dtucker.net)
> > GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA
> (new)
> > Good judgement comes with experience. Unfortunately, the experience
> > usually comes from bad judgement.
> >
>
>

Re: kernel relink segfaults on ALIX

[Theo de Raadt]

The great thing about OpenBSD is that it comes with all these debugging
tools that let you figure out what happened, right there on your own
system, without having to engage tech support who speaks a foreign
language.  If only you spend a few minutes to learn before sending
email.

Into enhle nge-OpenBSD yukuthi ifika nazo zonke lezi zinkinga
amathuluzi akuvumela ukuba uhlole ukuthi kwenzekani, khona-ke lapho uqobo
uhlelo, ngaphandle kokubandakanya ukwesekwa kwe-tech okhuluma ngaphandle
ulimi. Uma nje uchitha imizuzu embalwa ukuze ufunde ngaphambi kokuthumela
imeyili.

Jan Stary  wrote:
> This is a fresh upgrade of current/i386 on an ALIX 2D3.
> Upon start, kernel relinking fails, with relink.log saying:
> 
> (SHA256) /bsd: OK
> LD="ld" LDFLAGS="-g" sh makegap.sh 0x
> ld -T ld.script -X --warn-common -nopie -o newbsd ${SYSTEM_HEAD} vers.o 
> ${OBJS}
> Segmentation fault (core dumped) 
> *** Error 139 in /usr/share/relink/kernel/GENERIC (Makefile:1045 'newbsd': 
> @echo ld -T ld.script -X --warn-common -nopie -o newbsd '${SYSTEM...)
> 
> /usr/share/relink is empty, with
> /dev/wd0d 1001M801M150M84%/usr
> 
> Am I missing something obvious?
> 
>   Jan
> 

Re: kernel relink segfaults on ALIX

[Z Ero]

Did you see my reply...i had the epiphany that no incantation is
necessary. I have seen the light.

On Thu, Apr 19, 2018 at 6:58 AM, Paul de Weerd  wrote:
> On Thu, Apr 19, 2018 at 06:53:26AM -0500, Z Ero wrote:
> | Is the feature documented in the manual pages...thanks...if this really 
> works.
>
> OpenBSD doesn't normally document how to disable security features.
> Generally, security features cannot be disabled.  In this case you
> can because of the way it's implemented.
>
> Please make sure you write "make_me_less_secure_please" to the file
> though and chant the same phrase every day at noon (in your
> /etc/localtime timezone) for each day you run in this state; this is
> an important part of stopping the kernel relinking...
>
> Paul 'WEiRD' de Weerd
>
> | On Thu, Apr 19, 2018 at 4:29 AM, Paul de Weerd  wrote:
> | > On Thu, Apr 19, 2018 at 04:15:50AM -0500, Z Ero wrote:
> | > | Coincidently I just logged in to write the misc  list about relinking
> | > | on boot. Is it possible to disable it? What about just relinking on
> | > | the first boot after install? So then every kernel image is different
> | > | but not re-randomized each boot! There are some low memory / slow CPU
> | > | embedded systems like Alix / Soekris where the benefit, in my opinion,
> | > | of re-linking every single boot is not worth the cost. That said
> | > | granted these systems should not be rebooted frequently anyway once in
> | > | production during normal use. I had a soekris recently that performed
> | > | well for the task I needed it for but that I chose to install OpenBSD
> | > | version 5.8 on...because I did not want to put up with the
> | > | relinking...I would have rather used 6.2...would it be possible to
> | > | give users a "switch" to turn off relinking if they want without
> | > | recompiling the kernel...please forgive my ignorance (or flame
> | > | away...) if this already exists.
> | >
> | > echo make_me_less_secure_please | doas tee /var/db/kernel.SHA256
> | >
> | > Going back to an older release to *avoid* security features in newer
> | > versions... wow.  You do realise that this kernel relinking thing is
> | > not the only improvement that's made in the more than two years since
> | > 5.8, right?
> | >
> | > Paul 'WEiRD' de Weerd
> | >
> | > --
> | >>[<++>-]<+++.>+++[<-->-]<.>+++[<+
> | > +++>-]<.>++[<>-]<+.--.[-]
> | >  http://www.weirdnet.nl/
>
> --
>>[<++>-]<+++.>+++[<-->-]<.>+++[<+
> +++>-]<.>++[<>-]<+.--.[-]
>  http://www.weirdnet.nl/

Re: kernel relink segfaults on ALIX

[Paul de Weerd]

On Thu, Apr 19, 2018 at 06:53:26AM -0500, Z Ero wrote:
| Is the feature documented in the manual pages...thanks...if this really works.

OpenBSD doesn't normally document how to disable security features.
Generally, security features cannot be disabled.  In this case you
can because of the way it's implemented.

Please make sure you write "make_me_less_secure_please" to the file
though and chant the same phrase every day at noon (in your
/etc/localtime timezone) for each day you run in this state; this is
an important part of stopping the kernel relinking...

Paul 'WEiRD' de Weerd

| On Thu, Apr 19, 2018 at 4:29 AM, Paul de Weerd  wrote:
| > On Thu, Apr 19, 2018 at 04:15:50AM -0500, Z Ero wrote:
| > | Coincidently I just logged in to write the misc  list about relinking
| > | on boot. Is it possible to disable it? What about just relinking on
| > | the first boot after install? So then every kernel image is different
| > | but not re-randomized each boot! There are some low memory / slow CPU
| > | embedded systems like Alix / Soekris where the benefit, in my opinion,
| > | of re-linking every single boot is not worth the cost. That said
| > | granted these systems should not be rebooted frequently anyway once in
| > | production during normal use. I had a soekris recently that performed
| > | well for the task I needed it for but that I chose to install OpenBSD
| > | version 5.8 on...because I did not want to put up with the
| > | relinking...I would have rather used 6.2...would it be possible to
| > | give users a "switch" to turn off relinking if they want without
| > | recompiling the kernel...please forgive my ignorance (or flame
| > | away...) if this already exists.
| >
| > echo make_me_less_secure_please | doas tee /var/db/kernel.SHA256
| >
| > Going back to an older release to *avoid* security features in newer
| > versions... wow.  You do realise that this kernel relinking thing is
| > not the only improvement that's made in the more than two years since
| > 5.8, right?
| >
| > Paul 'WEiRD' de Weerd
| >
| > --
| >>[<++>-]<+++.>+++[<-->-]<.>+++[<+
| > +++>-]<.>++[<>-]<+.--.[-]
| >  http://www.weirdnet.nl/

-- 
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
 http://www.weirdnet.nl/ 

Re: kernel relink segfaults on ALIX

[Paul de Weerd]

On Thu, Apr 19, 2018 at 04:15:50AM -0500, Z Ero wrote:
| Coincidently I just logged in to write the misc  list about relinking
| on boot. Is it possible to disable it? What about just relinking on
| the first boot after install? So then every kernel image is different
| but not re-randomized each boot! There are some low memory / slow CPU
| embedded systems like Alix / Soekris where the benefit, in my opinion,
| of re-linking every single boot is not worth the cost. That said
| granted these systems should not be rebooted frequently anyway once in
| production during normal use. I had a soekris recently that performed
| well for the task I needed it for but that I chose to install OpenBSD
| version 5.8 on...because I did not want to put up with the
| relinking...I would have rather used 6.2...would it be possible to
| give users a "switch" to turn off relinking if they want without
| recompiling the kernel...please forgive my ignorance (or flame
| away...) if this already exists.

echo make_me_less_secure_please | doas tee /var/db/kernel.SHA256

Going back to an older release to *avoid* security features in newer
versions... wow.  You do realise that this kernel relinking thing is
not the only improvement that's made in the more than two years since
5.8, right?

Paul 'WEiRD' de Weerd

-- 
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
 http://www.weirdnet.nl/ 

Re: kernel relink segfaults on ALIX

[Z Ero]

Coincidently I just logged in to write the misc  list about relinking
on boot. Is it possible to disable it? What about just relinking on
the first boot after install? So then every kernel image is different
but not re-randomized each boot! There are some low memory / slow CPU
embedded systems like Alix / Soekris where the benefit, in my opinion,
of re-linking every single boot is not worth the cost. That said
granted these systems should not be rebooted frequently anyway once in
production during normal use. I had a soekris recently that performed
well for the task I needed it for but that I chose to install OpenBSD
version 5.8 on...because I did not want to put up with the
relinking...I would have rather used 6.2...would it be possible to
give users a "switch" to turn off relinking if they want without
recompiling the kernel...please forgive my ignorance (or flame
away...) if this already exists.

Thanks.

On Thu, Apr 19, 2018 at 2:16 AM, Darren Tucker  wrote:
> On 19 April 2018 at 16:52, Jan Stary  wrote:
>> This is a fresh upgrade of current/i386 on an ALIX 2D3.
>> Upon start, kernel relinking fails, with relink.log saying:
>
> Do you have any swap configured?  Relinking takes a reasonable amount
> of ram and the ALIX doesn't have a lot.
>
> --
> Darren Tucker (dtucker at dtucker.net)
> GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
> Good judgement comes with experience. Unfortunately, the experience
> usually comes from bad judgement.
>

Re: kernel relink segfaults on ALIX

[Darren Tucker]

On 19 April 2018 at 16:52, Jan Stary  wrote:
> This is a fresh upgrade of current/i386 on an ALIX 2D3.
> Upon start, kernel relinking fails, with relink.log saying:

Do you have any swap configured?  Relinking takes a reasonable amount
of ram and the ALIX doesn't have a lot.

-- 
Darren Tucker (dtucker at dtucker.net)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.