Re: [gentoo-kernel] vanilla-kernel sources should not be marked stable for obsolete versions

[Anthony G. Basile]

On 06/22/2013 10:43 AM, Greg KH wrote:
> On Sat, Jun 22, 2013 at 04:56:39AM -0400, Anthony G. Basile wrote:
>> On 06/21/2013 11:47 PM, Greg KH wrote:
>>> On Fri, Jun 21, 2013 at 09:54:46PM -0400, Anthony G. Basile wrote:
>>>> The bug where this was discussed is
>>>>
>>>> https://bugs.gentoo.org/show_bug.cgi?id=338739
>>> Thanks for the link, unfortunatly, things have changed since then, with
>>> stable kernel releases happening much more frequently now (instead of
>>> about ever 2-3 weeks, it's now, 1-2 releases a week.
>>>
>>> So the chance for an arch team to mark anything is going to be tough.
>>>
>>> greg k-h
>>>
>> I've been following, but I can't say I've been following closely.
>> I'm on the stable{,-commits}@vger list and the rate at which this
>> stuff is coming is too fast for human consumption.
> So, as I am the one creating all of that "stuff", does that mean I'm
> somehow not "human"?  :)

Yes, yes it does :)  I was one of your 40 elect when you needed minion, 
but I just can't with all my other duties.

>
>> We could just drop stabilization of vanilla-sources and have people
>> follow ~arch.  That might be closer to the meaning of ~testing vs
>> stable in other packages: other upstreams push out releases they
>> consider stable, but we don't consider them stable within Gentoo
>> until our QA team tests.
> I agree.
>
>> Another reason for dropping all vanilla-sources to ~arch is that we
>> have some Gentoo specific needs that upstream will not and should
>> not accept, eg we are making greater use of extended attributes in
>> our package management, so we need end-to-end copying of xattrs.
>> This means preserving certain namespaces (beyond security.* and
>> trusted.*) on tmpfs for emerge.  Gentoo users that use
>> vanilla-sources will loose those xattr values making vanilla-sources
>> ~ with respect to the rest of Gentoo.
> What?  So we are now relying on kernel patches that are not merged
> upstream for proper operation of at Gentoo-based system?  That's news to
> me, I've _never_ run a gentoo-based kernel on my boxes in all of my
> years as a Gentoo developer, with no problems, and I don't think we want
> to require this in the future, do you?

Its related to PaX coming form the grsec/pax team.

>
> Also, why aren't these patches upstream?  Were they rejected?  Just not
> ready?  No one submitted them?

We need to maintain a special namespace on tmpfs beyond security.* and 
trusted.*  It is "user.pax.flags" and it is limited to 8 bytes. Without 
it, we will not have end-to-end xattr support for the namespaces we need 
in Gentoo.

As for why they are not upstream, I can try.  I'm like 99.9% certain it 
will be rejected but at the very least, if the rejection is "we don't 
need that crap" then I can safely ignore it, but if the rejection is 
"there's a gapping security whole" then we can at least address it even 
if in the end they pulled into vanilla.

>
> Don't ever try to differentiate at the kernel level from other distros,
> it's not worth it, and will cause problems in the end.  The other
> distros have realized this, I thought we were smarter than that...

Like the 50k line patch that Brad spews out every other day?  I 
understand your point but grsec/pax has a large enough user base and 
we've supported it for 10 years now.

As for not differentiating at the kernel level, our choice here was 
either that or differentiate at the toolchain level.  Try readelf -l on 
any Gentoo elf object and tell me what you see different than, oh say, 
OpenSuse.  A 5 line patch to mm/shmem.c in the kernel is a small price 
to pay for cleaning up the program headers of our elf objects 
userland-wide.  *That* will bring Genoo in line with other linux distros.

>
> thanks,
>
> greg k-h
>


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@g.o
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA