Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 26 Jun 2018 22:33:11 +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 Tue, 26 Jun 2018, Solar Designer wrote:

> Wow.  But per my review of the full struct tss_struct, the stack[] field
> offset is:
>
> 4+8*5+4*2+2*2+1025*8+8 = 8264
>
> So it's not 16-byte aligned.  But that's the start of stack[], and we
> need the stack pointer to be aligned.  Yet I suppose aligning stack[]
> itself is in fact the most appropriate fix.

Well, it seemed to be the easiest (and least prone to break other things) 
way to make the top of stack[] aligned.

> Reviewing the diffs between e.g. -423 and -431, I see this stack[] in
> struct tss is in fact newly added:

Yes. It seems trampoline stacks were introduced as a part of KAISER/KPTI.

> Do you think this is a RHEL5 bug?

Probably... unless OpenVZ people (Vasily?) did all the butchery 
needed to merge KPTI themselves.

On Tue, 26 Jun 2018, Solar Designer wrote:

> BTW, it'd be fun if this tiny stack ever overflows.  The canary check
> doesn't do much:

Afaict it is only used as a "trampoline stack" to hold a small amount 
of data while the entry/exit code is switching address spaces.

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