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 (*)) 0x2090 (gdb) p &(((struct tss_struct *)0)->io_bitmap) $2 = (long unsigned int (*)) 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.