Kernel Compiler missmatches
 

We have a couple of reports indicating that following an update to Hardy
their exernal modules no longer build. Specifically those modules fail
to build because the version of gcc used to build the kernel and the one
installed and available to build the modules does not match. The kernel
highly recommends you use the same version, and most external modules
sensibly enforce this.

This missmatch has been triggered in Hardy because we recently did a
security update to the kernel. That was built in the -security environment
which necesarily lacks any updates from -updates, and therefore has the
released version of gcc. This kernel was then pocket copied to -updates.
At this point users of -updates have a kernel which was compiled with an
older compiler than the one they have. This is not desirable.

There seem to be several simple options here:

1) expect the users to build their own kernels if they want to use
external modules, or
2) update gcc in -security, and always do so, or
3) have separate kernel builds for each pocket (rather than pocket copying
the -security update into -updates, upload it there separatly with a
higher upload number).

I guess the security team is best placed to evaluate the safety or
otherwise of (2).

Thoughts?

-apw

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Kernel Compiler missmatches
 

On Fri, 13 Feb 2009 12:06:56 +0000 Andy Whitcroft <apw@canonical.com> wrote:
>We have a couple of reports indicating that following an update to Hardy
>their exernal modules no longer build. Specifically those modules fail
>to build because the version of gcc used to build the kernel and the one
>installed and available to build the modules does not match. The kernel
>highly recommends you use the same version, and most external modules
>sensibly enforce this.
>
>This missmatch has been triggered in Hardy because we recently did a
>security update to the kernel. That was built in the -security environment
>which necesarily lacks any updates from -updates, and therefore has the
>released version of gcc. This kernel was then pocket copied to -updates.
>At this point users of -updates have a kernel which was compiled with an
>older compiler than the one they have. This is not desirable.
>
>There seem to be several simple options here:
>
>1) expect the users to build their own kernels if they want to use
> external modules, or
>2) update gcc in -security, and always do so, or
>3) have separate kernel builds for each pocket (rather than pocket copying
> the -security update into -updates, upload it there separatly with a
> higher upload number).
>
>I guess the security team is best placed to evaluate the safety or
>otherwise of (2).
>
>Thoughts?
>

It has to be #1 or #3. If -security were built with the -updates gcc, then
you've just reversed the problem and broken things for people who don't use
-updates. This is a supported use case (the reason -security is built from
-release).

I don't think #1 is a very Ubuntu approach and your #3 is the best solution.

Scott K

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Kernel Compiler missmatches
 

Andy Whitcroft schrieb:
> There seem to be several simple options here:
>
> 1) expect the users to build their own kernels if they want to use
> external modules, or
> 2) update gcc in -security, and always do so, or
> 3) have separate kernel builds for each pocket (rather than pocket copying
> the -security update into -updates, upload it there separatly with a
> higher upload number).
>
> I guess the security team is best placed to evaluate the safety or
> otherwise of (2).

4) Re-upload gcc-4.2 with the compiler version set back from 4.2.4
to 4.2.3, no other changes.

I don't know the system used to detect the differences for different compiler
versions, but could it be an option to ignore the subminor version number or
check for a version greater than?

Matthias


--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Kernel Compiler missmatches
 

Hi Doko, All,

On Fri, 13 Feb 2009 15:43:35 +0100
Matthias Klose <doko@ubuntu.com> wrote:

> Andy Whitcroft schrieb:
> > There seem to be several simple options here:
> >
> > 1) expect the users to build their own kernels if they want to use
> > external modules, or
> > 2) update gcc in -security, and always do so, or
> > 3) have separate kernel builds for each pocket (rather than pocket
> > copying the -security update into -updates, upload it there
> > separatly with a higher upload number).
> >
> > I guess the security team is best placed to evaluate the safety or
> > otherwise of (2).
>
> 4) Re-upload gcc-4.2 with the compiler version set back from 4.2.4
> to 4.2.3, no other changes.
>
> I don't know the system used to detect the differences for different
> compiler versions, but could it be an option to ignore the subminor
> version number or check for a version greater than?

