Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
sys-kernel/gentoo-sources
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware
View previous topic :: View next topic  
Author Message
Xywa
Veteran
Veteran


Joined: 23 Jul 2005
Posts: 1631
Location: /mnt/Gentoo/Europe

PostPosted: Thu May 16, 2013 6:14 am    Post subject: sys-kernel/gentoo-sources Reply with quote

Hi,

From Yesterday we have such information here:
http://packages.gentoo.org/package/sys-kernel/gentoo-sources
Quote:
Users are adviced to upgrade to the latest kernel. Dropped amd64, x86 and hppa
keywords on affected 3.7.10 kernels as 3.8.13 has stabilized for them; dropped
testing keywords as well, since 3.7.10-r1 contains no more keywords it is
dropped from the tree. 3.7.10 still has some less common arches awaiting
3.8.13 stabilization.


...so I wont be able to use the kernel 3.7.10 (or any other 3.7) now.

So what about those people, for whom driver rtsx_pci (card reader) doesn't work from kernlel 3.8 till 3.9.2?
See the bug:
https://bugzilla.kernel.org/show_bug.cgi?id=57061

Should we use the old 3.4.5? Or maybe we shouldn't use built-in card reader at all, as no one at the moment is interested in fixing the driver in the kernel?
Back to top
View user's profile Send private message
aCOSwt
Bodhisattva
Bodhisattva


Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space

PostPosted: Thu May 16, 2013 7:24 am    Post subject: Re: sys-kernel/gentoo-sources Reply with quote

Xywa wrote:
Should we use the old 3.4.5?

Do you mean 3.4.45 ?
Then yes, this is advisable.
BTW, 3.4.45 is actually less than a week old.
And if it is working for you, why would you look for anything else ?
_________________
Back to top
View user's profile Send private message
Xywa
Veteran
Veteran


Joined: 23 Jul 2005
Posts: 1631
Location: /mnt/Gentoo/Europe

PostPosted: Thu May 16, 2013 10:03 am    Post subject: Re: sys-kernel/gentoo-sources Reply with quote

aCOSwt wrote:
Xywa wrote:
Should we use the old 3.4.5?

Do you mean 3.4.45 ?
Then yes, this is advisable.
BTW, 3.4.45 is actually less than a week old.
And if it is working for you, why would you look for anything else ?


Yes, I mean 3.4.45.

I mean 3.4 was relased in 21 May 2012 and 3.7 in 11 December 2012, so why should I leave the newer 3.7 (which was pretty fine for me for the last couple of months) into 3.4?
http://en.wikipedia.org/wiki/Linux_kernel
Back to top
View user's profile Send private message
aCOSwt
Bodhisattva
Bodhisattva


Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space

PostPosted: Thu May 16, 2013 10:25 am    Post subject: Re: sys-kernel/gentoo-sources Reply with quote

Xywa wrote:
why should I leave the newer 3.7

Absolutely nothing tells you that you should stop using 3.7 kernels.
Tom wrote:
Users are adviced to

Just you are informed that there are a couple of security issues in 3.7 kernels and, if you feel concerned with these issues, you might consider the opportunity to move to other available kernels known for not being impacted by these security issues.

BTW, I still get 2.6.38 systems running. (networkless) and I did not understand its disappearance from the portage tree as a sign that I should upgrade.
_________________
Back to top
View user's profile Send private message
shanew
n00b
n00b


Joined: 16 Sep 2006
Posts: 34
Location: Austin, TX

PostPosted: Thu May 16, 2013 4:08 pm    Post subject: Reply with quote

Note that the security issue is not limited to the 3.7 kernels, but runs up to 3.8.8, and more importantly all the way back as far as 2.6.37.
If you're not running a multi-user system or you absolutely positively trust the other users (and trust that no one can guess their passwords or otherwise access the system via their account), then you might be fine staying with an older kernel. But, if you're running a multi-user system, I would guess that preventing a local root exploit would be more important than a card reader.
Back to top
View user's profile Send private message
aCOSwt
Bodhisattva
Bodhisattva


Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space

PostPosted: Thu May 16, 2013 4:19 pm    Post subject: Reply with quote

shanew wrote:
more importantly all the way back as far as 2.6.37.

All the way back, all the way back...
apart from 3.4 >=3.4.42 / 3.2 >=3.2.45 / 3.0 > 3.0.75 that is also to say that you are in fact safe with "all the way back" in the gentoo-sources tree.
_________________
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 21490

PostPosted: Thu May 16, 2013 10:51 pm    Post subject: Reply with quote

aCOSwt wrote:
shanew wrote:
more importantly all the way back as far as 2.6.37.

All the way back, all the way back...
apart from 3.4 >=3.4.42 / 3.2 >=3.2.45 / 3.0 > 3.0.75 that is also to say that you are in fact safe with "all the way back" in the gentoo-sources tree.
Your post is a bit confusing, but I think you are trying to point out that there exist recent stable releases of old kernels and that such recent stable release have the fix. This is true, but it does not invalidate the quoted portion. The point shanew was trying to convey is that the bug is present in every major kernel release from 2.6.37 onward, so picking older kernels only makes sense if you pick a stable release of that kernel with the fix. Given the simplicity of the fix, anyone willing to use patch can backport the fix into a kernel of their choosing. The OP might consider doing this if he is determined to continue to use 3.7.10. However, I should point out that given how long 3.7 has been EOL, some fixes in 3.8 may be security fixes that ought to be in 3.7, which the OP would be missing by a selective backport. I am not aware of any fixes marked as such, but then the fix that triggered this thread was not all that well marked either.
Back to top
View user's profile Send private message
aCOSwt
Bodhisattva
Bodhisattva


Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space

PostPosted: Thu May 16, 2013 11:11 pm    Post subject: Reply with quote

Hu wrote:
it does not invalidate the quoted portion.

It does.
The title of this thread is "sys-kernel/gentoo-sources".
All the way back from 3.7.10 in sys-kernel/gentoo-sources have the fix.
_________________
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 21490

PostPosted: Fri May 17, 2013 1:39 am    Post subject: Reply with quote

aCOSwt wrote:
Hu wrote:
it does not invalidate the quoted portion.

It does.
The title of this thread is "sys-kernel/gentoo-sources".
All the way back from 3.7.10 in sys-kernel/gentoo-sources have the fix.
As best I can tell, v3.7.10, both vanilla and Gentoo, is affected. If you disagree, please provide a specific citation. Additionally, shanew stated, and I reiterated, that the offending commit is present in the major release of every kernel down to 2.6.37, so barring a specific patch to resolve the problem, every kernel version since then is affected. As I also stated, some kernel series have received a backported patch to fix the issue. Recent kernel 3.8 and kernel 3.9 series are known to have the fix. Others may also have it, and the fix could be easily backported.

By my analysis, vanilla v3.7.10 is affected:
Code:
$ git show v3.7.10:kernel/events/core.c | grep -A5 \ perf_swevent_init\(
static int perf_swevent_init(struct perf_event *event)
{
        int event_id = event->attr.config;

        if (event->attr.type != PERF_TYPE_SOFTWARE)
                return -ENOENT;
Current Subversion revision for the gentoo-sources patches is 2378. Most recent Subversion revision in which gentoo-sources patches for directory 3.7 were modified is 2315. None of the gentoo-sources patches visible in the 3.7 directory as of that revision appear to be relevant to the problem under discussion.
Back to top
View user's profile Send private message
aCOSwt
Bodhisattva
Bodhisattva


Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space

PostPosted: Fri May 17, 2013 5:54 am    Post subject: Reply with quote

Hu wrote:
As best I can tell, v3.7.10, both vanilla and Gentoo, is affected. If you disagree, please provide a specific citation.

Then... I will, quote... myself!
aCOSwt wrote:
you are informed that there are a couple of security issues in 3.7 kernels

That is no more no less than what I write in my second post.
We are since, uselessly IMNSHO, arguing about the way back from the 3.7 as emergeable from sys-kernel/gentoo-sources.

Of course if that makes you happy to demonstrate evidences, I am perfectly fine with this but I am still personally convinced that life is far too short for arguing about them.

Edit : btw of verbi gratia :

I personally posted here with the sole intention to help the OP. *NOT* to demonstrate that I am correct.
Help that I will summarize the following way :

a/ No, you should not stop using sys-kernel/gentoo-sources-3.7.10, you are only adviced to.
b/ sys-kernel/gentoo-sources-3.7.10 is concerned by a couple of security related issues you might feel concerned with depending on what you use your system for and its environment.
c/ If your device is correctly supported under <sys-kernel/gentoo-sources-3.7.10 kernels, then you can select anyone of the <sys-kernel/gentoo-sources-3.7.10 kernels. All of them are safe with regards to the above mentioned security issues.
_________________
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 21490

PostPosted: Sat May 18, 2013 12:56 am    Post subject: Reply with quote

aCOSwt wrote:
c/ If your device is correctly supported under <sys-kernel/gentoo-sources-3.7.10 kernels, then you can select anyone of the <sys-kernel/gentoo-sources-3.7.10 kernels. All of them are safe with regards to the above mentioned security issues.
You quoted yourself claiming that 3.7.10 is unaffected, but as I showed, vanilla v3.7.10 is affected. When I requested a citation, I wanted you to either quote a third party who specifically contradicts me with evidence showing where I am wrong or to otherwise provide a specific reason why it is incorrect for me to state that the PERF_EVENTS security bug is not applicable. I might also accept a third party quote contradicting me without evidence if it came from a community figure generally known to be an expert in the area, such as a maintainer of a publicly visible stable kernel or a maintainer of the subsystem in question. Quoting your own earlier post where you made that claim, without providing evidence in the original post or in the quoting post, does not advance your position. I found no evidence that Gentoo v3.7.10 carries a patch that would make it unaffected. Therefore, with regard to the security issue which triggered the thread, v3.7.10 is not safe.
Back to top
View user's profile Send private message
kurly
Apprentice
Apprentice


Joined: 02 Apr 2012
Posts: 260

PostPosted: Sat May 18, 2013 1:17 am    Post subject: Reply with quote

You two seem to be talking past each other.

All versions less than 3.7.10 (I assume that's what aCOSwt means by the "<" symbol) available under sys-kernel/gentoo-sources (assuming you have sync'd portage lately) today are safe. The version 3.7.10 no longer has keywords for the most common arches (amd64, x86). 3.7.10 is vulnerable and will be removed altogether as soon as the less common arches get around to stabilizing 3.8.13. This has been documented in Bug 469854.

If you run amd64 or x86, whether stable or ~arch, you are safe to use any keyworded version of sys-kernel/gentoo-sources, since the only remaining affected version is no longer available for your arch. If you decide to unmask it despite being keyword-masked, then you risk trouble.

3.7.10 is not safe on any architecture. All other gentoo-sources kernels are safe. To be super clear, as of the time of this writing, that includes 3.0.75-3.0.78, 3.2.45, 3.4.42-3.4.45, 3.8.9-3.8.13, 3.9.0-3.9.2.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 21490

PostPosted: Sat May 18, 2013 6:07 pm    Post subject: Reply with quote

kurly wrote:
All versions less than 3.7.10 (I assume that's what aCOSwt means by the "<" symbol) available under sys-kernel/gentoo-sources (assuming you have sync'd portage lately) today are safe. The version 3.7.10 no longer has keywords for the most common arches (amd64, x86). 3.7.10 is vulnerable and will be removed altogether as soon as the less common arches get around to stabilizing 3.8.13. This has been documented in Bug 469854.

If you run amd64 or x86, whether stable or ~arch, you are safe to use any keyworded version of sys-kernel/gentoo-sources, since the only remaining affected version is no longer available for your arch. If you decide to unmask it despite being keyword-masked, then you risk trouble.

3.7.10 is not safe on any architecture. All other gentoo-sources kernels are safe. To be super clear, as of the time of this writing, that includes 3.0.75-3.0.78, 3.2.45, 3.4.42-3.4.45, 3.8.9-3.8.13, 3.9.0-3.9.2.
Thank you. I read aCOSwt's posts to be a claim that v3.7.10 was safe and that the OP could pick any older kernel he liked (that is, any kernel matching v3.0.N, v3.1.N, etc. for any N) as safe, neither of which were true. The qualifiers you impose regarding recent sync and selecting only kernels still available for emerge when using a recent tree restrict the set to ones which should be safe.
Back to top
View user's profile Send private message
jasn
Guru
Guru


Joined: 05 May 2005
Posts: 439
Location: Maryland, US

PostPosted: Sat May 18, 2013 11:14 pm    Post subject: Reply with quote

Well then..

I have to ask..

Is it safe?

:wink:
Back to top
View user's profile Send private message
wcg
Guru
Guru


Joined: 06 Jan 2009
Posts: 588

PostPosted: Sun May 19, 2013 7:52 pm    Post subject: Reply with quote

Is there a GLSA for these kernel security issues? I am wondering if the
security vulnerability or vulnerabilities only exist in 3.7.10 kernels that have
perf enabled.
_________________
TIA
Back to top
View user's profile Send private message
jasn
Guru
Guru


Joined: 05 May 2005
Posts: 439
Location: Maryland, US

PostPosted: Sun May 19, 2013 8:47 pm    Post subject: Reply with quote

wcg wrote:
Is there a GLSA for these kernel security issues?

No GLSA yet. Just this bug report, and also this other forum thread.
wcg wrote:
I am wondering if the security vulnerability or vulnerabilities only exist in 3.7.10 kernels that have perf enabled.

As pointed out in at least the other forum thread, affected linux kernels include 2.6.37 through 3.8.9 and you are correct in that in order for the vulnerability to exist, it requires the kernel to be compiled with PERF_EVENTS enabled.

Good Luck..
Back to top
View user's profile Send private message
wcg
Guru
Guru


Joined: 06 Jan 2009
Posts: 588

PostPosted: Mon May 20, 2013 6:18 am    Post subject: Reply with quote

[PERF_EVENTS]
Ah. Looking in make menuconfig, this option cannot be disabled from there
in 3.7.10. (It is not an option, menuconfig enables it unconditionally in that
kernel. One would need to search all of the Kconfig files in the kernel source
tree to see what else depends on it before disabling it manually, simply
by editing .config before compiling the kernel.)

Thanks for the explanation.
_________________
TIA
Back to top
View user's profile Send private message
wcg
Guru
Guru


Joined: 06 Jan 2009
Posts: 588

PostPosted: Tue May 21, 2013 3:52 pm    Post subject: Reply with quote

This URL explains how the vulnerability could be exploited:
http://www.reddit.com/r/netsec/comments/1eb9iw/sdfucksheeporgs_semtexc_local_linux_root_exploit/c9ykrck

If one needs to use a kernel that is "not fixed" for this
vulnerability for hardware reasons (drivers for your hardware
work in some not fixed kernels but not in any of the
kernels that have this vulnerability patched), the easiest
thing to do would be to patch the kernel bug yourself.
The patches that I have seen that actually close the vulnerability
are very small and self-contained. They are like "don't
check this 64-bit value as if it were a 32-bit type in this
one spot in the kernel code." And that's it. You don't even
need patch. It is such a small change one could do it with
nano and get it right.

This would be the least disruptive imho, because you don't
have to make any adjustments to your otherwise working
kernel .config.

(make menuconfig probably enables PERF_EVENTS unconditionally
because more than just perf ("performance testing") uses code enabled
by it, including something that would break the kernel if it were disabled.)

(As for 3.8.13, linux-headers-3.8 is still in testing rather than stable. So
what changes are there from linux-headers-3.7 to linux-headers-3.8?
Do any of them break glibc, util-linux, iptables, openssh, or sysvinit?
Etc.)
_________________
TIA
Back to top
View user's profile Send private message
TomWij
Retired Dev
Retired Dev


Joined: 04 Jul 2012
Posts: 1553

PostPosted: Tue May 21, 2013 8:19 pm    Post subject: Reply with quote

Just to be clear, all versions currently in the Portage tree are not vulnerable to this except for 3.7.10 which awaits 3.8.13 stabilization on less important arches, all other vulnerable versions were removed.
Back to top
View user's profile Send private message
wcg
Guru
Guru


Joined: 06 Jan 2009
Posts: 588

PostPosted: Wed May 22, 2013 11:52 pm    Post subject: Reply with quote

fyi, this is the patch to fix it (in the quoted section of this message):
http://lkml.indiana.edu/hypermail/linux/kernel/1304.1/04302.html

So, to fix this vulnerability in a particular kernel that has it,
find /usr/src/linux/kernel/events/core.c, edit that file and
find the line:
Code:

int event_id = event->attr.config;


Change the "int" to "u64", save the file, and recompile and reinstall
your kernel. You will no longer have this PERF_EVENTS vulnerability.
_________________
TIA
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum