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}
> 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” f
> 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)
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
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,
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 m
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
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
variab
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
> do
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
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-O
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.
>
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
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 b
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
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 (dtu
16 matches
Mail list logo