From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756456AbcDHNvW (ORCPT ); Fri, 8 Apr 2016 09:51:22 -0400 Received: from mail-am1on0143.outbound.protection.outlook.com ([157.56.112.143]:30318 "EHLO emea01-am1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751757AbcDHNvT (ORCPT ); Fri, 8 Apr 2016 09:51:19 -0400 Authentication-Results: virtuozzo.com; dkim=none (message not signed) header.d=none;virtuozzo.com; dmarc=none action=none header.from=virtuozzo.com; Subject: Re: [PATCH 1/2] x86/arch_prctl: add ARCH_SET_{COMPAT,NATIVE} to change compatible mode To: Andy Lutomirski References: <1459960170-4454-1-git-send-email-dsafonov@virtuozzo.com> <1459960170-4454-2-git-send-email-dsafonov@virtuozzo.com> <57064E6C.2030202@virtuozzo.com> CC: Thomas Gleixner , Dmitry Safonov <0x7f454c46@gmail.com>, Dave Hansen , Ingo Molnar , Shuah Khan , Borislav Petkov , X86 ML , , Andrew Morton , , , Cyrill Gorcunov , "linux-kernel@vger.kernel.org" , "H. Peter Anvin" From: Dmitry Safonov Message-ID: <5707B70F.9080402@virtuozzo.com> Date: Fri, 8 Apr 2016 16:50:07 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------020505090309040806040800" X-Originating-IP: [195.214.232.10] X-ClientProxiedBy: HE1PR02CA0080.eurprd02.prod.outlook.com (10.163.170.48) To VI1PR08MB0990.eurprd08.prod.outlook.com (10.166.143.152) X-MS-Office365-Filtering-Correlation-Id: b26d995a-f009-41d5-34f0-08d35fb4da53 X-Microsoft-Exchange-Diagnostics: 1;VI1PR08MB0990;2:ijIJk+trwreElkax/Yatoi8QSLSZo9N7ezyISMo1p1GPz7Jty+Rz3O1lMOCArBDML40on4E+LTjH+hDvOOxpZpCXktMej5UytZwHH4VTAVkHpXlNkqclmmxtBcRIgCAbTrem6NDGtbrHJhC/q6HnRweNWFldzvEs/HUdr5/4aGtVaSAzXLAzzQKDMP4oUgpW;3:AjoApHws+mFrw/Ybv4B2buB74eQ8ZV6T5lyU9sVxC1MihxP3PJCk74ARbIw6AFRNUoAHDKCOHKRWd4X5loSwZNrfhXpq5MtHb6JljhYQiykoO742sq1xQ3AsPTtywS6l X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR08MB0990; X-Microsoft-Exchange-Diagnostics: 1;VI1PR08MB0990;25:tZT2lB+ArlKZWACH/FAVAD5tF+MMTLInFuJdHFH+eMfiUTu2whmOiD7dseySaWr/TXFO+upXWNmdblVob02Ft2HLP+w9ZaOQXUEVjCNNuv4aDllFaZLvYrvsZzTc8E4JXv47NaoVvevNQ4ZIN4knR77IPr2IrsiMaoKdlyVrLBHb5Xy+FDNI/TH6o2kmcEfSgfso/TH8VKXw0esJMSABzXEL3cNCSIlg5OrZSpdIq5rCt/FSI94xMNhkSgAYoQ9VM5lWbnGCiRXSK24gZRkswjmY24K32GD1ik2I8dKsR2KbA9vqRxj3uchWkrFh/jbIx1l4wgkNMeIBZKav2CFcRUyXiweg3hv7dUcYgrcxg77FB5VTBE5AdSPPvQRVDMiF0cz+ztB52vUuW3MaltMIDF8Jx4NrwcHipGqajb+c5yf4ddH7NonIRh/7ZP9HXK7eNeMRfO2B/7zRAdvU8VSY/mYf5ZY3ZeP4t8GWaF0AW1eGWiccu3PSORnCeUc89ot4HtrQ4j906s1C5//OfRXcCGYMQN8LAthu9gcuKxQFn/4ipdu90BIF+W7TnUEmmi/ecM8EDfna4R+324Jx8Ft3u4hpHpEY3LqRKahUSalmEda/E+Lhzr0g5psO9/18UVX4qCR1fUVtsKoA6hvA8kAU4Rf4QxK/VS8lhIZ/ZjO1thbpjyV2vM5VEybmhfSeHTHBDLlBJb3J7qwzLnTAIqmnKfS95ErU/9kDR/bEbWFnLS8= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(102415293)(102615271)(6040074)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041046)(6043046);SRVR:VI1PR08MB0990;BCL:0;PCL:0;RULEID:;SRVR:VI1PR08MB0990; X-Microsoft-Exchange-Diagnostics: 1;VI1PR08MB0990;4:suxH9dehaAHS9kmd4mxjDc63TM3HFvkrXpBY98AcYmvp8m58ThLyLZ/gM3yJCb6Gj4gIX1oAsus1+p7/6dFzVbudIqgi9sdpHZ/1ut2OvhCCbuHN2kBZIAGaoZtOIC+6UvVMSLLYeTYqqj1OA3J6UNnT2cpvn+nnegKJPxDNnFylSSmoqwIhj0TMcviGfpYXmK3CNCffu5XXsmW2e0UN3yLOD+YRNMFC0i3SQo3H6ajwwIQzOjZ6Cz3AvuuRgtJA16Uh6j5xqz2hjgCf1KC1qfYWsLJP7q1IW5i0xmV1EXFha8tbOHy4du8PYtdYJR20iwOZGRAHsR6pZTd+j7rzR4eK0I1uweI80uqg4ddv13/NKVyN4gHweJG1XvgoMuAlyjDxBUbh6Fi0+I32uL0IFg9EDIjKMxLtqsc4HD1uY3vopQLAdmWWLQEzutBtqgHXYG87IwzT0EKP8dij52Irng== X-Forefront-PRVS: 0906E83A25 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(4630300001)(6049001)(6009001)(76104003)(377454003)(57704003)(24454002)(80316001)(77096005)(59896002)(93886004)(64126003)(5004730100002)(2950100001)(65956001)(65806001)(66066001)(84326002)(512874002)(83506001)(189998001)(110136002)(2906002)(42186005)(76176999)(5890100001)(36756003)(5008740100001)(50986999)(54356999)(92566002)(86362001)(4610100001)(4001350100001)(65816999)(568964002)(164054004)(33656002)(2476003)(4326007)(1096002)(81166005)(270700001)(6116002)(3846002)(87266999)(586003)(142933001);DIR:OUT;SFP:1102;SCL:1;SRVR:VI1PR08MB0990;H:[10.30.26.154];FPR:;SPF:None;MLV:sfv;LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;VI1PR08MB0990;23:Fd2UEW3gdLN0AbX4gaPJgLIr8CPBf3wrr6Ej2D3BZ?= =?us-ascii?Q?yizfosz4lh/0cXGcBFjnu3vPitLpRlMevqbl2e4cBItjR7j72bTWaAngo5PK?= =?us-ascii?Q?FZCEDYd4LIrG+KiThrk24wFPcDByVcP6U6BEV9gKPHKOdVnU6SkcSbh0kh4y?= =?us-ascii?Q?AaGcoM8Z6Hb3ic3Q7O0HkV3bj8kA6dxrJuI885EVTHM8BFfN/EKm19l+AriH?= =?us-ascii?Q?g0mD/EcB9Z8PBd8VYj7IythfqjiVMgvH20e8PZTDl8wVhzn1zCfQDcL5QIeJ?= =?us-ascii?Q?tLGzHNQc07YRGRVL+1fTCgJPeXMvd/4ruD93k587jJylzS7eh/Y+QxAsum3P?= =?us-ascii?Q?itocTTfbrPP2VHyDEZo0cVgTBO3svnxeHaVeU3hWufEX3bB/TwcRNVy7qUkw?= =?us-ascii?Q?nROD/wx4SaGY2DfJwjlRgRCIW6M2BMK52sIScqruTwhYhPIVT4kc5UgjMaA8?= =?us-ascii?Q?ckkTjwnJAb+HsTi8T2avGmmIEyejPBKjkhS6pFHRNYJ0isDAxKygSk78SpI5?= =?us-ascii?Q?W9vvEQBRTPWyEGPmP3mQC3tpzxNzikpSBRdtS5r2/Jjo8AwlmRj//9tT5MFT?= =?us-ascii?Q?P/AdROXeqR/KYkf1jSVhlGHxxtjPV6IH51PtKbEhvm9P0J5DrEitBnQYWNdo?= =?us-ascii?Q?MlwV2OXK4ie7teyeeNHny3Ch3AAdFIrjuewD+Io6W4UuQ50Q4tPUxftg8T96?= =?us-ascii?Q?iH57elF0sIjtwvrZzz5e+aYRXg8ab1MxbsL9TCGHzrvQ2EkHn908oZXVjHrY?= =?us-ascii?Q?eJKFv736j2itDvYGYDVV6LukHd7xEY0TPDOml9fuwo+RWSCqjDbx6OQ68Tdt?= =?us-ascii?Q?ZCS/Ys0eumFdNAXUjADeDkrXYl2sBO6wxtj7Sl0tbgcRzy2vrLzcm57nWy3t?= =?us-ascii?Q?ndEx08n9HlP6zIm9l7HaZHJtK579jj21SxaAtHFn/S18zxPI2RCEixvUztPE?= =?us-ascii?Q?qvkmxTJp25n6CLqUv5MsORsa/dCHI3meFMRzO1AK3yrVTmCqlaXKjTFK+Dsx?= =?us-ascii?Q?2ucLWBacY+yJN5SHjN82mdnzN/uGPMPvFDT7RgZbznDH8h6EQtYVdXkKAHso?= =?us-ascii?Q?kf6FnxCYTGbU5C1lKbNxf+EgfFMZSuJM71gNyv5IsZyNUDhBWl2+E2Cia0RF?= =?us-ascii?Q?g2VWdRpbuDgINxz/Q4wTNF0pf6UvaFnAa31ZJJ/3kVmrhSIoL27HdmPsdRDZ?= =?us-ascii?Q?VpnBzknhcOs6xGBpYIhiWImQntojK9DE7ZDHdx1Ns1u7EFdFVNuu0gZlCe9y?= =?us-ascii?Q?ZrsNBH4gXbDvwqRRGQ=3D?= X-Microsoft-Exchange-Diagnostics: 1;VI1PR08MB0990;5:7ZBI+v8sCOhBJri74Go8mSUCfULpKrpYAmHDFrugWwQDkFBCS+ijqp6qU9nZQPSy1M2rAdF9ZbtzZsGA+XHEyzOw8Nb1BekDHKBUq3osm+C1x788q5g0FENiNIpaD/VvJwAzwyhogMwCI28gXmrk1A==;24:JIWU62qKz6ujfyrumPMdI0+7SwIfxSwMsXmExnd+q9f0TASe9iRdFnZUyBsH/LhXCanpz7v7cuDZoWSe6zgXKHirNe+SPizhP+gnQ212JPw=;20:0//NTP4692iB0TBJSUC1FRctplq7xYnwbYVbrpi6mzc220Jz/CJcEPcdIfovO2etIhn41jEzjoegc3IlM5kcB0z2c5jzvC5xdRjy5GKt9T/tVyJq7DROHugBSunrDot3mcQjh0Lj/4NyL5MM+aVyKeMpKMfBlkwMYwAe23cuEyw= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Apr 2016 13:51:12.9134 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB0990 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --------------020505090309040806040800 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit On 04/07/2016 05:39 PM, Andy Lutomirski wrote: > For 32-bit, the vdso *must* exist in memory at the address that the > kernel thinks it's at. Even if you had a pure 32-bit restore stub, > you would still need vdso remap, because there's a chance the vdso > could land at an unusable address, say one page off from where you > want it. You couldn't map a wrapper because there wouldn't be any > space for it without moving the real vdso out of the way. > > Remember, you *cannot* mremap() the 32-bit vdso because you will > crash. It works by luck for 64-bit, but it's plausible that we'd want > to change that some day. (I have awful patches that speed a bunch of > things up at the cost of a vdso trampoline for 64-bit code and a bunch > of other hacks. Those patches will never go in for real, but > something else might want the ability to use 64-bit vdso trampolines.) Hello again, what do you think about attached patch? I think it should fix landing problem for i386 vdso mremap. It does not touch fast syscall path, so there should be no speed regression. >> I did remapping for vdso as blob for native x86_64 task differs >> to compatible task. So it's just changing blobs, address value >> is there for convenience - I may omit it and just remap >> different vdso blob at the same place where was previous vdso. >> I'm not sure, why do we need possibility to map 64-bit vdso blob >> on native 32-bit builds? > That would fail, but I think the API should exist. But a native > 32-bit program should be able to remap the 32-bit vdso. > > IOW, I think you should be able to do, roughly: > > map_new_vdso(VDSO_32BIT, addr); > > on any kernel. > > Am I making sense? I will still work for this interface - just wanted that usuall mremap to work on vdso mappings. Thanks, Dmitry. --------------020505090309040806040800 Content-Type: text/x-patch; name="0001-x86-vdso-add-mremap-hook-to-vm_special_mapping.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0001-x86-vdso-add-mremap-hook-to-vm_special_mapping.patch" >>From ffba027156d7194a07ccccd80ece9be19107e4e6 Mon Sep 17 00:00:00 2001 From: Dmitry Safonov Date: Fri, 8 Apr 2016 16:27:18 +0300 Subject: [PATCH] x86/vdso: add mremap hook to vm_special_mapping This patch adds possibility for userspace 32-bit applications to move vdso mapping. Previously, when userspace app called mremap for vdso, in return path it would land on previous address of vdso page, resulting in segmentation violation. Now it lands fine and returns to userspace with remapped vdso. There is still problem for remapping vdso in glibc applications: linker relocates addresses for syscalls on vdso page, so you need to relink with the new addresses. Or the next syscall through glibc may fail: Program received signal SIGSEGV, Segmentation fault. #0 0xf7fd9b80 in __kernel_vsyscall () #1 0xf7ec8238 in _exit () from /usr/lib32/libc.so.6 Signed-off-by: Dmitry Safonov --- arch/x86/entry/vdso/vma.c | 29 ++++++++++++++++++++++++----- include/linux/mm_types.h | 3 +++ mm/mmap.c | 10 ++++++++++ 3 files changed, 37 insertions(+), 5 deletions(-) diff --git a/arch/x86/entry/vdso/vma.c b/arch/x86/entry/vdso/vma.c index 10f704584922..ed6c9fa64531 100644 --- a/arch/x86/entry/vdso/vma.c +++ b/arch/x86/entry/vdso/vma.c @@ -12,6 +12,7 @@ #include #include #include +#include #include #include #include @@ -98,10 +99,22 @@ static int vdso_fault(const struct vm_special_mapping *sm, return 0; } -static const struct vm_special_mapping text_mapping = { - .name = "[vdso]", - .fault = vdso_fault, -}; +static int vdso_mremap(const struct vm_special_mapping *sm, + struct vm_area_struct *new_vma) +{ + struct pt_regs *regs = current_pt_regs(); + + new_vma->vm_mm->context.vdso = (void __user *)new_vma->vm_start; + +#if defined(CONFIG_X86_32) || defined(CONFIG_IA32_EMULATION) + /* Fixing userspace landing - look at do_fast_syscall_32 */ + if (current_thread_info()->status & TS_COMPAT) + regs->ip = (unsigned long)current->mm->context.vdso + + vdso_image_32.sym_int80_landing_pad; +#endif + + return 0; +} static int vvar_fault(const struct vm_special_mapping *sm, struct vm_area_struct *vma, struct vm_fault *vmf) @@ -162,6 +175,12 @@ static int map_vdso(const struct vdso_image *image, bool calculate_addr) struct vm_area_struct *vma; unsigned long addr, text_start; int ret = 0; + + static const struct vm_special_mapping vdso_mapping = { + .name = "[vdso]", + .fault = vdso_fault, + .mremap = vdso_mremap, + }; static const struct vm_special_mapping vvar_mapping = { .name = "[vvar]", .fault = vvar_fault, @@ -195,7 +214,7 @@ static int map_vdso(const struct vdso_image *image, bool calculate_addr) image->size, VM_READ|VM_EXEC| VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC, - &text_mapping); + &vdso_mapping); if (IS_ERR(vma)) { ret = PTR_ERR(vma); diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h index c2d75b4fa86c..4d16ab9287af 100644 --- a/include/linux/mm_types.h +++ b/include/linux/mm_types.h @@ -586,6 +586,9 @@ struct vm_special_mapping { int (*fault)(const struct vm_special_mapping *sm, struct vm_area_struct *vma, struct vm_fault *vmf); + + int (*mremap)(const struct vm_special_mapping *sm, + struct vm_area_struct *new_vma); }; enum tlb_flush_reason { diff --git a/mm/mmap.c b/mm/mmap.c index bd2e1a533bc1..ba71658dd1a1 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -2930,9 +2930,19 @@ static const char *special_mapping_name(struct vm_area_struct *vma) return ((struct vm_special_mapping *)vma->vm_private_data)->name; } +static int special_mapping_mremap(struct vm_area_struct *new_vma) +{ + struct vm_special_mapping *sm = new_vma->vm_private_data; + + if (sm->mremap) + return sm->mremap(sm, new_vma); + return 0; +} + static const struct vm_operations_struct special_mapping_vmops = { .close = special_mapping_close, .fault = special_mapping_fault, + .mremap = special_mapping_mremap, .name = special_mapping_name, }; -- 2.8.0 --------------020505090309040806040800--