The problem appears also for vmwaretools modules.

The vmware-config.pl script is crying that the compiler version is
different from the modules compiler version...but after all, if you
force it to compile, it does without a problem.

I think it's a disturbance for users, but regarding that the ABI of
the kernel is not changed it should not be a big problem.

But in the future, we need to ensure, that we have actually the same
gcc version numbers for kernel modules compiled with a gcc or as
proposed in 3) have different kernel packages compiled with the latest
gcc of the pocket.

Regards,

sh

--
Stephan 'sh' Hermann | OSS Developer &
Systemadministrator JID: sh@linux-server.org |
http://www.sourcecode.de/ GPG ID: 0xC098EFA8 |
http://leonov.tv/ 3D8B 5138 0852 DA7A B83F DCCB C189 E733 C098 EFA8

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Kernel Compiler missmatches
 

On Fri, Feb 13, 2009 at 09:33:37AM -0500, Scott Kitterman wrote:
> On Fri, 13 Feb 2009 12:06:56 +0000 Andy Whitcroft <apw@canonical.com> wrote:
> >We have a couple of reports indicating that following an update to Hardy
> >their exernal modules no longer build. Specifically those modules fail
> >to build because the version of gcc used to build the kernel and the one
> >installed and available to build the modules does not match. The kernel
> >highly recommends you use the same version, and most external modules
> >sensibly enforce this.
> >
> >This missmatch has been triggered in Hardy because we recently did a
> >security update to the kernel. That was built in the -security environment
> >which necesarily lacks any updates from -updates, and therefore has the
> >released version of gcc. This kernel was then pocket copied to -updates.
> >At this point users of -updates have a kernel which was compiled with an
> >older compiler than the one they have. This is not desirable.
> >
> >There seem to be several simple options here:
> >
> >1) expect the users to build their own kernels if they want to use
> > external modules, or
> >2) update gcc in -security, and always do so, or
> >3) have separate kernel builds for each pocket (rather than pocket copying
> > the -security update into -updates, upload it there separatly with a
> > higher upload number).
> >
> >I guess the security team is best placed to evaluate the safety or
> >otherwise of (2).
>
> It has to be #1 or #3. If -security were built with the -updates gcc, then
> you've just reversed the problem and broken things for people who don't use
> -updates. This is a supported use case (the reason -security is built from
> -release).

My suggestion was #2, because this means that (a) future kernel builds
happen with the newer gcc and (b) users who don't use -updates get the
new gcc so that their local module compiles will work. Furthermore I
think it's probably not particularly good to have divergent versions of
gcc between -security and -updates anyway.

You seem to discard #2, but your objections don't match my understanding
of this option. Do we have different understandings? I'm saying that we
should copy gcc into -security; you're objecting to building -security
using -updates, which isn't what Andy's #2 says.

I do think, given the known state of the kernel, that we should update
gcc in -security shortly before a kernel ABI change in -security, to
minimise practical problems. Furthermore, in light of this problem we
should avoid changing the visible upstream version of gcc in future
post-release updates, even if it is necessary to backport some upstream
changes.

--
Colin Watson [cjwatson@ubuntu.com]

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Kernel Compiler missmatches
 

On Fri, Feb 13, 2009 at 03:43:35PM +0100, Matthias Klose wrote:
> Andy Whitcroft schrieb:
> > There seem to be several simple options here:
> >
> > 1) expect the users to build their own kernels if they want to use
> > external modules, or
> > 2) update gcc in -security, and always do so, or
> > 3) have separate kernel builds for each pocket (rather than pocket copying
> > the -security update into -updates, upload it there separatly with a
> > higher upload number).
> >
> > I guess the security team is best placed to evaluate the safety or
> > otherwise of (2).
>
> 4) Re-upload gcc-4.2 with the compiler version set back from 4.2.4
> to 4.2.3, no other changes.

