From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751587AbdFAQ5g (ORCPT ); Thu, 1 Jun 2017 12:57:36 -0400 Received: from mail-eopbgr50109.outbound.protection.outlook.com ([40.107.5.109]:53904 "EHLO EUR03-VE1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751129AbdFAQ5c (ORCPT ); Thu, 1 Jun 2017 12:57:32 -0400 Authentication-Results: lists.infradead.org; dkim=none (message not signed) header.d=none;lists.infradead.org; dmarc=none action=none header.from=virtuozzo.com; Subject: Re: [PATCH 3/4] arm64/kasan: don't allocate extra shadow memory To: Mark Rutland , Dmitry Vyukov References: <20170601162338.23540-1-aryabinin@virtuozzo.com> <20170601162338.23540-3-aryabinin@virtuozzo.com> <20170601163442.GC17711@leverpostej> <20170601165205.GA8191@leverpostej> CC: Andrew Morton , Catalin Marinas , Will Deacon , LKML , kasan-dev , "linux-mm@kvack.org" , Alexander Potapenko , From: Andrey Ryabinin Message-ID: <75ea368f-9268-44fd-f3f6-2a48dc8d2fe8@virtuozzo.com> Date: Thu, 1 Jun 2017 19:59:20 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170601165205.GA8191@leverpostej> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [195.214.232.6] X-ClientProxiedBy: DB6PR02CA0025.eurprd02.prod.outlook.com (2603:10a6:6:15::38) To AM4PR0801MB2722.eurprd08.prod.outlook.com (2603:10a6:200:14::24) X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AM4PR0801MB2722: X-MS-Office365-Filtering-Correlation-Id: fb7d62f8-77dc-4805-ca73-08d4a90f4696 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(201703131423075)(201703031133081);SRVR:AM4PR0801MB2722; X-Microsoft-Exchange-Diagnostics: 1;AM4PR0801MB2722;3:1M7zVXalZJLoLpkMfrhp6QOqkGI+ryF+76a0L1E3IX2Tz0pyqPD+vNbx9g8hCiZO+LuilJcCIAEaodtv/LeaGxLFAIjMMw5Y10DkH45q3kw3BVI+IMwGJmslLB69BTVDzXwIbAHR3MAJnZcNeIRBVR5v2fXXuEK96EQa8g7pWzPvZ5zDMPuUDitHX2/ECqcfq150CSwVnCDJUmXoKX+XS3he04d0XCmQkGV2MVi+Rmk27rGK0eOb1yl9b671Rh7j/eF5MEaC2xJd/vh6ANivEpY+9Rg2SWtmAuqVzMsCGeN7oK2xfKViuRA8n1UO2Bw03iyWa8H5/46iwXzez6Yz4A==;25:lFq4zbeNQHVyhoZ2xyoaJhwAxqPfxyqdpsNTV7hSvsZ9zZCC6opkf9FQK1MJ20CXFP8pEpXyK5fYTkJcBLX+zybKLvM9dewgFwdx21fXG1DqeNFFYn/Yc6he7/gOhFtI3ZZaKfuE5GCx0yrmg6qC+b5LFpowPBl02gAkKclifgWtoH6Fo5TZz08lNk6dDC2wn8jJW32rn+8ixXKdUNyS8iEf8UHtAVE9HfIW9tcSfJKJyhfc0k0OdDZ3XmpLzchc6b1GCESP6ysg0Z3TBdtpJyd6HEDs8ZQf9v6AHyJLHQnezPjeaFNekXBGHXAv0Q8aWFB3BNTA9akjkuCOOPr0g894eGZ+lUf8gFJDLpI2c+SFhXST+Amycq6s20AwipmmkCbIYVNQQ23EVqRwJK8V31+evOZeTgA5aEH6nO4sJ7Zv0C0vBGFHtFk+Qhq8OdhO+irQl/5+YWJSZqOOAQ4D36Kv49ehZ5e0zVjN7rro5/0= X-Microsoft-Exchange-Diagnostics: 1;AM4PR0801MB2722;31:z6yV+qvBVXMN3SUfvxDNwa7Nwu+KQeN3cWJA++BhCmV0y3LOKDuvd6vCvSnvumjIpQFXW9tPh19DeOUPfZQcudYsuodjCAQkzjFOnRTHbCT3OPWsJu0po2M7QQ9slMPbwYY6nnqVturzLdHdOuT8oyWnZgCwYYvbt9d+TZcT5TvxYvZigaOGhz449WL/4OnAh6JmwkV7CORdHhvASRFUlfyytnvvh/IhjIxmkpvqsCcT4GeCyTvjjz34wdnKuI6QtWfpPo1hlMocSvdBjjsyIQ==;20:OLghcovYlikiLcG9mBCpsKL3Lvcv00HJV3biOl99OgK0BK/ylIZ9oULBVOFNB0lr6MH0DKmlbJcac8bcnbiKhQC5tBp05bQkmoj/wV2Hum/MAacoJuBGCT0OiCIcQwSGF0Ffzg91SDWqZw5G318DomlSlM26rjfKyJYLQdbFwQdh6kA7pgz3JOvUIYii6wyXGcQNjcq077/I8eHZ9YFbtwKQiAOD3gdYlf8/vYnMPYM1pwku0XRoG+nXLfqp45eXd0JqqCYfqJF4hHkBeF3Wqy7tAQDeSdUd14sC7PsoMKoaDnyunXwwmD0WluqLknAjnvOrU1OVKKxvWAlX+KOpdr6ZZsqyyuudZlw74ogvIiNgxozgVloAd5tu5NWqR2LSK4hA9DmFT/lT92P5xKzY8WjbqgoihUSnuWWJ831qLgE= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(180628864354917)(166708455590820); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(6041248)(20161123560025)(20161123558100)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095);SRVR:AM4PR0801MB2722;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:AM4PR0801MB2722; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1;AM4PR0801MB2722;4:jAVKS2APSHJRLFAorWQ0Ge3PXm9OcQpbj32s?= =?Windows-1252?Q?E52AZpLuagGX0MqsYiMOgcJypaFxfONqd9bWTJr3NuiotaTzbmmkiVxk?= =?Windows-1252?Q?Sn+8R3ayXYL+IwLfH2/F8NW80QicYv0ZhVI26Mzo3smG273M8/anIrMD?= =?Windows-1252?Q?4LXikjaR8pcXVx1Q/YagRfKuyL5yGucQsHdh9vbfDiSn3Zcus3iOmyiX?= =?Windows-1252?Q?y5PoGZ5zmqmCrrnauhEOTQNV6d9PH0ZjrzB7rpRs0HMtHkyFzjolS7S0?= =?Windows-1252?Q?NAziiFeku/n5Ww8mjujMrLyZcV47xCvHj99eTsLiYssKuWDrDikzH5Cn?= =?Windows-1252?Q?4SlGtIKXZb8e5pJpHnHTi782eD2WXoU5PFnmVMeQ6kC6ciLSwgbVDxO2?= =?Windows-1252?Q?3Sa7ZNSNOk9sEmQT8mOIhD3Q47l6Miafwz7JYoRk73/BWq5hu8QWMMb0?= =?Windows-1252?Q?wx80IbStKDflCHotm2SluMI7vDEO+fGqViNHudCymJnsYb2tyzPjyBHl?= =?Windows-1252?Q?mkV6btNsff7QhpXJvau3h/vu3oVEVkZDN/7MrWsSj3UzOvQK+rTNduTY?= =?Windows-1252?Q?AfvG9N7HhTQKI/N0GiGrL6mTHk7ceV7Xjn8UoJbS+bp6RHoVMV84x1s7?= =?Windows-1252?Q?8ZX2AVrdbNm0b2d4mM/WBJ87gwxABIaZXFzaT9r6ikI8KpYp5DWpuAkm?= =?Windows-1252?Q?QmAIblIEJQAr7FmqWKcW21dxogHvYrLOIB/mk4kO82zbIwwVgJvxVVFk?= =?Windows-1252?Q?bM1SKhnFZn3S/x/wO/t+lLFEJkkEqZZ85hafRQ+empa0wQY0u+EY4kXX?= =?Windows-1252?Q?VD4UD4jjV91VrBgUdVIoqueSrXfmo8S0g9JucziPxiyCjtmpt4T/FOAV?= =?Windows-1252?Q?lZdtAk0u5CWXi7vGaC4g7coks3kbk21hMp3R07SGpEpSf7k/knPO9Omr?= =?Windows-1252?Q?QmnqyhCNCQGrje+A1FvRLYSecea5ks6p0LQ0/YJ2Uw1c1acA3Cp/gIF2?= =?Windows-1252?Q?0l1ZlIOjAplwTNrAw9Go+aSjYmzfaNXxVkYJYGSvwFqTQ1/yY2gp8mvw?= =?Windows-1252?Q?PUH7oanXvxaUY+cAzLLWIH52cQiuKEYMKKDjteyLEvig25/JU+6uCXYQ?= =?Windows-1252?Q?Gs9jgNEFc/y0PjlzKaRzQlNixkGqhsVEraJac3bwyDLeEAAhUWaRMKKH?= =?Windows-1252?Q?Mjpi3S70HgYv0q5TMSL5mG+1SY4o95/On0YxRaDcZYWEi/oeRtD9rdgs?= =?Windows-1252?Q?9cfRgZZJJkR5fnjRo/aQaSh9AxtDcTyENgNgujC3IiwZKz/xtCDul5qE?= =?Windows-1252?Q?wEa66P4PB0KFqPXfOX11XmROsA=3D=3D?= X-Forefront-PRVS: 0325F6C77B X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(4630300001)(6009001)(6049001)(39410400002)(39830400002)(39450400003)(39400400002)(377454003)(24454002)(42186005)(50986999)(478600001)(7416002)(6116002)(77096006)(6486002)(966005)(4326008)(3846002)(47776003)(53936002)(36756003)(54356999)(6246003)(83506001)(54906002)(31686004)(76176999)(6306002)(33646002)(38730400002)(2906002)(81166006)(5660300001)(65826007)(230700001)(93886004)(229853002)(25786009)(66066001)(53546009)(7736002)(2950100002)(8676002)(86362001)(4001350100001)(31696002)(23746002)(50466002)(189998001)(305945005);DIR:OUT;SFP:1102;SCL:1;SRVR:AM4PR0801MB2722;H:[172.16.25.12];FPR:;SPF:None;MLV:sfv;LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1;AM4PR0801MB2722;23:Yhrm80BLLTk1ixXczkF8ufUrVDov1xEZu4F?= =?Windows-1252?Q?2dPkbprma4fuDti0CmHIbDWTYLfZZB9CSyXQcYG9bp340rShOmi/oc9u?= =?Windows-1252?Q?hTsyUkAoCvz/kF3qrrirIfhJis2Snltq2J/Ci/OxMNospeG0iiQobnHs?= =?Windows-1252?Q?iELcIEEtGRMVmTQ0+gq0Nt6f7gj7QHAF00dt7suMPH7oYqhQgbJ+W19w?= =?Windows-1252?Q?hcIVwUk3+/3ajqHDU6n62cfrUxakWqjpEzodPkngwcfveDpS4UItHN5S?= =?Windows-1252?Q?uPn6SgwF9At8drYkCTsy3IEFFn0enhIgAbGelsfzBikf1g0kZ/p4bi7H?= =?Windows-1252?Q?5maOpDktz+5p0HSCfuMrPlLCMBXpEHzmIZ/XGCYb58Rdzmkop34Pu9ki?= =?Windows-1252?Q?uTIl4gJg3/QYNSNNJUaVILJo/M85hwTT6AhdbQo0Bvaq4ZY1eCMtiRnO?= =?Windows-1252?Q?Kriu9qL4y6mOVKA616B2y+99avRDYOPmknF+Sm7ss7leI+jqern6DktK?= =?Windows-1252?Q?lTGiKDVgL379NffCaNOmzlJ0ZyP5nCQ6ePBzylE23+NGJuafAlx9dvRf?= =?Windows-1252?Q?MOgFRJJYdNQJy0VeLA3hZKICx2AlV920NymxMcK6oLRV+pl13vZ0xzFb?= =?Windows-1252?Q?BHCF1McvhZ8u8OfPn7UgvNBGu0LEntcr2bUcwZQH3iwKgfIAgZRYGRgR?= =?Windows-1252?Q?tR/mbqUPTkRmY7DbgmnIercizG9KPza7NC000u5JY1fKQb1v1aqJZPIz?= =?Windows-1252?Q?G+OI1QWyW0ysSCkyPyRnTXXsUmOIcyzuvr0W0PQplolQQrSOi2Qw1vqZ?= =?Windows-1252?Q?F7kicJLQqfT1q/OWgrL5kcVCg6wbSdHGgmq7CzumONEIV4QaXR6zlPbM?= =?Windows-1252?Q?v5FXpY3eRCF2t9RWZQmfZd9jgYnIuElZ/JFsbH7MU8laHlMNtGC/qcYD?= =?Windows-1252?Q?YnUKYbe6CyLtcz9gMZJy7If31vZ2BnYzeRh9Ty1Vq5xfu/+Wea6tk+fn?= =?Windows-1252?Q?LYaglg6jFcDCwF5qASr8I7bdvGcYm52KyNfOWcooKcv0aIT2/T2HpJ1u?= =?Windows-1252?Q?iLRFmrdTY2r57/3Gy9dTmNZ8z2QzLEv77R3YTXnCZ9nOAsweGm/xsBle?= =?Windows-1252?Q?M1hZSUeAmRok7p+7vV6lz2BjUd1+pCKicJwBfG78aLegaWItqC6oAgqd?= =?Windows-1252?Q?LcY+++2JTBVjxsv5Jxq3WmBcsxq8dex5z6MoWGZAU5yzzTo6qwZViPZ0?= =?Windows-1252?Q?HSfRTXTUxTRsighlQHM6f7PVeOPQa7Mc4JFSJDsncByq56bD4vbO39Fe?= =?Windows-1252?Q?F2AKrSZkSFPtdyqUS6hocVgomoK44EA5BTY4de3I9lFsO0O4=3D?= X-Microsoft-Exchange-Diagnostics: 1;AM4PR0801MB2722;6:I4cZA3kherH9RLzHY+ZqsVQkzsZUb15JZVheeGoCkJ5xScq734xfY257DtzKCQbzazxEdnCC5VUY0h4Yiu2uUbq8bd8TlcyMXK/590QnyHlu9feupwrVb8ZHKTd/oXbsfMMf7meu1He6xhS0kYQJqFjq2LE0p+Mx4NlmBP3/lXHpG4dS70zTp9qEvMwFimoW1zm9FYqefX5vyvdmD2/jNBOUOqoWODqdjqh2o/swjMHqnIeoPzSLjO68WlXk806MYY5qaOhJ/WvKER+AAqPJ0C3qhTOcBzsXf6qpM6hHub94cH1PH/iYNxx6eYg2CdYLod08G5hhV3mEHbq+OEk40ZQF0QHRafDGIXoiQWqMz7wWAlEjPK45vo19NMUvL2OS4wDJqILSEtFANzrLO60N9ScHyKimYYwQap+lkOh/j859pD64BVef8MA96av6j3P8KxMQgxWL06AlP9IJd0Gkjl1+gOZxTsEP2IhBY5B2tI4HOeYKamH1npYi7TBI7+q5YUc6hW5wIJKAevRnEcuhIg== X-Microsoft-Exchange-Diagnostics: 1;AM4PR0801MB2722;5:c9R6tXi8i+ka8WUlrHmJ8IEd4tGKPSWIJwbvvSWorLR8MZIT8HpjE+ZYv4S49AGkXV+wWLbtMC3WWXbJQ9pSck4+hmu8ikiuZ25MlpiRC0WitMAXQxSAm9hP3WLyVdD2jLXz20BtPtqiiIS4CIRMCA1FGPad+uB0Gl1YKfR4gJ5RUzChnu3CCte6YofY1W3r2bwycf9RbEghgBnkbNkYjGalDcMGqMVBCVKmQ2OYHMKlmHWp/CtB1UHziH6GvUq487xgdp9Bqropcw/tCBEF/mEZ3Ob5SPNyZjZ7NVV78qYP4zwm6OI6p2hBfVKpBwN/hBy534skpoKQOIaDvDdPTZ0BWZT1zsEPGCVg4YS/PBAzEZ3Rghs3cmoOAhQNMVCPeX/sqL/Emf3WoFXQP/ZYdktRG+nD1Yjofii9XoHPUOeWXEx4wb+nw7Cmyo2UOAor4d+qpjNVd6tp/uCacPHuLEwkG9cLUYBfFEzMW6e/g0S+4coXv5kl1JRIPc4HHkyQ;24:7RIoxTs8VLV44GJyFa1azXFf68fHOi4pGDhSXWLRBhn9oFvcHqwyPWjLXKjTS7I8G/ZRn+0NjNlOAt2oqIHYXYBDdR2yDYN5unnZMxL9uFE= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;AM4PR0801MB2722;7:Itd10N7xfAP0BZ/jJ5WBlXojUsQA7KnQua6gu83zTJ9899Ohl8fOVaaGu/+G1pRtAjZQB1qdyyfHvvjC4CFd/o0Tdw6KtIQoRmrToRtVfD3bdwFzNq8KW8TUqkTTvw/1FIENpEKZfdVZNE30cODmmlQucc+FU0N1oxrMy9Q+kz5bSsjzD1ofLvPtuX78Gn7CbRmykZKmcroPJig9wnkIIT1xXgM66xm6s+d9wKVfjliMstJHw8gUnxjzQWVoyflufm/75uH+1/44oZymbXV0FA5JDmfQpBtp5p/9+KH4HFLA3ZOw6JLuutHxQOg3tD5qfYXC8DVOkahfXqjTdWMYsg==;20:M5MDz6MbHSJc522oVOglwU/QCJkMfUWX1hmW9BvYyQ2ydX+qzOdLzto1Oke75TooHXIzbrFc87x6q+4mjyTz+ekkgxROxnQ5IKCRHTOkAMUCfCnaU1kZSzosXywisocmZB9dqmm0Rk9Jxa/QhGCntrvufRTYwvVMDx4vsV+rx+I= X-OriginatorOrg: virtuozzo.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Jun 2017 16:57:23.0113 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0801MB2722 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/01/2017 07:52 PM, Mark Rutland wrote: > On Thu, Jun 01, 2017 at 06:45:32PM +0200, Dmitry Vyukov wrote: >> On Thu, Jun 1, 2017 at 6:34 PM, Mark Rutland wrote: >>> On Thu, Jun 01, 2017 at 07:23:37PM +0300, Andrey Ryabinin wrote: >>>> We used to read several bytes of the shadow memory in advance. >>>> Therefore additional shadow memory mapped to prevent crash if >>>> speculative load would happen near the end of the mapped shadow memory. >>>> >>>> Now we don't have such speculative loads, so we no longer need to map >>>> additional shadow memory. >>> >>> I see that patch 1 fixed up the Linux helpers for outline >>> instrumentation. >>> >>> Just to check, is it also true that the inline instrumentation never >>> performs unaligned accesses to the shadow memory? >> Correct, inline instrumentation assumes that all accesses are properly aligned as it required by C standard. I knew that the kernel violates this rule in many places, therefore I decided to add checks for unaligned accesses in outline case. >> Inline instrumentation generally accesses only a single byte. > > Sorry to be a little pedantic, but does that mean we'll never access the > additional shadow, or does that mean it's very unlikely that we will? > > I'm guessing/hoping it's the former! > Outline will never access additional shadow byte: https://github.com/google/sanitizers/wiki/AddressSanitizerAlgorithm#unaligned-accesses > Thanks, > Mark. > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f197.google.com (mail-pf0-f197.google.com [209.85.192.197]) by kanga.kvack.org (Postfix) with ESMTP id 3540D6B0315 for ; Thu, 1 Jun 2017 12:57:28 -0400 (EDT) Received: by mail-pf0-f197.google.com with SMTP id n75so49394387pfh.0 for ; Thu, 01 Jun 2017 09:57:28 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0107.outbound.protection.outlook.com. [104.47.0.107]) by mx.google.com with ESMTPS id k184si19728711pgd.390.2017.06.01.09.57.26 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 01 Jun 2017 09:57:27 -0700 (PDT) Subject: Re: [PATCH 3/4] arm64/kasan: don't allocate extra shadow memory References: <20170601162338.23540-1-aryabinin@virtuozzo.com> <20170601162338.23540-3-aryabinin@virtuozzo.com> <20170601163442.GC17711@leverpostej> <20170601165205.GA8191@leverpostej> From: Andrey Ryabinin Message-ID: <75ea368f-9268-44fd-f3f6-2a48dc8d2fe8@virtuozzo.com> Date: Thu, 1 Jun 2017 19:59:20 +0300 MIME-Version: 1.0 In-Reply-To: <20170601165205.GA8191@leverpostej> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Mark Rutland , Dmitry Vyukov Cc: Andrew Morton , Catalin Marinas , Will Deacon , LKML , kasan-dev , "linux-mm@kvack.org" , Alexander Potapenko , linux-arm-kernel@lists.infradead.org On 06/01/2017 07:52 PM, Mark Rutland wrote: > On Thu, Jun 01, 2017 at 06:45:32PM +0200, Dmitry Vyukov wrote: >> On Thu, Jun 1, 2017 at 6:34 PM, Mark Rutland wrote: >>> On Thu, Jun 01, 2017 at 07:23:37PM +0300, Andrey Ryabinin wrote: >>>> We used to read several bytes of the shadow memory in advance. >>>> Therefore additional shadow memory mapped to prevent crash if >>>> speculative load would happen near the end of the mapped shadow memory. >>>> >>>> Now we don't have such speculative loads, so we no longer need to map >>>> additional shadow memory. >>> >>> I see that patch 1 fixed up the Linux helpers for outline >>> instrumentation. >>> >>> Just to check, is it also true that the inline instrumentation never >>> performs unaligned accesses to the shadow memory? >> Correct, inline instrumentation assumes that all accesses are properly aligned as it required by C standard. I knew that the kernel violates this rule in many places, therefore I decided to add checks for unaligned accesses in outline case. >> Inline instrumentation generally accesses only a single byte. > > Sorry to be a little pedantic, but does that mean we'll never access the > additional shadow, or does that mean it's very unlikely that we will? > > I'm guessing/hoping it's the former! > Outline will never access additional shadow byte: https://github.com/google/sanitizers/wiki/AddressSanitizerAlgorithm#unaligned-accesses > Thanks, > Mark. > -- 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: aryabinin@virtuozzo.com (Andrey Ryabinin) Date: Thu, 1 Jun 2017 19:59:20 +0300 Subject: [PATCH 3/4] arm64/kasan: don't allocate extra shadow memory In-Reply-To: <20170601165205.GA8191@leverpostej> References: <20170601162338.23540-1-aryabinin@virtuozzo.com> <20170601162338.23540-3-aryabinin@virtuozzo.com> <20170601163442.GC17711@leverpostej> <20170601165205.GA8191@leverpostej> Message-ID: <75ea368f-9268-44fd-f3f6-2a48dc8d2fe8@virtuozzo.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 06/01/2017 07:52 PM, Mark Rutland wrote: > On Thu, Jun 01, 2017 at 06:45:32PM +0200, Dmitry Vyukov wrote: >> On Thu, Jun 1, 2017 at 6:34 PM, Mark Rutland wrote: >>> On Thu, Jun 01, 2017 at 07:23:37PM +0300, Andrey Ryabinin wrote: >>>> We used to read several bytes of the shadow memory in advance. >>>> Therefore additional shadow memory mapped to prevent crash if >>>> speculative load would happen near the end of the mapped shadow memory. >>>> >>>> Now we don't have such speculative loads, so we no longer need to map >>>> additional shadow memory. >>> >>> I see that patch 1 fixed up the Linux helpers for outline >>> instrumentation. >>> >>> Just to check, is it also true that the inline instrumentation never >>> performs unaligned accesses to the shadow memory? >> Correct, inline instrumentation assumes that all accesses are properly aligned as it required by C standard. I knew that the kernel violates this rule in many places, therefore I decided to add checks for unaligned accesses in outline case. >> Inline instrumentation generally accesses only a single byte. > > Sorry to be a little pedantic, but does that mean we'll never access the > additional shadow, or does that mean it's very unlikely that we will? > > I'm guessing/hoping it's the former! > Outline will never access additional shadow byte: https://github.com/google/sanitizers/wiki/AddressSanitizerAlgorithm#unaligned-accesses > Thanks, > Mark. >