From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753925AbcDOJCw (ORCPT ); Fri, 15 Apr 2016 05:02:52 -0400 Received: from mail-db5eur01on0104.outbound.protection.outlook.com ([104.47.2.104]:46943 "EHLO EUR01-DB5-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753886AbcDOJCq (ORCPT ); Fri, 15 Apr 2016 05:02:46 -0400 X-Greylist: delayed 916 seconds by postgrey-1.27 at vger.kernel.org; Fri, 15 Apr 2016 05:02:45 EDT Authentication-Results: virtuozzo.com; dkim=none (message not signed) header.d=none;virtuozzo.com; dmarc=none action=none header.from=virtuozzo.com; Subject: Re: [PATCHv2] x86/vdso: add mremap hook to vm_special_mapping To: Andy Lutomirski References: <1460388169-13340-1-git-send-email-dsafonov@virtuozzo.com> <1460651571-10545-1-git-send-email-dsafonov@virtuozzo.com> CC: "linux-kernel@vger.kernel.org" , "Thomas Gleixner" , Ingo Molnar , "H. Peter Anvin" , X86 ML , Andrew Morton , "linux-mm@kvack.org" , Dmitry Safonov <0x7f454c46@gmail.com> From: Dmitry Safonov Message-ID: <5710AA59.1010001@virtuozzo.com> Date: Fri, 15 Apr 2016 11:46:17 +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: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [195.214.232.10] X-ClientProxiedBy: DB5PR02CA0006.eurprd02.prod.outlook.com (10.161.237.16) To HE1PR0801MB1305.eurprd08.prod.outlook.com (10.167.247.147) X-MS-Office365-Filtering-Correlation-Id: 44e845c6-5b64-4d10-bff9-08d3650a8e38 X-Microsoft-Exchange-Diagnostics: 1;HE1PR0801MB1305;2:vLwGmWn3ncZ9UnkcmiSI8YvJgzU2K2f38KttV/n9vJRtgmoagVkgb1FKZ/RE0Bp+meLFaWPuwoBzTitD3ih0C1T2vLJ+HdsquRINDff+gMG8goPL5T0dmvXfOPeBLvYrQXitJ+uacae1WQOVtKrr97/9YfDry6cnGKsE8tONAlf0I+IjorLhUgxxKjo36L64;3:iOlHBtcfElMriTMuwan4qCpEKmTQ1AQgkHLIRkHaMohojxrC9Ovbs0ZkMQ5IiGomLQj3RZ/nCOOjtvoBt5AKSumpad/F3MwZ5++jYjrhmq1fGeNDf91SFKvzhDd/kcdK X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0801MB1305; X-Microsoft-Exchange-Diagnostics: 1;HE1PR0801MB1305;25:vrPkAPAvw1i6vGVrDOQn7um+9RtiNoLFFdeT72eBk4Ibkvv9Tzn816Lp3h+KUe14LbAkNjJfcky4lIkezJvCr9BBWFWDnCkrvPI9/aAMk8/bplUteMz0Rh7Vf4LC08S7Uk2q9eQfVCu7JL67Xb+f6pIr94KajOBLcgxQaTgGgvFhUSFdqWxypvQNryGbnPcvk7R4K08dCmukfVmFissIzc6/HtMWnIkye78L44PC/gzoLtnjTM2ASTNbY02cANFzFB1GnsEwVujqmC0CzrYg0DK5lptayYRAX3ao/deINp9LT08z8a++8rTeySadxIzjdHpW2Q11tzmryWaNiETqeeoZ1PuFzyTdR/p9tHZNCtGAAW5Ywz73pf/P/xK+w75wHiJ+JoH229nwyzXGJ6UyAGsY2zt43nTNuCEE1YEMsDL+FFkyUeHVducP+TIfLAj4oBTBbxiX5gMedGZUsOJszQoIRpNAODCVp9Ixza42JtTMWX83cz7QP0QPS9Zl/F22WQ0TE78QpiOFti+jhgsS3IgSPhd/Fg0nJWFeiZ6Aenz5por51JANyUa2VggBcokV3i+CYrftSDE1L8vNAe7TpaOx/hJDgV2t9tFymFTtAMBS4CUcI5OaRznbkmYv/wWJ0Q6CrjOEnLbzbio8EB7mrA== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040130)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041046)(6043046);SRVR:HE1PR0801MB1305;BCL:0;PCL:0;RULEID:;SRVR:HE1PR0801MB1305; X-Microsoft-Exchange-Diagnostics: 1;HE1PR0801MB1305;4:Z+1gKCM8DDJdCm5d5vOFBorQ5PiceShnCrU8Zaq3MtUJmWWTTgMguABs0SqrQNOlgpbr5MOb9Scz8XKhLdtZ0HAT9tbhitxnemmskGBwGI83QRsVLxRYfX1dLdXQ9TkXoNQLXNLYgMTvPUoNb23Hy6A0J0KKpbPTTb2VHmgM0Iils7LPHv+MYfE5YffpGcDgjMCmrB/SBJHbkP5Gj+I3NyThg5NpwAuYegxZGvf6RWRslT2ZU4JvuPYt5Nv1PzhButLXWIZtJplaknxbgVhfc0+j5ASQhCPUGB/XSF5c9NHR6MoA522ofayaHMxtYAuIS3SG5ABEqOgdQ0/AHE97wIrNsp+b2JuQvhQsqQ8UhynJg2+hX9CQRz21UyWVXb2utI83QqQNqb8nqeSYXUmhX/pHvu3Vbrsa7KFJkyc6dF0= X-Forefront-PRVS: 0913EA1D60 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(4630300001)(6049001)(6009001)(377454003)(24454002)(5004730100002)(189998001)(77096005)(110136002)(92566002)(80316001)(54356999)(87266999)(65816999)(76176999)(50986999)(59896002)(36756003)(5008740100001)(23676002)(86362001)(33656002)(65806001)(42186005)(47776003)(4001350100001)(65956001)(66066001)(64126003)(19580405001)(19580395003)(6116002)(83506001)(2906002)(50466002)(164054004)(3846002)(230700001)(586003)(1096002)(81166005)(2950100001)(4326007);DIR:OUT;SFP:1102;SCL:1;SRVR:HE1PR0801MB1305;H:[10.30.26.154];FPR:;SPF:None;MLV:sfv;LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQUjA4MDFNQjEzMDU7MjM6RW00U1RTcGI3VDR4MkZjeWtqeHlsNlVI?= =?utf-8?B?bmxiL0pWOStGcERqK3A0cEdDUHZ2Y0ExRm90cElnZTJERms0UkMxZnU1UGNW?= =?utf-8?B?SnpOYmFkSWVaSytMUlcrcGo4bmQ5Nk9Vck95Z1pXSDZRdFVtUmcvVnRLRTNM?= =?utf-8?B?Q0lwUXBCWUtHakdMajZML0VwclNSc3dnSFNDRWVPN0p6U3dGb1pJa2VJYkY2?= =?utf-8?B?YlZUdk84Si9GZG1GZVNLZE5GWVR0S2tuWWRDZERxeEVYdGpNTkQ5dFlNMVFl?= =?utf-8?B?cTJ5eEQ4ak8yK1ZZQ1NTZUlpQ2NIV294MDhvMXp0WlFUNHprU0N6N1dSMVZt?= =?utf-8?B?Q3dOZW00V1lzdWNXanoydDVha1lmcDd6RVByem0zaEFLYmNPMk5KOHpRZzB6?= =?utf-8?B?OGxublV5bUtLMEdUMkdSVkJsM09mUDJWUnhDcTdaMlFSdjYvbEoraEFXMjJr?= =?utf-8?B?T056TnpoSDIvNmpKdndTN2VNS2krRFNCU2I5RExqUDcrMDNpb0cxZW5xSVNW?= =?utf-8?B?YlRTaXVRWGNHYTJ0cGZhSVJ3NjlxT1FHUmJsNWVLZFFTc2ZYOTh2N09YY242?= =?utf-8?B?SEJadUZCUmM0NlNiTHcrYjEzUDN2cCtPcGZTT1UwOE0zczlTTTFuM2txa3dC?= =?utf-8?B?UlBEMHg1cGM3UzREcUY4K3pyWFFieFVyRWJydDJBWVpPc0tQQU1GQzlmcjB0?= =?utf-8?B?b0NVY3RpMmZCemZkRUc0b3BEWHZOTmcrbDNRb0UyOU8zMjY0S2d3VXdkTkV4?= =?utf-8?B?WnVFZlZlVkc0R3lOYWVlNnY0Wnl5a2RMdUpFNWN6WVRyYjV5K3d6YVFjWnN3?= =?utf-8?B?d3hWTWRxSlcyMndISGdGNUFQc0Z6SzNMemNXMTR1dVh6djVZUjlaQUpnWlVx?= =?utf-8?B?WmwvanJNVjVlQkM2VHN6ajlGRmZFcjkyOUhYSlBpcEVON0pkTURhWmVVMnJH?= =?utf-8?B?WUQrU0RWYjlvNEg4aWcwdHZBSjdodGVibWFmRm42aC8zdEJ6dUlVdThaNzNC?= =?utf-8?B?VFZlVkZ3SXl1Rlp6TTB0Mytra2poYnBnSjRFQVJ0ZDJZY2t6dC9ZNkdqWmRr?= =?utf-8?B?QWFTZWxNUmFPNGY1RUhlR3I5MHFnTzBnNHh2TEcxL3pTUGRaV2tNS2FZSVhB?= =?utf-8?B?aFN0OHBXWk1pVk1PWEd5UHJBNkhmRzVmRmh0eEJ5ZUpMUHdzSkEveEwwQUFN?= =?utf-8?B?ZDlPZzh2dTBtb2RBRHlyQlR3T2ttSFFWKzFtelE1a0UzNnJiWnI2L0NVdmdl?= =?utf-8?B?cStRUVJFL01yQXJ0bkhLRWVLTTNFS0JXYnY2MEdteHVoM3laWG1xS25jdE9a?= =?utf-8?B?ZDZ0cDBUUFcwTS9ha0I1dUxkZE5NeU5INWNDM0N5WnVqWWxXNGd5Qm1KOTVz?= =?utf-8?B?STJQRGM2Q2l4eHhjbzM5V1IvSk5XSENNbE1JeEV5eU8xN09EM09RWXVsRWRm?= =?utf-8?B?MmhkQlpjTXM1Wm5pYkVaRlBvcUJFbWg1eWhia0tQbWdFaVF4c3k3NmQ0ZmJo?= =?utf-8?Q?eimreX/kOKilNOMsVMYMj6beWw4=3D?= X-Microsoft-Exchange-Diagnostics: 1;HE1PR0801MB1305;5:nLTCdWMpavi1mUgsehd8jQO0GqjOMaraW33d8fjNN3XYvtxG+OFsMfOVxoYbn4q4I8ISp9RUN3+1lBw33BhxuNYob3A//9QqeBTlwmedjKTMh0aD2L+xJv8U7Y3rEsdcJ7RqZxqAC9kycMxX6ywrkg==;24:yRctO2/x72LtyBXGyZrka+lFF6G8I81dgWsDrI5cMYze3SfhhlTql/lUdy/QE4EaWANNCMjgx+kGkioNCc+gSyDNbo3rleZI+2vvGavSqtE=;20:rURdFVxpRNfiJPuv87p4QhM0K+3aAmKiBaeZ3J9W42LkBEnV8XHObkS9C0PU5EQ5GqBJSK9gkRqLqpNj3BOKKtZhtdQIKcdRGN+Z5DVHMgTtKrnt4ljU2vwGhobLRfG9Egr9mclqURiZdb8bL+LKZhCuFpCK16CZMmYiv18Ap0A= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Apr 2016 08:47:18.6252 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0801MB1305 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/15/2016 01:58 AM, Andy Lutomirski wrote: > On Thu, Apr 14, 2016 at 9:32 AM, Dmitry Safonov wrote: >> Add 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. >> This will also fix context.vdso pointer for 64-bit, which does not >> affect the user of vdso after mremap by now, but this may change. >> >> Renamed and moved text_mapping structure declaration inside >> map_vdso, as it used only there and now it complement >> vvar_mapping variable. >> >> There is still problem for remapping vdso in 32-bit 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 >> --- >> v2: added __maybe_unused for pt_regs in vdso_mremap >> >> arch/x86/entry/vdso/vma.c | 33 ++++++++++++++++++++++++++++----- >> include/linux/mm_types.h | 3 +++ >> mm/mmap.c | 10 ++++++++++ >> 3 files changed, 41 insertions(+), 5 deletions(-) >> >> diff --git a/arch/x86/entry/vdso/vma.c b/arch/x86/entry/vdso/vma.c >> index 10f704584922..7e261e2554c8 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,26 @@ 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 __maybe_unused *regs = current_pt_regs(); >> + >> +#if defined(CONFIG_X86_32) || defined(CONFIG_IA32_EMULATION) >> + /* Fixing userspace landing - look at do_fast_syscall_32 */ >> + if (regs->ip == (unsigned long)current->mm->context.vdso + >> + vdso_image_32.sym_int80_landing_pad >> +#ifdef CONFIG_IA32_EMULATION >> + && current_thread_info()->status & TS_COMPAT >> +#endif > Instead of ifdef, use the (grossly misnamed) is_ia32_task() helper for > this, please. Thanks, will do > >> + ) >> + regs->ip = new_vma->vm_start + >> + vdso_image_32.sym_int80_landing_pad; >> +#endif >> + new_vma->vm_mm->context.vdso = (void __user *)new_vma->vm_start; > Can you arrange for the mremap call to fail if the old mapping gets > split? This might be as simple as confirming that the new mapping's > length is what we expect it to be and, if it isn't, returning -EINVAL. Sure. > > If anyone things that might break some existing application (which is > quite unlikely), then we could allow mremap to succeed but skip the > part where we change context.vdso and rip. > >> + >> + return 0; >> +} >> >> static int vvar_fault(const struct vm_special_mapping *sm, >> struct vm_area_struct *vma, struct vm_fault *vmf) >> @@ -162,6 +179,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, >> + }; > Why did you add this instead of modifying text_mapping? I moved text_mapping inside map_vdso function, as it's used only there. Then I thought that vdso_mapping is better naming for it as it complement vvar_mapping (goes right after). If it's necessary, I will preserve naming. > > --Andy -- Regards, Dmitry Safonov