Is it possible to place a newer hardened-sources (>=2.6.30) in a portage tree? I have a hardware (onboard RTL8111 network card) which is making a panic on all <=2.6.29* (every 1-3 days), but it have been fixed in 2.6.30 (current uptime 70 days without kernel panic). I have next (with the same hardware) server, and I have to upgrade to >=2.6.30 and I don't want do it by hand. I'm using amd64. Reproducible: Always Steps to Reproduce:
Same question. I have an onboard ati radeon RS780 (ATI Technologies Inc Radeon HD 3200 Graphics) which need dri from >=2.6.30. I want to figure out xorg with this chip. I'm using amd64 too.
(In reply to comment #1) > Same question. > I have an onboard ati radeon RS780 (ATI Technologies Inc Radeon HD 3200 > Graphics) which need dri from >=2.6.30. I want to figure out xorg with this > chip. > I'm using amd64 too. > I add hardened-sources-2.6.31-r1 to the hardened-dev overlay last night please feel free to test it.
Thank you. I needed this too and the version in hardened-dev works great.
For me it is also working fine (-r2) and currently I'm testing -r3.
well, since 2.6.32 is already out, i'd dare to suggest to go for hardened-2.6.31 which has a more or less working btrfs support. i'd like to test how btrfs plays with hardened ... thanks
The existing hardened-sources in the main tree are quite dated. It would be nice to see a bump there.
*** Bug 302567 has been marked as a duplicate of this bug. ***
At *VERY* least, bump 2.6.29 to 2.6.29-r1 using version 8 of genpatches.
*bump* again, a new stable version for kernel-2.6.32.8 is out for about a week. Is somebody still maintaining the hardened-sources? It's kinda quiet in the hardened-overlay as well.
(In reply to comment #9) > *bump* > > again, a new stable version for kernel-2.6.32.8 > is out for about a week. Is somebody still > maintaining the hardened-sources? > It's kinda quiet in the hardened-overlay as well. > Sorry I step'd away from hardened for a bit with all my mozilla work. I am still working to resolve a few last issues along with changes gengor is wanting as well. Soon as it is ready we will get a bump in the tree.
I really don't mean to be rude, but is there a reason we can't add the ebuilds to the portage tree keyworded? It seems that would allow the development to proceed more naturally, give more folks access to testing new releases, and make the project seem far more alive.
I totally agree. Btw., there (again) is a newer stable version available (for kernel-2.6.32.10) for quite some time now.
(In reply to comment #11) > I really don't mean to be rude, but is there a reason we can't add the ebuilds > to the portage tree keyworded? It seems that would allow the development to > proceed more naturally, give more folks access to testing new releases, and > make the project seem far more alive. > As this would cause headaches for those wanting to use make oldconfig it will not happen. Just be patient we are working as fast as time permits. All the comments about it not being in the tree are useless. If you want to see this sooner then we can provide it you should join #gentoo-hardened and offer to help.
*** Bug 280610 has been marked as a duplicate of this bug. ***
Hm, now the ebuilds have even disappeared from the "hardened-development"-overlay. Is there something i should have read?
Re: Comment 15 http://thread.gmane.org/gmane.linux.gentoo.hardened/4414/focus=4419
My apologies - I meant instead to write: http://thread.gmane.org/gmane.linux.gentoo.hardened/4414/focus=4416
Oh please no, not yet another overlay. @Kerin: Thank you a lot for pointing that out.
For those interested, 2.6.33.3 is avaliable via my overlay, it reverts back to simple genpatch base and extra with grsecurity patch. This is much closer to that of what Brad ships.
On that note, here's a grsec-sources ebuild for those who might wish to make use of it. Its virtue is that it is very easy to bump. Simple change ${PVR} as appropriate, generate a new manifest and it does the rest. For the testing version, the SRC_URI needs to be slightly different so I'll attach two ebuilds. I'm using this personally; not only because of the hardened-sources stagnation, but also because genpatches is too slow on the uptake for my liking. I'd rather just follow the 2.6.32.x branch from upstream.
Created attachment 230185 [details] grsec-sources-2.6.32.12-r201005012055.ebuild
Created attachment 230187 [details] grsec-sources-2.6.33.3-r201005012055.ebuild
The sys-kernel/hardened-sources kernel in Portage: Latest stable: 2.6.28-r9 Latest testing: 2.6.29 Are these secure!? Hey! Wake up!!! According to the ChangeLog, the latest stable was added on 25 May, 2009. :D Its difficult to take Gentoo Hardened seriously because of such things... Why is this taking so long? Why not add 2.6.32 and 2.6.33 to ~testing?
Re: Comment 23 > Are these secure!? No, unfortunately they are not. At the very least, one would need to patch in the mmap_min_addr offset patch, which I backported to 2.6.28 and 2.6.29 quite a while ago (I'll attach both of these to the bug just to prove the point). Heaven knows what other issues there may be with them. Frankly, at this juncture it would be rather more circumspect to drop them from the tree entirely and suggest that users pull directly from kernel.org and grsecurity.net. I would not, however, hold my breath.
Created attachment 230721 [details, diff] 2.6.28 mmap_min_addr patch
Created attachment 230723 [details, diff] 2.6.29 mmap_min_addr patch
The ebuilds for 2.6.32 are now in the tree. These do not need the patches in Comments #25 and #26 which were included in the kernel since .31. The code has changed in .32 but you can see the check if ((addr < mmap_min_addr) && !capable(CAP_SYS_RAWIO)) in include/linux/security.h has been moved to cap_file_mmap in security/commoncap.c but achieves the same purpose. This bug should be closed.
This is in portage now Jacek, sorry for the wait.
@kerin millar FYI I'm using your "grsec-sources"-ebuild/template for quite some time now. Great work ;)
