Re: disabling SA in 5.0

[David Brownlee <abs%NetBSD.org@localhost>]

On Mon, 9 Mar 2009, Martin Husemann wrote:

> On Sun, Mar 08, 2009 at 10:43:39PM +0000, David Brownlee wrote:
> >         How difficult would it be to disable it by default and arrange
> >         for a kernel printf mentioning the sysctl when a process
> >         attempts to use it and fails
>
> This is too late, already - the system will be not functioning as expected
> in this state already, and we realy do not want our users to easily get
> into that state.

        I understand, but its safe to assume that *some* will hit that
        state, and it would be nice to provide a big red flag so they
        can trivially work out what has happened and just set the sysctl
        to fix it (untill they upgrade their libraries).

        Actually IIRC Andrew produced a compat pthread library which
        enabled dynamically linked SA pthread using binaries to run
        against the new pthread in 5.0. It was dropped in favour of
        providing the full compat_sa as it required upgrading the
        userland at the same time as the kernel, but as anyone using
        sysinst to upgrade a system will hit that path anyway maybe
        that is a better approach to handling 5.0?

        I tested it at the time against a set of 4.0 pthread sa using
        binaries and was unable to trigger any of the crashes and lockups
        I got with the full pthread sa compat.

> We can note it in the release notes (and probably a lot more prominent
> places), it still will bite some people.
>
> However, we can guess (and nothing more) how many people, while using a
> manual update method, rely on our standard binary distribution. There will be
> some, but maybe forcing them to prepare a custom install media would be
> acceptable pain. I am not sure. I probably would prefer to make them upgrade
> to something with similar security/local DOS problems as the 4.x they used
> before and then tell them how to make it secure.
>
> On the other hand, we certainly do not want to do this play for new
> installations, so maybe a hackish but simple solution could be to use two
> different kernel sets - one for upgrades (with SA enabled by default and
> a prominent warning printed at every boot) and a "real" one for fresh
> installations?

        For that case you could just add logic to sysinst to optionally
        enable the sysctl in sysctl.conf ...

--
                David/absolute       -- www.NetBSD.org: No hype required --