[<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
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
