[gentoo-hardened] Please test hardened-sources 2.6.32-r88 and 3.2.2

[gentoo-hardened] Please test hardened-sources 2.6.32-r88 and 3.2.2

[Anthony G. Basile]

Hi everyone,

I just added hardened-sources 2.6.32-r88 and 3.2.2 to the tree.  They 
address CVE-2012-0056.  I've tested and they do indeed resist the 
exploit.  I will be stabilizing them within 24 hours.  However, I feel 
very uncomfortable doing so because I don't want to trade one set of 
problems with another.  If anyone has time to test, let me know if you 
encounter any issues.

-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

Re: [gentoo-hardened] Please test hardened-sources 2.6.32-r88 and 3.2.2

["Tóth Attila"]

I've just had this one while booting hardened-3.2.1:
Jan 27 16:40:29 atoth kernel: vmalloc: allocation failure: 0 bytes
Jan 27 16:40:29 atoth kernel: modprobe: page allocation failure: order:0,
mode:0x80d2
Jan 27 16:40:29 atoth kernel: Pid: 7460, comm: modprobe Not tainted
3.2.1-hardened #1
Jan 27 16:40:29 atoth kernel: Call Trace:
Jan 27 16:40:29 atoth kernel: [<000080d2>] ? match_id.clone.1+0x62/0x90
Jan 27 16:40:29 atoth kernel: [<000a0e1f>] ? warn_alloc_failed+0xbf/0x100
Jan 27 16:40:29 atoth kernel: [<000080d2>] ? match_id.clone.1+0x62/0x90
Jan 27 16:40:29 atoth kernel: [<000c3cc3>] ? __vmalloc_node_range+0x1a3/0x240
Jan 27 16:40:29 atoth kernel: [<000080d2>] ? match_id.clone.1+0x62/0x90
Jan 27 16:40:29 atoth kernel: [<00637cb5>] ?
__mutex_lock_slowpath+0x1a5/0x240
Jan 27 16:40:29 atoth kernel: [<00020b8e>] ? module_alloc+0x7e/0x90
Jan 27 16:40:29 atoth kernel: [<000080d2>] ? match_id.clone.1+0x62/0x90
Jan 27 16:40:29 atoth kernel: [<000728a3>] ?
module_alloc_update_bounds_rw+0x13/0x60
Jan 27 16:40:29 atoth kernel: [<000728a3>] ?
module_alloc_update_bounds_rw+0x13/0x60
Jan 27 16:40:29 atoth kernel: [<00073196>] ? load_module+0x886/0x1b70
Jan 27 16:40:29 atoth kernel: [<00002c59>] ? __switch_to+0xb9/0x210
Jan 27 16:40:29 atoth kernel: [<000744ca>] ? sys_init_module+0x4a/0x1d0
Jan 27 16:40:29 atoth kernel: [<00010246>] ? switch_to_new_gdt+0x26/0x30
Jan 27 16:40:29 atoth kernel: [<00638d71>] ? syscall_call+0x7/0xb
Jan 27 16:40:29 atoth kernel: [<00002c59>] ? __switch_to+0xb9/0x210
Jan 27 16:40:29 atoth kernel: [<00010246>] ? switch_to_new_gdt+0x26/0x30

It's there for every module loading. Even though modules seems to work.
Strange. The kernel also didn't logged the first page of dmesg in
kernel.log.

I don't experience this using hardened-3.1.8.
I don't know if it's a known problem. I'll try hardened-3.2.2 later.

Thanks:
Dw.
-- 
dr Tóth Attila, Radiológus, 06-20-825-8057
Attila Toth MD, Radiologist, +36-20-825-8057

2012.Január 27.(P) 14:37 időpontban Anthony G. Basile ezt írta:
> Hi everyone,
>
> I just added hardened-sources 2.6.32-r88 and 3.2.2 to the tree.  They
> address CVE-2012-0056.  I've tested and they do indeed resist the
> exploit.  I will be stabilizing them within 24 hours.  However, I feel
> very uncomfortable doing so because I don't want to trade one set of
> problems with another.  If anyone has time to test, let me know if you
> encounter any issues.
>
> --
> Anthony G. Basile, Ph. D.
> Chair of Information Technology
> D'Youville College
> Buffalo, NY 14201
> (716) 829-8197
>

Re: [gentoo-hardened] Please test hardened-sources 2.6.32-r88 and 3.2.2

["Tóth Attila"]

And this one is from my laptop:
vmalloc: allocation failure: 0 bytes
modprobe: page allocation failure: order:0, mode:0x80d2
Pid: 3157, comm: modprobe Tainted: G           O 3.2.1-hardened #1
Call Trace:
 [<000080d2>] ? old_ich_force_enable_hpet+0x52/0x140
 [<0008922b>] ? warn_alloc_failed+0xbb/0x100
 [<000080d2>] ? old_ich_force_enable_hpet+0x52/0x140
 [<000a8a11>] ? __vmalloc_node_range+0x1c1/0x260
 [<000080d2>] ? old_ich_force_enable_hpet+0x52/0x140
 [<0001ac3e>] ? module_alloc+0x7e/0x90
 [<000080d2>] ? old_ich_force_enable_hpet+0x52/0x140
 [<00060053>] ? module_alloc_update_bounds_rw+0x13/0x60
 [<00060053>] ? module_alloc_update_bounds_rw+0x13/0x60
 [<00060ac1>] ? sys_init_module+0xa01/0x1af0
 [<000051f4>] ? smp_x86_platform_ipi+0x44/0x60
 [<0000297c>] ? prepare_to_copy+0xc/0xb0
 [<0000299c>] ? prepare_to_copy+0x2c/0xb0
 [<0061396c>] ? syscall_call+0x7/0xb
 [<000051f4>] ? smp_x86_platform_ipi+0x44/0x60
 [<0001f7e0>] ? vmalloc_sync_all+0xf0/0xf0
 [<0061398c>] ? restore_all_pax+0xc/0xc
 [<0061007b>] ? snd_intel8x0m_probe+0x36e/0x635
 [<00010202>] ? x86_schedule_events+0x122/0x2c0
 [<00010202>] ? x86_schedule_events+0x122/0x2c0
Mem-Info:
DMA per-cpu:
CPU    0: hi:    0, btch:   1 usd:   0
Normal per-cpu:
CPU    0: hi:  186, btch:  31 usd: 126
HighMem per-cpu:
CPU    0: hi:  186, btch:  31 usd:  31
active_anon:523 inactive_anon:72 isolated_anon:0
 active_file:2369 inactive_file:2790 isolated_file:0
 unevictable:0 dirty:11 writeback:0 unstable:0
 free:502375 slab_reclaimable:625 slab_unreclaimable:1183
 mapped:570 shmem:89 pagetables:59 bounce:0
DMA free:15928kB min:64kB low:80kB high:96kB active_anon:0kB
inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB
isolated(anon):0kB isolated(file):0kB present:15804kB mlocked:0kB
dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB
slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB
bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 865 2015 2015
Normal free:826824kB min:3728kB low:4660kB high:5592kB active_anon:0kB
inactive_anon:0kB active_file:1716kB inactive_file:1444kB unevictable:0kB
isolated(anon):0kB isolated(file):0kB present:885944kB mlocked:0kB
dirty:44kB writeback:0kB mapped:4kB shmem:0kB slab_reclaimable:2500kB
slab_unreclaimable:4732kB kernel_stack:488kB pagetables:236kB unstable:0kB
bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 9202 9202
HighMem free:1166748kB min:512kB low:1748kB high:2988kB active_anon:2092kB
inactive_anon:288kB active_file:7760kB inactive_file:9716kB
unevictable:0kB isolated(anon):0kB isolated(file):0kB present:1177932kB
mlocked:0kB dirty:0kB writeback:0kB mapped:2276kB shmem:356kB
slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB
pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0
all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
DMA: 0*4kB 1*8kB 1*16kB 1*32kB 2*64kB 1*128kB 1*256kB 0*512kB 1*1024kB
1*2048kB 3*4096kB = 15928kB
Normal: 116*4kB 67*8kB 46*16kB 10*32kB 5*64kB 3*128kB 3*256kB 0*512kB
2*1024kB 3*2048kB 199*4096kB = 826824kB
HighMem: 1*4kB 69*8kB 85*16kB 33*32kB 16*64kB 2*128kB 3*256kB 3*512kB
1*1024kB 2*2048kB 282*4096kB = 1166748kB
5258 total pagecache pages
0 pages in swap cache
Swap cache stats: add 0, delete 0, find 0/0
Free swap  = 0kB
Total swap = 0kB
524112 pages RAM
296802 pages HighMem
12058 pages reserved
3473 pages shared
7713 pages non-shared

But modules are still get loaded somehow and working.
-- 
dr Tóth Attila, Radiológus, 06-20-825-8057
Attila Toth MD, Radiologist, +36-20-825-8057

2012.Január 27.(P) 17:02 időpontban "Tóth Attila" ezt írta:
> I've just had this one while booting hardened-3.2.1:
> Jan 27 16:40:29 atoth kernel: vmalloc: allocation failure: 0 bytes
> Jan 27 16:40:29 atoth kernel: modprobe: page allocation failure: order:0,
> mode:0x80d2
> Jan 27 16:40:29 atoth kernel: Pid: 7460, comm: modprobe Not tainted
> 3.2.1-hardened #1
> Jan 27 16:40:29 atoth kernel: Call Trace:
> Jan 27 16:40:29 atoth kernel: [<000080d2>] ? match_id.clone.1+0x62/0x90
> Jan 27 16:40:29 atoth kernel: [<000a0e1f>] ? warn_alloc_failed+0xbf/0x100
> Jan 27 16:40:29 atoth kernel: [<000080d2>] ? match_id.clone.1+0x62/0x90
> Jan 27 16:40:29 atoth kernel: [<000c3cc3>] ?
> __vmalloc_node_range+0x1a3/0x240
> Jan 27 16:40:29 atoth kernel: [<000080d2>] ? match_id.clone.1+0x62/0x90
> Jan 27 16:40:29 atoth kernel: [<00637cb5>] ?
> __mutex_lock_slowpath+0x1a5/0x240
> Jan 27 16:40:29 atoth kernel: [<00020b8e>] ? module_alloc+0x7e/0x90
> Jan 27 16:40:29 atoth kernel: [<000080d2>] ? match_id.clone.1+0x62/0x90
> Jan 27 16:40:29 atoth kernel: [<000728a3>] ?
> module_alloc_update_bounds_rw+0x13/0x60
> Jan 27 16:40:29 atoth kernel: [<000728a3>] ?
> module_alloc_update_bounds_rw+0x13/0x60
> Jan 27 16:40:29 atoth kernel: [<00073196>] ? load_module+0x886/0x1b70
> Jan 27 16:40:29 atoth kernel: [<00002c59>] ? __switch_to+0xb9/0x210
> Jan 27 16:40:29 atoth kernel: [<000744ca>] ? sys_init_module+0x4a/0x1d0
> Jan 27 16:40:29 atoth kernel: [<00010246>] ? switch_to_new_gdt+0x26/0x30
> Jan 27 16:40:29 atoth kernel: [<00638d71>] ? syscall_call+0x7/0xb
> Jan 27 16:40:29 atoth kernel: [<00002c59>] ? __switch_to+0xb9/0x210
> Jan 27 16:40:29 atoth kernel: [<00010246>] ? switch_to_new_gdt+0x26/0x30
>
> It's there for every module loading. Even though modules seems to work.
> Strange. The kernel also didn't logged the first page of dmesg in
> kernel.log.
>
> I don't experience this using hardened-3.1.8.
> I don't know if it's a known problem. I'll try hardened-3.2.2 later.
>
> Thanks:
> Dw.
> --
> dr Tóth Attila, Radiológus, 06-20-825-8057
> Attila Toth MD, Radiologist, +36-20-825-8057
>
> 2012.Január 27.(P) 14:37 időpontban Anthony G. Basile ezt írta:
>> Hi everyone,
>>
>> I just added hardened-sources 2.6.32-r88 and 3.2.2 to the tree.  They
>> address CVE-2012-0056.  I've tested and they do indeed resist the
>> exploit.  I will be stabilizing them within 24 hours.  However, I feel
>> very uncomfortable doing so because I don't want to trade one set of
>> problems with another.  If anyone has time to test, let me know if you
>> encounter any issues.
>>
>> --
>> Anthony G. Basile, Ph. D.
>> Chair of Information Technology
>> D'Youville College
>> Buffalo, NY 14201
>> (716) 829-8197
>>
>
>
>
>

