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 <>
cc: Vasily Averin <>
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.