From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933728AbdCUS2r (ORCPT ); Tue, 21 Mar 2017 14:28:47 -0400 Received: from mail-db5eur01on0096.outbound.protection.outlook.com ([104.47.2.96]:55960 "EHLO EUR01-DB5-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S932470AbdCUS2o (ORCPT ); Tue, 21 Mar 2017 14:28:44 -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: [PATCHv2] x86/mm: set x32 syscall bit in SET_PERSONALITY() To: Andy Lutomirski , Cyrill Gorcunov References: <20170321163712.20334-1-dsafonov@virtuozzo.com> <20170321171723.GB21564@uranus.lan> CC: "linux-kernel@vger.kernel.org" , Dmitry Safonov <0x7f454c46@gmail.com>, Adam Borowski , "linux-mm@kvack.org" , Andrei Vagin , Borislav Petkov , "Kirill A. Shutemov" , X86 ML , "H. Peter Anvin" , Andy Lutomirski , Ingo Molnar , Thomas Gleixner From: Dmitry Safonov Message-ID: <6648805c-e0d8-5e27-9e19-602ab47937a7@virtuozzo.com> Date: Tue, 21 Mar 2017 21:09:40 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 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.6] X-ClientProxiedBy: DB6PR1001CA0022.EURPRD10.PROD.OUTLOOK.COM (10.171.79.32) To AM5PR0801MB1731.eurprd08.prod.outlook.com (10.169.247.9) X-MS-Office365-Filtering-Correlation-Id: f0f9359f-80ad-412f-9ea7-08d47085f4d7 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM5PR0801MB1731; X-Microsoft-Exchange-Diagnostics: 1;AM5PR0801MB1731;3:tvsQ3PLJKMInaPkwgo+aK4AtmmLNzcFXZ8hshgr2xwdXUBDeuu3SajMUryA4/+UxtJA+CR3dnHGNvycfUxE9cFT/UxhIzMaUSEWJVe7zuaf3LGvTs5wiJvPPvJJdlWONXbOw7QiBhW8f4KFe4EM3fMfOItrxnSOmN1VybQnzf8ke/Gc5kOOlFRuqicid2rKZPJ0XBp1zkUkvQ4bLexImRLtF0Cv008z8FdK762qF8EKgDmrgpLevD/3I7X+IuAFsQABaBRNN/E7435aQc14YuQ==;25:zfoKptZnj4ITteDJAEdFktW9IbV6xttkQcZFjAaQCWI4pDpF1L7qNkijN53tnTMp9P34a02v0owJYCd+t16w0a1WrIEKcGaRUx4ned2dtcRAgiitVPjiW7vlVbG+qmv8P17Q2enKUExdjjbtqPv+c2WIMczkr40uZBCy6808dtFPcvK+7+ygXkiaCxEgz8krukjQVPkV32ZMT2i6TwDQMi5qndZSm3l+2VLQwcETow8bmbVoXSsvsjeiRM9nY5pL72twqqIEsrjerwmV+AmJc0G3kOE4lR+E3N89NTvvXBiIMU3gxLSJ0ReX/+CMjTiUz/OaD3eTYdyuURIG29fkvU+HD56sczFwbFk2aukO9LHxwYQOjIaRCCD61wZbJskmkHhgpyNZ/TgN7z4k1sIAhbOAdENaoH1Ca64wmVCnqMItbr+f1DwTwdIs7HBJELa6iJKv6uHJZF6hWJ658a6M7w== X-Microsoft-Exchange-Diagnostics: 1;AM5PR0801MB1731;31:FdGN69eKmDinfVX78bh8mgtJojGLW97UN78Vp3+gmD1uGH81ylFGJNnvrwHpKfkhyzQdGdByakexB5vYwNQQqIV09UmiAjCYX/vgLuutU8WVkbnOeHXy5r1O76M986i0N9MluDxc2G0sc5iRlb/uxGOh6RLWzLl0R2Bm+RbTvnuzITKyZUxmb2wyHHP3hq05i1A2Ma40V+9MCw3k4yhj5qNUjTW/Wg2moXZYhqruRPCksU1UIp1u9LdaL0IfJKWk;20:mTmCYMfu9G0KeP6CrWxDuWxQD+YITxaHoEM5iUPZrUAdTpq2ctlorUI4Kp9Ox6KL2WvxsjVRHnUD5y2jOhkN2KQK2kT7P6dCgogeJpWtpQLSDRKvr2HelQzw8ann2EQEA43goqkYOtlsQyBYt/1mW30AIIuhgDxn9LqWUR4yEr7jH7XR+Q5jrT77+tVc9LxOJ9nQPk47Lgf6suhBLvCwMRdjg4MYFELtmDXd3TlMzCZdDYRhHg8o9Gn1Yi51ch1OEEPZ+gCflDSFditQrQv2Nww1cOL89dBGiRhTCHXgTVnD9aSSyPk6ZfDycduYS46AiO5ltlkzXM4BT+Cv6VQ9ELZ0c0NVhyZ0iFYIWuAzmdikOfXB4yj1bu1HtnsMeVUcMsTGm2Bx4agt65NYvesav78lDKXdiC2dEhI89qo7fPs= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123564025)(20161123558025)(20161123562025)(20161123555025)(20161123560025)(6072148);SRVR:AM5PR0801MB1731;BCL:0;PCL:0;RULEID:;SRVR:AM5PR0801MB1731; X-Microsoft-Exchange-Diagnostics: 1;AM5PR0801MB1731;4:owuQ51q0P03KmD0YdB4k/8ECsgX8Ry0mE2gZbDa9hcV9pBeAEOOVInW/MK5iCJXPXXNKZ3LmxRIyZBVXD6k+PuIJ8hKIvWAOW4d4hMUalaABxyaEXjCXO5nWSM/FZMMSAftus1on6sb0/361ZsDlPOeoYUfoZ6n/02XpqwOlBEQDmt4pNBeEflIYDBgShYJNqCS2kHdbys20Z+1AUQb6mEM/ijVBMcbil2b+b6jSg12i2Md252Fffr+v38XHVB5ANmTPX6vnU/ENIRnakrMC3nB2qvG3tGoA7fOpusumQBBdaUx3GmgOdS0IOjRz2+Yz35snejNmEYxNw1mAh/A/vHQTOvvDUW683Z5sjBSs7A/wGKmRF9R4DK44tBeFxTT0oM5oU0Rq/3K+8l25Vg8ctQiOuyNF/Dk6crkjWrQqNR/9qpRYd1/El886E3roZ/P/H8D1FerM6rKiti3rgeuII+qSC0hwGh5tgMGTT102uJHv7pzXM+SP2kovCi7X8SI8Szra3ojBZmRVMdHsU/+mYtoJGiTl2VDNc0j3JyI99/6SH/asNZNtQ1wtpc0DIz9uTjH2mkcNOrJ5xBX41HTQYtEb8Ls08MWFyr4Mye3/95Q= X-Forefront-PRVS: 02530BD3AA X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(4630300001)(6009001)(6049001)(39450400003)(377454003)(24454002)(189998001)(77096006)(50466002)(53936002)(90366009)(83506001)(6666003)(65956001)(8676002)(305945005)(76176999)(33646002)(64126003)(31696002)(229853002)(6486002)(53546009)(7736002)(50986999)(31686004)(86362001)(54356999)(36756003)(5660300001)(7416002)(42186005)(81166006)(23676002)(54906002)(4326008)(3846002)(230700001)(2950100002)(2906002)(6116002)(4001350100001)(38730400002)(47776003)(6246003)(66066001)(65806001)(25786009);DIR:OUT;SFP:1102;SCL:1;SRVR:AM5PR0801MB1731;H:[172.16.25.13];FPR:;SPF:None;MLV:sfv;LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTTVQUjA4MDFNQjE3MzE7MjM6RXNRUXpDSDhyT1pQK2JwSHRCVUNCRnls?= =?utf-8?B?aE94S3JHMVowdmZjSWhiaGYzYzdJMHZRcS9kZ3Vod2o2ZEYyTTM5WE42V2lu?= =?utf-8?B?NVRFeFMrQWFPQXI3enIzRHVKVlhTanZYdlBnNmE2SlJFN3BGVjFqT01wTHcy?= =?utf-8?B?eHVXcWx3em1mYzZtaHJENG9jQktxMTlIaUtTOElMZml6QlZRUVgwQUg3UHl3?= =?utf-8?B?cEVaVXBXbWNoL0dTSUprSWsxSFBKSHUxNzRna0c2aDBybXd6UnY0TEo3bzJG?= =?utf-8?B?V3QvdzFlaXg1bVdMOURNZENIYkUrMmQwWDZBQnFiTFVYbXZ5MUs3L0hXM2hs?= =?utf-8?B?K3RYV005eFQwU3BNd09mczRJdjVIQm0yYVJ6R0Fjc0NKRUFrSXRaWEwzZUsx?= =?utf-8?B?Z0N5d2kzTGR1Z1VySmhJYS82bVN2R3J6emN6eFhmUHpJUjlSUmY2NGFGZG1C?= =?utf-8?B?QjRwMnBRYW9Lc1lNZGpBT0w2dlJ2ZGUvRkpFSXM4Uzc2M3dkMUlocHBTQU1J?= =?utf-8?B?MDIwZ0RGdzFZcVN1blVrcXo5OGFURE5sSkZjbGJHTWtDbE5TL0R6Yys3QWh6?= =?utf-8?B?cWFWY1pCNzJDcWhJU3VKZG95WHl0aGlhWVRXdkVOT3hqNkR4YTJwT0lnd2Zr?= =?utf-8?B?a0ZHTGRVVUFpVWJJQUtsdUxNcGJBRENXUk0ySVVzMTFhV0pvYVdvYVFGa25Q?= =?utf-8?B?RSt3djZacTRpK0pFSnJRV3Q3ZnNSU0kxNXk2ZitvcW1SQmlpTnlCVzZFYkpj?= =?utf-8?B?Q3AxbkpnR05NdUJSN2ovQXpCOHJGRTFqeHNoRENnRkRVRk5XdS9aOWt0SDI2?= =?utf-8?B?SHJzcWFISEZuYkUvQnEydzJVOGVleEk4NzBpZ25TM0wrSW9Gb2Q2dlFuSlNZ?= =?utf-8?B?UFRmb1NtTUQyZjd6NHUvWHBLaWVjYWJ2Rnd6bzY3blZBVHdqT1YwRUxrMUo5?= =?utf-8?B?ODJBS0thdEcxdTlBbFFHOWN4TVoyMGtrMmtWZW1wZWhUa01pL3I4Q28yU0l0?= =?utf-8?B?cVkwU1RZN1pxMFJIQTFjYkVERUlkTlJUMDdaZExPZWkxMGp3b1pwSmFtdVpE?= =?utf-8?B?UDVnbDJFV2VnSmxmakgwVzJrRmtSU2h0MFc4OFV2VU1DV05zem1RODNBaGtC?= =?utf-8?B?d2kzNEpLZnBJZjJJcjV2WElLbEE1bU5qWERRR1hXNVljbEYxOVBxa3BoOEhY?= =?utf-8?B?VmZEVlFhK0xWbE5OSm9EV3NkN3hzNEhRdVZMaUZEZkJocER5Uzh6TXpXSXJt?= =?utf-8?B?REFWdHhQRU1SQXpteEpiYThuNVYwbHNCcStYWEN4bUk2N0JHd0tpZUh3aVdt?= =?utf-8?B?UlIxclBBQ0xHTXBvWDdWUWZaRnEzY1d2REFaNHVURllrR1FNa0NJdWRaalJV?= =?utf-8?B?WklTZVFsZU5abDkxNTlPbUNaZzVadTJJT1Q4dmx5bTF1K0NTMVgwNmFRSkxY?= =?utf-8?B?VUFkM2FUNCthWk1OcnVLV3gyTFRXNkVXSHJ0SE9LOGo3elowZHhTVkRLUVd3?= =?utf-8?B?RTNCbHp3UTJrWUh1UzBSaWRUeTdobTBrVE1nRDU1djNyTDVBMTNITHpFbkE5?= =?utf-8?B?dzlSTEw4RXlYU0ZwNjNiN1V6eVJGMEd5UXJPTWwrV1JGR1hLZnQ4Yzh2cktS?= =?utf-8?Q?4=3D?= X-Microsoft-Exchange-Diagnostics: 1;AM5PR0801MB1731;6:NSb6w1JWsb0WK+i8TtFb09hoM/C0OIOJqi/dpIO2QdtEpQiY6n5X4F8Iz96L1DDKsMw1c7imT9RqcbNECuqjQmxEmg5MH3Ft8xq/Wd/eLwBE46zIEdaL2iKidAFpXzI42TT7CL99nl3EIDm2Qq8SuJlj89UBmuvYVdSOUWmTMXjKK1sAu7PU5RcT4vwFF/mmQLPPnRQ6ODemJYWwGDak9YPiiibcpsSO5/und9kRWqs8uXdl54J1LsRqF1xir+rxKTBKJ0P0o7aGFuOWwWBcC+FpdMHRIu3OC8KA9rH5cAgOYpKgro5wba8R9GhlMBnnhzdz4lxTCb9z21LMrwG9TV4jex/KrLyJonlRhXs38k2qnzvtEh/YsaeyxQY7UlqOMnT61hLARCJQYCN5MTt8QA==;5:r6UjhaNk9imTFGk8o2eu67fAAw2YaFuxEiH/k6AsDWW2sdRYF2yhqUgHS9VQAMLWfnqonCgm9cLTaNisErrkKji9V+0FgXriC8eEcEJ5yKRSNCrEBC6WWy1O7MPCSFO8capuG0VVkoiUCgbb1WV3Iw==;24:RAa+Ha/ThYw/ccgME3pO+dSTO17EazY/ei07kEzFy30kYIkQmc5UHDKeuxTbSWPZT9EO97T9ekonpPfcW8bmH/dF9U11GSvNnzw4JDTzLF0= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;AM5PR0801MB1731;7:MZWMx2+mYnHb4/3VH1itSHhx9lBTOSuEBaB5uuYd24mC6PXHcCXklTNH7pjY9vtlA+MNcLg/h05HBxO/IH/KvCNl1r7ck1O6h6bu9BUsE8WGLKNbLeV2fnAcKEU7q+0auf8hKTEmgaUa9QpDqDahDV2uJPxqQlEvXq+B1AB0rkFE8cjaxA8/ynFR5s+4pyvlW2X89xAE4DXCijVgp0ZDObRtTm4rkVLW2wd8htSyQQVTD8F9HEyJKuypX7wPRONWZzFnKjLkOc28lK2SBNDreAeOxtT1vLr6qRf71j+YTs+GkT2/UaUcFKyuIHqUBD37rz6GBcIk4wKRvhWYMhd1yA==;20:ZkgWu+8Fib3Pl5Hv0k4T9mrDtV3Bj5v3NSpgTOSHNldVQuyxpDzBwdxkEzEpQTBorxASbILtJ3vXbPPLA47U/V4OJOKvywtaxBWyd6y3A3gPTCFfAvDTPtfFH6Gq5NlF2f2vTFYLdEK9kazYeRbf/ucS5iqJnXkw+GsQJyygiqY= X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Mar 2017 18:13:19.1542 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0801MB1731 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/21/2017 08:45 PM, Andy Lutomirski wrote: > On Tue, Mar 21, 2017 at 10:17 AM, Cyrill Gorcunov wrote: >> On Tue, Mar 21, 2017 at 07:37:12PM +0300, Dmitry Safonov wrote: >> ... >>> diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c >>> index d6b784a5520d..d3d4d9abcaf8 100644 >>> --- a/arch/x86/kernel/process_64.c >>> +++ b/arch/x86/kernel/process_64.c >>> @@ -519,8 +519,14 @@ void set_personality_ia32(bool x32) >>> if (current->mm) >>> current->mm->context.ia32_compat = TIF_X32; >>> current->personality &= ~READ_IMPLIES_EXEC; >>> - /* in_compat_syscall() uses the presence of the x32 >>> - syscall bit flag to determine compat status */ >>> + /* >>> + * in_compat_syscall() uses the presence of the x32 >>> + * syscall bit flag to determine compat status. >>> + * On the bitness of syscall relies x86 mmap() code, >>> + * so set x32 syscall bit right here to make >>> + * in_compat_syscall() work during exec(). >>> + */ >>> + task_pt_regs(current)->orig_ax |= __X32_SYSCALL_BIT; >>> current->thread.status &= ~TS_COMPAT; >> >> Hi! I must admit I didn't follow close the overall series (so can't >> comment much here :) but I have a slightly unrelated question -- is >> there a way to figure out if task is running in x32 mode say with >> some ptrace or procfs sign? > > You should be able to figure out of a *syscall* is x32 by simply > looking at bit 30 in the syscall number. (This is unlike i386, which > is currently not reflected in ptrace.) The process could be stopped with PTRACE_SEIZE and I think, it'll not have x32 syscall bit at that moment. I guess the question comes from that we're releasing CRIU 3.0 with 32-bit C/R and some other cool stuff, but we don't support x32 yet. As we don't want release a thing that we aren't properly testing. So for a while we should error on dumping x32 applications. I think, the best way for now is to check physicall address of vdso from /proc/.../pagemap. If it's CONFIG_VDSO=n kernel, I guess we could also add check for %ds from ptrace's register set. For x32 it's set to __USER_DS, while for native it's 0 (looking at start_thread() and compat_start_thread()). The application can simply change it without any consequence - so it's not very reliable, we could only warn at catching it, not rely on this. > > Do we actually have an x32 per-task mode at all? If so, maybe we can > just remove it on top of Dmitry's series. -- Dmitry From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-f197.google.com (mail-io0-f197.google.com [209.85.223.197]) by kanga.kvack.org (Postfix) with ESMTP id 860376B0394 for ; Tue, 21 Mar 2017 14:13:24 -0400 (EDT) Received: by mail-io0-f197.google.com with SMTP id y136so69024774iof.3 for ; Tue, 21 Mar 2017 11:13:24 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50133.outbound.protection.outlook.com. [40.107.5.133]) by mx.google.com with ESMTPS id w10si14864921itf.37.2017.03.21.11.13.23 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 21 Mar 2017 11:13:23 -0700 (PDT) Subject: Re: [PATCHv2] x86/mm: set x32 syscall bit in SET_PERSONALITY() References: <20170321163712.20334-1-dsafonov@virtuozzo.com> <20170321171723.GB21564@uranus.lan> From: Dmitry Safonov Message-ID: <6648805c-e0d8-5e27-9e19-602ab47937a7@virtuozzo.com> Date: Tue, 21 Mar 2017 21:09:40 +0300 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Andy Lutomirski , Cyrill Gorcunov Cc: "linux-kernel@vger.kernel.org" , Dmitry Safonov <0x7f454c46@gmail.com>, Adam Borowski , "linux-mm@kvack.org" , Andrei Vagin , Borislav Petkov , "Kirill A. Shutemov" , X86 ML , "H. Peter Anvin" , Andy Lutomirski , Ingo Molnar , Thomas Gleixner On 03/21/2017 08:45 PM, Andy Lutomirski wrote: > On Tue, Mar 21, 2017 at 10:17 AM, Cyrill Gorcunov wrote: >> On Tue, Mar 21, 2017 at 07:37:12PM +0300, Dmitry Safonov wrote: >> ... >>> diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c >>> index d6b784a5520d..d3d4d9abcaf8 100644 >>> --- a/arch/x86/kernel/process_64.c >>> +++ b/arch/x86/kernel/process_64.c >>> @@ -519,8 +519,14 @@ void set_personality_ia32(bool x32) >>> if (current->mm) >>> current->mm->context.ia32_compat = TIF_X32; >>> current->personality &= ~READ_IMPLIES_EXEC; >>> - /* in_compat_syscall() uses the presence of the x32 >>> - syscall bit flag to determine compat status */ >>> + /* >>> + * in_compat_syscall() uses the presence of the x32 >>> + * syscall bit flag to determine compat status. >>> + * On the bitness of syscall relies x86 mmap() code, >>> + * so set x32 syscall bit right here to make >>> + * in_compat_syscall() work during exec(). >>> + */ >>> + task_pt_regs(current)->orig_ax |= __X32_SYSCALL_BIT; >>> current->thread.status &= ~TS_COMPAT; >> >> Hi! I must admit I didn't follow close the overall series (so can't >> comment much here :) but I have a slightly unrelated question -- is >> there a way to figure out if task is running in x32 mode say with >> some ptrace or procfs sign? > > You should be able to figure out of a *syscall* is x32 by simply > looking at bit 30 in the syscall number. (This is unlike i386, which > is currently not reflected in ptrace.) The process could be stopped with PTRACE_SEIZE and I think, it'll not have x32 syscall bit at that moment. I guess the question comes from that we're releasing CRIU 3.0 with 32-bit C/R and some other cool stuff, but we don't support x32 yet. As we don't want release a thing that we aren't properly testing. So for a while we should error on dumping x32 applications. I think, the best way for now is to check physicall address of vdso from /proc/.../pagemap. If it's CONFIG_VDSO=n kernel, I guess we could also add check for %ds from ptrace's register set. For x32 it's set to __USER_DS, while for native it's 0 (looking at start_thread() and compat_start_thread()). The application can simply change it without any consequence - so it's not very reliable, we could only warn at catching it, not rely on this. > > Do we actually have an x32 per-task mode at all? If so, maybe we can > just remove it on top of Dmitry's series. -- Dmitry -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org