Re: [gentoo-hardened] Please test hardened-sources 2.6.32-r88 and3.2.2

[radegand]

[-- Attachment #1: Type: text/plain, Size: 740 bytes --]

Dnia 27 stycznia 2012 17:06 "Tóth Attila" <atoth@atoth.sote.hu> napisał(a):

> And this one is from my laptop:
> vmalloc: allocation failure: 0 bytes
> modprobe: page allocation failure: order:0, mode:0x80d2
> Pid: 3157, comm: modprobe Tainted: G           O 3.2.1-hardened #1
> Call Trace:
> 
> But modules are still get loaded somehow and working.
> 

Hi,

I'm getting similar errors on 3.2.2-hardened, amd64, core2duo, system seems to be working fine, but the errors look rather ugly, please see the attached snippet from the logs.

uname -a:
Linux hypercube3 3.2.2-hardened #1 SMP PREEMPT Fri Jan 27 17:03:59 GMT 2012 x86_64 Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz GenuineIntel GNU/Linux

Cheers,
Radek Madej


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 3.2.2-hardened_kern.log --]
[-- Type: text/x-log; name="3.2.2-hardened_kern.log", Size: 4777 bytes --]

Jan 27 16:56:59 hypercube3 kernel: udev[5255]: starting version 164
Jan 27 16:56:59 hypercube3 kernel: warn_alloc_failed: 43 callbacks suppressed
Jan 27 16:56:59 hypercube3 kernel: vmalloc: allocation failure: 0 bytes
Jan 27 16:56:59 hypercube3 kernel: modprobe: page allocation failure: order:0, mode:0x80d2
Jan 27 16:56:59 hypercube3 kernel: Pid: 5322, comm: modprobe Not tainted 3.2.2-hardened #1
Jan 27 16:56:59 hypercube3 kernel: Call Trace:
Jan 27 16:56:59 hypercube3 kernel: [<ffffffff810a335c>] ? 0xffffffff810a335c
Jan 27 16:56:59 hypercube3 kernel: [<ffffffff810c9dc8>] ? 0xffffffff810c9dc8
Jan 27 16:56:59 hypercube3 kernel: [<ffffffff8107f7b9>] ? 0xffffffff8107f7b9
Jan 27 16:56:59 hypercube3 kernel: [<ffffffff81028609>] ? 0xffffffff81028609
Jan 27 16:56:59 hypercube3 kernel: [<ffffffff8107f7b9>] ? 0xffffffff8107f7b9
Jan 27 16:56:59 hypercube3 kernel: [<ffffffff8107f7b9>] ? 0xffffffff8107f7b9
Jan 27 16:56:59 hypercube3 kernel: [<ffffffff81080424>] ? 0xffffffff81080424
Jan 27 16:56:59 hypercube3 kernel: [<ffffffff81080df2>] ? 0xffffffff81080df2
Jan 27 16:56:59 hypercube3 kernel: [<ffffffff815857bd>] ? 0xffffffff815857bd
Jan 27 16:56:59 hypercube3 kernel: Mem-Info:
Jan 27 16:56:59 hypercube3 kernel: DMA per-cpu:
Jan 27 16:56:59 hypercube3 kernel: CPU    0: hi:    0, btch:   1 usd:   0
Jan 27 16:56:59 hypercube3 kernel: CPU    1: hi:    0, btch:   1 usd:   0
Jan 27 16:56:59 hypercube3 kernel: DMA32 per-cpu:
Jan 27 16:56:59 hypercube3 kernel: CPU    0: hi:  186, btch:  31 usd: 198
Jan 27 16:56:59 hypercube3 kernel: CPU    1: hi:  186, btch:  31 usd:  12
Jan 27 16:56:59 hypercube3 kernel: Normal per-cpu:
Jan 27 16:56:59 hypercube3 kernel: CPU    0: hi:  186, btch:  31 usd: 122
Jan 27 16:56:59 hypercube3 kernel: CPU    1: hi:  186, btch:  31 usd:  31
Jan 27 16:56:59 hypercube3 kernel: active_anon:4880 inactive_anon:1944 isolated_anon:0
Jan 27 16:56:59 hypercube3 kernel: active_file:1062 inactive_file:5692 isolated_file:0
Jan 27 16:56:59 hypercube3 kernel: unevictable:0 dirty:0 writeback:0 unstable:0
Jan 27 16:56:59 hypercube3 kernel: free:1485613 slab_reclaimable:1279 slab_unreclaimable:2785
Jan 27 16:56:59 hypercube3 kernel: mapped:609 shmem:1956 pagetables:1405 bounce:0
Jan 27 16:56:59 hypercube3 kernel: DMA free:15924kB min:24kB low:28kB high:36kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15700kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
Jan 27 16:56:59 hypercube3 kernel: lowmem_reserve[]: 0 2927 5957 5957
Jan 27 16:56:59 hypercube3 kernel: DMA32 free:2980700kB min:4848kB low:6060kB high:7272kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:2998144kB mlocked:0kB dirty:0kB writeback:0kB mapped:4kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
Jan 27 16:56:59 hypercube3 kernel: lowmem_reserve[]: 0 0 3030 3030
Jan 27 16:56:59 hypercube3 kernel: Normal free:2945828kB min:5016kB low:6268kB high:7524kB active_anon:19520kB inactive_anon:7776kB active_file:4248kB inactive_file:22768kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:3102720kB mlocked:0kB dirty:0kB writeback:0kB mapped:2432kB shmem:7824kB slab_reclaimable:5116kB slab_unreclaimable:11140kB kernel_stack:1904kB pagetables:5620kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
Jan 27 16:56:59 hypercube3 kernel: lowmem_reserve[]: 0 0 0 0
Jan 27 16:56:59 hypercube3 kernel: DMA: 1*4kB 0*8kB 1*16kB 1*32kB 2*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB 3*4096kB = 15924kB
Jan 27 16:56:59 hypercube3 kernel: DMA32: 7*4kB 8*8kB 4*16kB 4*32kB 3*64kB 5*128kB 5*256kB 7*512kB 7*1024kB 5*2048kB 722*4096kB = 2980700kB
Jan 27 16:56:59 hypercube3 kernel: Normal: 1*4kB 21*8kB 16*16kB 3*32kB 1*64kB 0*128kB 1*256kB 0*512kB 2*1024kB 1*2048kB 718*4096kB = 2945868kB
Jan 27 16:56:59 hypercube3 kernel: 8768 total pagecache pages
Jan 27 16:56:59 hypercube3 kernel: 0 pages in swap cache
Jan 27 16:56:59 hypercube3 kernel: Swap cache stats: add 0, delete 0, find 0/0
Jan 27 16:56:59 hypercube3 kernel: Free swap  = 0kB
Jan 27 16:56:59 hypercube3 kernel: Total swap = 0kB
Jan 27 16:56:59 hypercube3 kernel: vmalloc: allocation failure: 0 bytes
Jan 27 16:56:59 hypercube3 kernel: modprobe: page allocation failure: order:0, mode:0x80d2
Jan 27 16:56:59 hypercube3 kernel: Pid: 5299, comm: modprobe Not tainted 3.2.2-hardened #1
Jan 27 16:56:59 hypercube3 kernel: Call Trace:

Re: [gentoo-hardened] Please test hardened-sources 2.6.32-r88 and3.2.2

[Anthony G. Basile]

On 01/27/2012 12:38 PM, radegand wrote:
> Dnia 27 stycznia 2012 17:06 "Tóth Attila"<atoth@atoth.sote.hu>  napisał(a):
>
>> And this one is from my laptop:
>> vmalloc: allocation failure: 0 bytes
>> modprobe: page allocation failure: order:0, mode:0x80d2
>> Pid: 3157, comm: modprobe Tainted: G           O 3.2.1-hardened #1
>> Call Trace:
>>

I believe pipacs has fixed this.  Please everyone, retest

	hardened-sources-2.6.32-r89.ebuild
	hardened-sources-3.2.2-r1.ebuild

I just added them to the tree.  I'll rapid stabilize these in about 24 
hours if no one has any issues.

-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

[gentoo-hardened] Re: Please test hardened-sources 2.6.32-r88 and3.2.2

[7v5w7go9ub0o]

On 01/28/12 00:41, Anthony G. Basile wrote:

>
> I believe pipacs has fixed this. Please everyone, retest
>
> hardened-sources-2.6.32-r89.ebuild
> hardened-sources-3.2.2-r1.ebuild
>
> I just added them to the tree. I'll rapid stabilize these in about 24
> hours if no one has any issues.
>

No joy. hardened-sources-3.2.2-r1.ebuild still  fails  for me.

I'll install gentoo-sources-3.2.1-r2 to confirm that it's not a 3.2 "thing"

Re: [gentoo-hardened] Re: Please test hardened-sources 2.6.32-r88 and3.2.2

[pageexec]

On 28 Jan 2012 at 20:24, 7v5w7go9ub0o wrote:

> No joy. hardened-sources-3.2.2-r1.ebuild still  fails  for me.

what's dmesg say? and what's 'readelf -eW'' say on the module that was loaded at the time?

[gentoo-hardened] Re: Please test hardened-sources 2.6.32-r88 and3.2.2

[7v5w7go9ub0o]

On 01/28/12 13:26, pageexec-Y8qEzhMunLyT9ig0jae3mg@public.gmane.org wrote:
> On 28 Jan 2012 at 20:24, 7v5w7go9ub0o wrote:
>
>> No joy. hardened-sources-3.2.2-r1.ebuild still  fails  for me.
>
> what's dmesg say? and what's 'readelf -eW'' say on the module that
> was loaded at the time?

Dang!  I have a different issue here - same problem with
gentoo-sources-3.2.1-r2.

Also ... (BLUSH) .... I should have mentioned I have just started using gcc
x86_64-pc-linux-gnu-4.5.3-vanilla. Up to now had been using an earlier
gcc. (I'm using vanilla because I'm also using nvidia drivers, which
apparently need to be both compiled with a vanilla compiler, and need to
match the kernel).

So I'm recompiling with  [5] x86_64-pc-linux-gnu-4.4.6-vanilla * and
will see if that helps.

At any rate, I withdraw my earlier posts - sorry about the static!

[gentoo-hardened] Re: Please test hardened-sources 2.6.32-r88 and3.2.2

[7v5w7go9ub0o]

On 01/28/12 15:16, 7v5w7go9ub0o wrote:

> So I'm recompiling with  [5] x86_64-pc-linux-gnu-4.4.6-vanilla * and
> will see if that helps.

Well, that didn't help - at this point I'm guessing I screwed up a
Loop-AES setting or component; time to dig in.

Thanks for your quick replies!

Re: [gentoo-hardened] Re: Please test hardened-sources 2.6.32-r88 and3.2.2

[Alex Efros]

Hi!

On Sat, Jan 28, 2012 at 03:16:28PM -0500, 7v5w7go9ub0o wrote:
> gcc. (I'm using vanilla because I'm also using nvidia drivers, which
> apparently need to be both compiled with a vanilla compiler, and need to

Actually I'm compiling nvidia-drivers with hardened gcc all of time.
But you'll need two extra patches attached to these bug reports:
    https://bugs.gentoo.org/show_bug.cgi?id=378059
    https://bugs.gentoo.org/show_bug.cgi?id=385837

-- 
			WBR, Alex.

[gentoo-hardened] Re: Please test hardened-sources 2.6.32-r88 and3.2.2

[7v5w7go9ub0o]

On 01/29/12 05:38, Alex Efros wrote:
> Hi!
>
> On Sat, Jan 28, 2012 at 03:16:28PM -0500, 7v5w7go9ub0o wrote:
>> gcc. (I'm using vanilla because I'm also using nvidia drivers, which
>> apparently need to be both compiled with a vanilla compiler, and need to
>
> Actually I'm compiling nvidia-drivers with hardened gcc all of time.
> But you'll need two extra patches attached to these bug reports:
>      https://bugs.gentoo.org/show_bug.cgi?id=378059
>      https://bugs.gentoo.org/show_bug.cgi?id=385837
>

DANG! :-)

Good threads; thanks for researching and sharing this!!!

Re: [gentoo-hardened] Please test hardened-sources 2.6.32-r88 and3.2.2

[Radek Madej]

On Saturday 28 January 2012 00:41:08 Anthony G. Basile wrote:
> On 01/27/2012 12:38 PM, radegand wrote:
> > Dnia 27 stycznia 2012 17:06 "Tóth Attila"<atoth@atoth.sote.hu>  
napisał(a):
> >> And this one is from my laptop:
> >> vmalloc: allocation failure: 0 bytes
> >> modprobe: page allocation failure: order:0, mode:0x80d2
> >> Pid: 3157, comm: modprobe Tainted: G           O 3.2.1-hardened #1
> 
> >> Call Trace:
> I believe pipacs has fixed this.  Please everyone, retest
> 
> 	hardened-sources-2.6.32-r89.ebuild
> 	hardened-sources-3.2.2-r1.ebuild
> 
> I just added them to the tree.  I'll rapid stabilize these in about 24
> hours if no one has any issues.

Hi,

I've tested the hardened-sources-3.2.2-r1.ebuild on three different machines, 
works like a charm - thanks! :)

Cheers,
Radek

[gentoo-hardened] Re: Please test hardened-sources 2.6.32-r88 and 3.2.2

[7v5w7go9ub0o]

On 01/27/12 08:37, Anthony G. Basile wrote:
> Hi everyone,
>
> I just added hardened-sources 2.6.32-r88 and 3.2.2 to the tree. They
>  address CVE-2012-0056. I've tested and they do indeed resist the
> exploit. I will be stabilizing them within 24 hours. However, I feel
>  very uncomfortable doing so because I don't want to trade one set of
>  problems with another. If anyone has time to test, let me know if
> you encounter any issues.
>

With 3.2.1 and 3.2.2 I am unable to enter my Loop-AES passphrase after
the bios. 3.1.5 (and all earlier - for years) works fine.

Re: [gentoo-hardened] Please test hardened-sources 2.6.32-r88 and 3.2.2

[Tom Hendrikx]

On 27/01/12 14:37, Anthony G. Basile wrote:
> Hi everyone,
> 
> I just added hardened-sources 2.6.32-r88 and 3.2.2 to the tree.  They
> address CVE-2012-0056.  I've tested and they do indeed resist the
> exploit.  I will be stabilizing them within 24 hours.  However, I feel
> very uncomfortable doing so because I don't want to trade one set of
> problems with another.  If anyone has time to test, let me know if you
> encounter any issues.
> 

I am still using 2.6.* sources here on one machine pending resolution of
bug https://bugs.gentoo.org/show_bug.cgi?id=386721 (if it will ever
happen :/ ).

However, I adopted the last working kernel (2.6.39-r8). After reading
the above, am I right to assume that there's no long-term support for
the .39 tree?

--
Tom

Re: [gentoo-hardened] Please test hardened-sources 2.6.32-r88 and 3.2.2

[Francisco Blas Izquierdo Riera (klondike)]

[-- Attachment #1: Type: text/plain, Size: 214 bytes --]

El 02/02/12 21:42, Tom Hendrikx escribió:
> However, I adopted the last working kernel (2.6.39-r8). After reading
> the above, am I right to assume that there's no long-term support for
> the .39 tree?
yup.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-hardened] Please test hardened-sources 2.6.32-r88 and 3.2.2

[Brian Kroth]

[-- Attachment #1: Type: text/plain, Size: 991 bytes --]

Tom Hendrikx <tom@whyscream.net> 2012-02-02 21:42:
> On 27/01/12 14:37, Anthony G. Basile wrote:
>> Hi everyone,
>>
>> I just added hardened-sources 2.6.32-r88 and 3.2.2 to the tree.  They
>> address CVE-2012-0056.  I've tested and they do indeed resist the
>> exploit.  I will be stabilizing them within 24 hours.  However, I feel
>> very uncomfortable doing so because I don't want to trade one set of
>> problems with another.  If anyone has time to test, let me know if you
>> encounter any issues.
>>
>
> I am still using 2.6.* sources here on one machine pending resolution of
> bug https://bugs.gentoo.org/show_bug.cgi?id=386721 (if it will ever
> happen :/ ).

Are those open-vm kernel modules still necessary?  It was my 
understanding that most/all of the guest modules for more efficient 
virtual hardware support were included in the mainline kernel now:
<http://kernelnewbies.org/Linux_2_6_33#head-b1a0ddbc804d228802ce8aebd37d9fd6513ccb01>

Thanks,
Brian

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-hardened] Please test hardened-sources 2.6.32-r88 and 3.2.2