Given that 4.2.4 has been in -updates for some time, I'm concerned that
this would create another incompatibility and further confusion.
Presumably kernel build scripts will be no happier with a kernel
compiled with 4.2.4 and modules compiled with 4.2.3 than vice versa.

We should certainly take care to avoid this problem in future, but for
now perhaps it is simpler to push 4.2.4 into -security. However, I'd
like to have the security team's signoff for that.

--
Colin Watson [cjwatson@ubuntu.com]

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Kernel Compiler missmatches
 

On Tue, 17 Feb 2009 14:07:23 +0000 Colin Watson <cjwatson@ubuntu.com> wrote:
>On Fri, Feb 13, 2009 at 09:33:37AM -0500, Scott Kitterman wrote:
>> On Fri, 13 Feb 2009 12:06:56 +0000 Andy Whitcroft <apw@canonical.com>
wrote:
>> >We have a couple of reports indicating that following an update to Hardy
>> >their exernal modules no longer build. Specifically those modules fail
>> >to build because the version of gcc used to build the kernel and the one
>> >installed and available to build the modules does not match. The kernel
>> >highly recommends you use the same version, and most external modules
>> >sensibly enforce this.
>> >
>> >This missmatch has been triggered in Hardy because we recently did a
>> >security update to the kernel. That was built in the -security
environment
>> >which necesarily lacks any updates from -updates, and therefore has the
>> >released version of gcc. This kernel was then pocket copied to
-updates.
>> >At this point users of -updates have a kernel which was compiled with an
>> >older compiler than the one they have. This is not desirable.
>> >
>> >There seem to be several simple options here:
>> >
>> >1) expect the users to build their own kernels if they want to use
>> > external modules, or
>> >2) update gcc in -security, and always do so, or
>> >3) have separate kernel builds for each pocket (rather than pocket
copying
>> > the -security update into -updates, upload it there separatly with a
>> > higher upload number).
>> >
>> >I guess the security team is best placed to evaluate the safety or
>> >otherwise of (2).
>>
>> It has to be #1 or #3. If -security were built with the -updates gcc,
then
>> you've just reversed the problem and broken things for people who don't
use
>> -updates. This is a supported use case (the reason -security is built
from
>> -release).
>
>My suggestion was #2, because this means that (a) future kernel builds
>happen with the newer gcc and (b) users who don't use -updates get the
>new gcc so that their local module compiles will work. Furthermore I
>think it's probably not particularly good to have divergent versions of
>gcc between -security and -updates anyway.
>
>You seem to discard #2, but your objections don't match my understanding
>of this option. Do we have different understandings? I'm saying that we
>should copy gcc into -security; you're objecting to building -security
>using -updates, which isn't what Andy's #2 says.

I misread it the first time. Sorry about that.

>I do think, given the known state of the kernel, that we should update
>gcc in -security shortly before a kernel ABI change in -security, to
>minimise practical problems. Furthermore, in light of this problem we
>should avoid changing the visible upstream version of gcc in future
>post-release updates, even if it is necessary to backport some upstream
>changes.
>
OK. Nevermind about my objection.

Scott K

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Kernel Compiler missmatches
 

On Tue, Feb 17, 2009 at 02:09:36PM +0000, Colin Watson wrote:
> We should certainly take care to avoid this problem in future, but for
> now perhaps it is simpler to push 4.2.4 into -security. However, I'd
> like to have the security team's signoff for that.

I'm a little nervous about gcc-4.2 in hardy (there have been a
lot of changes -- 4 full changelogs since release). However, I am
rather interested in getting intrepid's gcc-4.3 updated in -security.
Given that gcc has extensive regression tests, and that we need to find
a way to fix the compiler skew problem, perhaps we can develop some kind
of additional process for promoting gcc into -security from -updates
(i.e. a longer waiting period or some series of better tests).

Traditionally, we always publish a USN for anything in main that appears in
-security. This is a bit tricky for gcc, since they're all strictly bug
fixes, not security issues. I'm not really sure how to "announce" the
appearance of gcc in -security.

-Kees

--
Kees Cook
Ubuntu Security Team

--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel