Mailing List Archive: Gentoo: Hardened

Please test hardened-sources 2.6.32-r88 and 3.2.2

Index | Next | Previous | View Threaded

basile at opensource

Jan 27, 2012, 5:37 AM

Post #1 of 9 (426 views)
Permalink

Please test hardened-sources 2.6.32-r88 and 3.2.2

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

atoth at atoth

Jan 27, 2012, 8:02 AM

Post #2 of 9 (398 views)
Permalink

Re: Please test hardened-sources 2.6.32-r88 and 3.2.2 [In reply to]

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
>

atoth at atoth

Jan 27, 2012, 8:06 AM

Post #3 of 9 (402 views)
Permalink

Re: Please test hardened-sources 2.6.32-r88 and 3.2.2 [In reply to]

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
>>
>
>
>
>

7v5w7go9ub0o at gmail

Jan 27, 2012, 10:18 AM

Post #4 of 9 (401 views)
Permalink

Re: Please test hardened-sources 2.6.32-r88 and 3.2.2 [In reply to]

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.

tom at whyscream

Feb 2, 2012, 12:42 PM

Post #5 of 9 (380 views)
Permalink

Re: Please test hardened-sources 2.6.32-r88 and 3.2.2 [In reply to]

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

klondike at gentoo

Feb 2, 2012, 12:47 PM

Post #6 of 9 (383 views)
Permalink

Re: Please test hardened-sources 2.6.32-r88 and 3.2.2 [In reply to]

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.

Attachments:

signature.asc (0.26 KB)

bpkroth at gmail

Feb 2, 2012, 6:50 PM

Post #7 of 9 (375 views)
Permalink

Re: Please test hardened-sources 2.6.32-r88 and 3.2.2 [In reply to]

Tom Hendrikx <tom [at] whyscream> 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

Attachments:

signature.asc (0.19 KB)

tom at whyscream

Feb 3, 2012, 4:37 AM

Post #8 of 9 (378 views)
Permalink

Re: Please test hardened-sources 2.6.32-r88 and 3.2.2 [In reply to]

On 03/02/12 03:50, Brian Kroth wrote:
> Tom Hendrikx <tom [at] whyscream> 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

tom at whyscream

Feb 3, 2012, 6:11 AM

Post #9 of 9 (374 views)
Permalink

Re: Please test hardened-sources 2.6.32-r88 and 3.2.2 [In reply to]

On 03/02/12 13:37, Tom Hendrikx wrote:
> On 03/02/12 03:50, Brian Kroth wrote:
>> Tom Hendrikx <tom [at] whyscream> 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

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads