tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: disabling SA in 5.0

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

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

                David/absolute       -- No hype required --

Home | Main Index | Thread Index | Old Index