[Tom Hendrikx]

On 03/02/12 03:50, Brian Kroth wrote:
> Tom Hendrikx <tom@whyscream.net> 2012-02-02 21:42:
>> On 27/01/12 14:37, Anthony G. Basile wrote:
>>> Hi everyone,
>>>
>>> I just added hardened-sources 2.6.32-r88 and 3.2.2 to the tree. They
>>> address CVE-2012-0056. I've tested and they do indeed resist the
>>> exploit. I will be stabilizing them within 24 hours. However, I feel
>>> very uncomfortable doing so because I don't want to trade one set of
>>> problems with another. If anyone has time to test, let me know if you
>>> encounter any issues.
>>>
>>
>> I am still using 2.6.* sources here on one machine pending resolution of
>> bug https://bugs.gentoo.org/show_bug.cgi?id=386721 (if it will ever
>> happen :/ ).
>
> Are those open-vm kernel modules still necessary? It was my
> understanding that most/all of the guest modules for more efficient
> virtual hardware support were included in the mainline kernel now:
> <http://kernelnewbies.org/Linux_2_6_33#head-b1a0ddbc804d228802ce8aebd37d9fd6513ccb01>

I did some more investigation. None of the three in-tree 
open-vm-tools-kmod ebuilds compile against 2.6.32-r89, building a 
3.2.2-r1 kernel now to test against that.

I thought that I needed the -kmod package to run open-vm-tools in the 
guest, but after some more research this might only apply when you want 
drag-and-drop support (useless for (headless) server). The open-vm-tools 
ebuilds list the -kmod package as a hard RDEPEND though. I'll do some 
tests later today/during the weekend.

Tom

Re: [gentoo-hardened] Please test hardened-sources 2.6.32-r88 and 3.2.2

[Tom Hendrikx]

On 03/02/12 13:37, Tom Hendrikx wrote:
> On 03/02/12 03:50, Brian Kroth wrote:
>> Tom Hendrikx <tom@whyscream.net> 2012-02-02 21:42:
>>> On 27/01/12 14:37, Anthony G. Basile wrote:
>>>> Hi everyone,
>>>>
>>>> I just added hardened-sources 2.6.32-r88 and 3.2.2 to the tree. They
>>>> address CVE-2012-0056. I've tested and they do indeed resist the
>>>> exploit. I will be stabilizing them within 24 hours. However, I feel
>>>> very uncomfortable doing so because I don't want to trade one set of
>>>> problems with another. If anyone has time to test, let me know if you
>>>> encounter any issues.
>>>>
>>>
>>> I am still using 2.6.* sources here on one machine pending resolution of
>>> bug https://bugs.gentoo.org/show_bug.cgi?id=386721 (if it will ever
>>> happen :/ ).
>>
>> Are those open-vm kernel modules still necessary? It was my
>> understanding that most/all of the guest modules for more efficient
>> virtual hardware support were included in the mainline kernel now:
>> <http://kernelnewbies.org/Linux_2_6_33#head-b1a0ddbc804d228802ce8aebd37d9fd6513ccb01>
>>
>
> I did some more investigation. None of the three in-tree
> open-vm-tools-kmod ebuilds compile against 2.6.32-r89, building a
> 3.2.2-r1 kernel now to test against that.

The same goes for 3.2.2-r1: none of the -kmod packages build against it. 
this means that the state of the -kmod package is a security issue, 
since it cannot be used with a non-vulnerable -hardened kernel. I'll add 
this to the bug report.

>
> I thought that I needed the -kmod package to run open-vm-tools in the
> guest, but after some more research this might only apply when you want
> drag-and-drop support (useless for (headless) server). The open-vm-tools
> ebuilds list the -kmod package as a hard RDEPEND though. I'll do some
> tests later today/during the weekend.
>

Just booted a 3.2.2-r1-hardened kernel, and vmware-tools stuff seems to 
run fine with the in-kernel vmware support. Not sure about performance 
etc, but it boots, generates no errors and VSphere in the host reports 
no issues either.

We might just need an updated open-vm-tools package that only depends on 
the in-kernel stuff, and no longer on the -kmod package. I'll try to 
followup with the vmware people, as this is getting OT here ;)

--
Tom