Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 28 Jun 2018 16:09:43 +0200 (CEST)
From: Pavel Kankovsky <peak@...o.troja.mff.cuni.cz>
To: owl-dev@...ts.openwall.com
cc: Vasily Averin <vvs@...tuozzo.com>
Subject: Re: 32-bit syscall breakage in -431 kernel with KAISER

On Thu, 28 Jun 2018, Solar Designer wrote:

> At first glance, RHEL6 might also be affected.  From 2.6.32-754.el6 as
> currently used by that OpenVZ branch:

Using vmlinux from CentOS kernel-debuginfo-2.6.32-754.el6.x86_64.rpm:

$ gdb vmlinux
(gdb) p &(((struct tss_struct *)0)->stack)
$1 = (long unsigned int (*)[256]) 0x2090
(gdb) p &(((struct tss_struct *)0)->io_bitmap)
$2 = (long unsigned int (*)[1025]) 0x80
(gdb) p &(((struct tss_struct *)0)->stack_canary)
$3 = (long unsigned int *) 0x2088
(gdb) p &(((struct tss_struct *)0)->x86_tss.io_bitmap_base)
$4 = (u16 *) 0x66
(gdb) p sizeof(struct x86_hw_tss)
$5 = 128

struct x86_hw_tss is somehow padded to 128 bytes (instead of 104 bytes you 
get when you sum its components). This is probably an effect of 
____cacheline_aligned.

An extra element at then end of io_bitmap[] and the presence of 
stack_canary (not present in vanilla 2.6.32!) conspire to keep stack[] 
aligned at 16 bytes.

It seems they have managed to dodge that bullet.

-- 
Pavel Kankovsky aka Peak                      "Que s├žay-je?"

Powered by blists - more mailing lists

Your e-mail address:

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.