From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH 1/4] x86: move syscall trampolines off the stack Date: Tue, 19 May 2015 07:41:35 +0100 Message-ID: <555AF73F020000780007B6BC@mail.emea.novell.com> References: <5559DAFF020000780007AFE2@mail.emea.novell.com> <5559FB2E020000780007B196@mail.emea.novell.com> <555A31FD.3030706@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YubDf-0004KX-8u for xen-devel@lists.xenproject.org; Tue, 19 May 2015 06:41:39 +0000 In-Reply-To: <555A31FD.3030706@citrix.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andrew Cooper Cc: xen-devel , Keir Fraser List-Id: xen-devel@lists.xenproject.org >>> On 18.05.15 at 20:39, wrote: > On 18/05/15 13:46, Jan Beulich wrote: >> This is needed as stacks are going to become non-executable. Use >> separate stub pages (shared among suitable CPUs on the same node) >> instead. >> >> Signed-off-by: Jan Beulich > > Can you please include a description of how you intend the stubs to > function, and how they are layed out? Parts of the code look like a > single page per stub, while other bits look like several stubs per page. I'm adding this to the already present description: Stub areas (currently 128 bytes each) are being split into two parts - a fixed usage one (the syscall ones) and dynamically usable space, which will be used by subsequent changes to hold dynamically generated code during instruction eumlation. While sharing physical pages among certain CPUs on the same node, for now the virtual mappings get established in distinct pages for each CPU. This isn't a strict requirement, but simplifies VA space management for this initial implementation: Sharing VA space would require additional tracking of which areas are currently in use. If the VA and/or TLB overhead turned out to be a problem, such extra code could easily be added. > (Personally, I would split the stub allocation/mapping/freeing into a > patch separately to moving the syscall trampolines, as each are > moderately complicated changes.) I'm afraid this wouldn't work: The freeing of the stub page depends on finding the first byte of each stub area being other than 0xCC in order for the page to not get freed. Yet only the setting up of the syscall stubs guarantees this (and I'm not really looking forward to add - however little - code to store a placeholder instead). Jan