From mboxrd@z Thu Jan 1 00:00:00 1970 From: mark.rutland@arm.com (Mark Rutland) Date: Thu, 16 Feb 2017 11:06:12 +0000 Subject: [PATCH] arm64: print a fault message when attempting to write RO memory In-Reply-To: <20170216015408.12933-1-stephen.boyd@linaro.org> References: <20170216015408.12933-1-stephen.boyd@linaro.org> Message-ID: <20170216110612.GA32039@leverpostej> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi, On Wed, Feb 15, 2017 at 05:54:08PM -0800, Stephen Boyd wrote: > If a page is marked read only we should print out that fact, > instead of printing out that there was a page fault. Right now we > get a cryptic error message that something went wrong with an > unhandled fault, but we don't evaluate the esr to figure out that > it was a read/write permission fault. > > Instead of seeing: > > Unable to handle kernel paging request at virtual address ffff000008e460d8 > pgd = ffff800003504000 > [ffff000008e460d8] *pgd=0000000083473003, *pud=0000000083503003, *pmd=0000000000000000 > Internal error: Oops: 9600004f [#1] PREEMPT SMP > > we'll see: > > Internal error: Attempting to write read-only memory: 9600004f [#1] PREEMPT SMP It's less than ideal to lose the fault address here. Arguably we should also log that for the userspace cases. It would also be nice to keep the table dump for the kernel fault case, since dodgy page tables are a likely case there. > @@ -331,6 +331,11 @@ static int __kprobes do_page_fault(unsigned long addr, unsigned int esr, > > if (!search_exception_tables(regs->pc)) > die("Accessing user space memory outside uaccess.h routines", regs, esr); > + } else if (is_permission_fault(esr, regs)) { > + if (esr & ESR_ELx_WNR) > + die("Attempting to write read-only memory", regs, esr); > + else > + die("Attempting to read unreadable memory", regs, esr); > } We won't have looked at the exception tables yet, so won't this make probe_kernel_{read,write}(), or any other extable users unsafe? Could we update __do_kernel_fault() to report faults more thoroughly instead? Thanks, Mark. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754557AbdBPLGW (ORCPT ); Thu, 16 Feb 2017 06:06:22 -0500 Received: from mail-eopbgr40058.outbound.protection.outlook.com ([40.107.4.58]:10656 "EHLO EUR03-DB5-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753333AbdBPLGT (ORCPT ); Thu, 16 Feb 2017 06:06:19 -0500 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Mark.Rutland@arm.com; Date: Thu, 16 Feb 2017 11:06:12 +0000 From: Mark Rutland To: Stephen Boyd CC: Catalin Marinas , Will Deacon , , , Laura Abbott , Subject: Re: [PATCH] arm64: print a fault message when attempting to write RO memory Message-ID: <20170216110612.GA32039@leverpostej> References: <20170216015408.12933-1-stephen.boyd@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20170216015408.12933-1-stephen.boyd@linaro.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Originating-IP: [217.140.96.140] X-ClientProxiedBy: AM5PR0601CA0045.eurprd06.prod.outlook.com (10.173.86.159) To AM5PR0802MB2385.eurprd08.prod.outlook.com (10.175.43.147) X-MS-Office365-Filtering-Correlation-Id: 577c2c05-9c8c-48d5-de7d-08d4565bd42b X-MS-Office365-Filtering-HT: Tenant X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(48565401081);SRVR:AM5PR0802MB2385; X-Microsoft-Exchange-Diagnostics: 1;AM5PR0802MB2385;3:FZkhVl+PfmLN9qW/Kfd67YhU/DnD6Y6UZJ+dAUynYMY/ikzho7HsnQBbB/5Qw+5WcFyk2y/HVelA6TjgDktErgZyWN6g0X3LpU8UXIoKfmi8daoVopkpHfgZI7jTCnN1eN93SSkkj261KAxwQB1Zu4HkrQArzmH95YhgzW4O6pymDthOYSSvKSYHJyZtdIky98gc32lpdiUZqOeqo89QS3g4wjsFrKsFf5yji/aYnS5pWWVxLeJAE+h6SdZyza+Lu1A2qlgbiiZZGiQUAQyFVxem4UdKdWYXGZg1Q863LWs=;25:zZua47dT9zWQ3bYM2aLW7Gcu7i2AVWuygpuuNm/rCZqWfAE2S+Kg9bQrR9i+XR7AC/f1AWoK9VOmk/05bLXRWJ6wUCPmEFWiDTtHeVqtc4miT7NZ9rfbw+5eZtbpk3rIfl8+4tB+4FL8JYbqRtny5i3bBPXluEqE6pH1F1n1xfCnOoFEGvRMm84NpZYspsN+1333s82wopuIqf7bIFgORhS9IZdiTBtIRuAVZ6qt1mKvOwcbE/OndWeGvN3S3YPz6zQiFRkSkTWnaJsAPEHtLXOBpJkOr7ThlAh2LPtq+cNHEFjyi+tSsVaEzrpwpMHAr2z7P/g2a6JShyjPeD/RMF8WHRGrkHvyyIVhnesnMBELnvWAarizN9MVUY+bhfXWf2aROdrTRAiTVUYj0ffosG3kjao2EMPHHvnyK+AsJV+jssWGx/a3ZzxTQqC/l5V1gEXETnF4S9M29ctLKr48RA== X-Microsoft-Exchange-Diagnostics: 1;AM5PR0802MB2385;31:fEgyjDMlvDiUUVaU+1M4TBIqOSXL4X7TnttC1o8FqUFmD5Qsy/0TFVs3+zDqklCbu+e3TlOMb9jrT3SLytEkJpcBWBjlD3JB3/JzyJCccm9xqHNj+nPzVNreoBPEkTqFJ90GQFU4LNnDqWQXM+m1CxCrKIs/8pMRAFeOWdt6bDtJMhnKMKCXsSx63mEbmz9V+SQqhFIbL6CIQnlPXVt2ltxhubYVHBi0cvKJjWO4Ejk=;20:pS6W4cKgnTN2PBs6g7/m+XUs/xFh4p6jCGw+6LoCHVagovk9vk9Dtw//PjKPZec9YrHwTO5DD1NkSnePC4U3w0qJbEEE4x/gDJUPWPN9yFP2+v9XwMcRHMtyVgxgd7SXSto9jtltC9PhtiKotSB/TzJTJ9kk/ocsHjBRQ3O2rXkqVoa3bUEx6MfkAJ35HMSZezGcyqf1qgDhzzCcBrOlIEOGqqjnQocKWorG348vhLxKZB9bHG64GgtwW7TN2kXvISsJ9eoPmdhKPRfI7LzRpn6QFIeG0c51nbGnLFxTUCjtpBJ5mdKk6VBZMBgRtJEMS3aGlA7LajU7dntfDlaWj9YaRU9YVC9Bn9qwlTye187t43P9Wcsuxd7Zwo3g6+iT5cb2B0qMnqHv6v2tHNysshOt+DV3boIHUdaEDWr/swM/39GTdz6uBmYa3vH4LuzF+2/rX5KQi3ich72wUB0jhqk/D8UFOb9l7RPHu22G4z6QIUjEXZk8PMi6LvhW1FbQ 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)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123560025)(20161123562025)(20161123558025)(20161123564025)(6072148);SRVR:AM5PR0802MB2385;BCL:0;PCL:0;RULEID:;SRVR:AM5PR0802MB2385; X-Microsoft-Exchange-Diagnostics: 1;AM5PR0802MB2385;4:QSGwL4BAOJOpbhFirns13qDtq68xtEVZvjdWQIWDjpw2uJFReTjfMENQb4ZH6Lh57U2VpBvqqp5e2CiBCxDtirkPglQzuXO7BFqhaZ9g7zmj+JnuhsW5xj+Ykrw7eQ1BXihmaQvGELnSGMkJvGjWb5ny36lu5elz6WT/KYKHmnnqkfscG2k4HcDhsK7Z9XMuDsQtfWuqNGZ0q8CmHZFt2YsDuTXfYjLEKBLtY8a2fjqDaH3i1DT+GqjKJOnF6g2T/nfbsF/Ys8D1fcNsxEo+eu3mwPDOXBSLUK+2qiFVj/f2f2RdvqhR9E7wa0JKLh4EIhwkyK1MDzpowE58nEL1smTmERyrrotps88/fGs7iadUCMy/2zy9CZj6mT2XSaLgdy2V9b1U8UkTnhb29yOVGCLnfHu+R/kCMXRSOapOCJsK17+QSMZU9/djhO7uAWsl7iGgsc2q+QCDQ/fehVmf5yFR0dofBBHU1HK9q4tOIZmysApXQ/pnYuWmn9/2gNPlgLZelPSAUvcVpQwTT9fbGfB75j8JLWpYPq7LeBqy3dMytF1XnavHEtqXQidzNJ7b0i8oFvboJRB0Ir0UXNzfCqDtcFR7r9klzsCZkoZ9lPPEwLT7nar2eTcOORrPcYK/ X-Forefront-PRVS: 0220D4B98D X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(4630300001)(6009001)(7916002)(39840400002)(39410400002)(39850400002)(39450400003)(39860400002)(189002)(199003)(24454002)(40434004)(54356999)(50986999)(6246003)(5660300001)(15650500001)(76176999)(8746002)(25786008)(38730400002)(110136004)(81166006)(305945005)(81156014)(8676002)(9686003)(33716001)(33656002)(6916009)(2950100002)(389900003)(6666003)(5890100001)(53936002)(229853002)(6496005)(83506001)(68736007)(46406003)(23726003)(92566002)(101416001)(42186005)(1076002)(105586002)(97736004)(189998001)(2906002)(50466002)(4001350100001)(86362001)(55016002)(47776003)(97756001)(106356001)(4326007)(7736002)(54906002)(6116002)(3846002)(66066001)(18370500001);DIR:OUT;SFP:1101;SCL:1;SRVR:AM5PR0802MB2385;H:leverpostej;FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1;AM5PR0802MB2385;23:GsseJKs2xaCmXi7VrXy/Ythr2kxVaBdNFodQvC1?= =?us-ascii?Q?4UTXK2oyLedfWYygdXBdxKnd9b3xjeKOsL028wF2tHQu9tvKtaMLnsBlv//H?= =?us-ascii?Q?eZ7pA38lMjHqFKdmDbKK7YgRCId7o5CsLcUO/0bRaWG0lo4X0+ll2c6UvDvo?= =?us-ascii?Q?GGERIo9Xd9SEvAoJ82wNf/JlzBA3418KG+H3xl5T7qFrHD6NJ8y1nqH4fz5N?= =?us-ascii?Q?4TgPNTOl1Q/UjX1Dn5q/qnrSAUdKX23iwdZBOwl/LEfoU4K3a1pEHWG+XLZK?= =?us-ascii?Q?7BYrzjPZCkiGfUd5hSeERMRX18RZY377rw4LuOTGojU9JcDdEA/ML8NtIAew?= =?us-ascii?Q?omo6PgmQLPK696ticFZy5z3zOZ8wqHe1DpB+cZZTEuWj+hc8ACX/v1WFjBvq?= =?us-ascii?Q?3yI8jkjZJuzJBGrkGdnjjwgukzNOsyjkowCghwMCEhFYxfiDzglcOiTmXfiK?= =?us-ascii?Q?g7ypAgMs+YH44Zu6ZKuh/Ws564pEHuUAUdfzIA16lKy7p916hFNLrhX3XxDQ?= =?us-ascii?Q?c2wInuVpADTVSpheygrDqgokd32jaUQ0qNS5hTRWSulSqANQrc9aBB/+xGUI?= =?us-ascii?Q?AgNb4bUz0GY83r3AcjvB+TBoW2jLppy449fbp8ZV9fPnbPDrWg92eiZVbC2n?= =?us-ascii?Q?dYt62HAE87MVAjIOpKYDi5xY1BCU0FT710Kc+xzNoYcrfcGSU8eatytQjTpQ?= =?us-ascii?Q?8spyPDIlHVRuMqHWjlNfrl95m9OwzANc15LTwqC53MCNoWGH8EnldxvAKwCy?= =?us-ascii?Q?qCNsBWj1unxGsEzmvZruAS6vCkdDbbI9d2SIAI0CMOHJaNEdrhFfcC6gV/pG?= =?us-ascii?Q?EqBnmGwJGIKMu/QuuzHc5k8TkdzbLMFqfwtGyY2kg3gwuR5fRmA9A5KudbYh?= =?us-ascii?Q?9mEI6nyL0htFmU14p7kniGWfOAWuVg8UpVNMRomenbH2h6MXyOm6Z/7PdSCU?= =?us-ascii?Q?jDKkSoFFlwqgXL4xWCb+FVIjXMDHov7BtrbzoPGYSuW3ntQbXE2aS1Afa8ZC?= =?us-ascii?Q?80IRauNfmAjlUkZbPczhoW7s1TwZl0vE0rSmnG+LzdnbiO1YKhWQPvcXq93F?= =?us-ascii?Q?kFkWHsw6D7EUdOUSWsJCxvcTewDE+6/VG1opetzRs20xKrZWA05ZkTW/Cq5n?= =?us-ascii?Q?UoCPTnY8OxEc+8GdjNx53SR174+soB9TCjbiq7G5rN05efmAbAOsP+UPnQlH?= =?us-ascii?Q?lqj/cJNU1l/lebqfNZyDh3RkQrtGhn+D7QajPyWmXPl778TfOS/+1btqWtMQ?= =?us-ascii?Q?KYwdWZv9LpU4m9RyeFYIt7EaYhWHIVzwlY/SjCFALd92YatYMEgr2gKwerfz?= =?us-ascii?Q?tj2KH94exgTZ/MIh1GykBy6eoDPCY/PAzV9awh+E9ccLULqe4wFGqV0iTK4c?= =?us-ascii?Q?CjkSv/HCy9eebFq5pW9NKDLTuFuKiy3jFMiJ4xDjlJ/8X6TMhTXIoY3BvzZq?= =?us-ascii?Q?VU68oIp8wt0erSLWG6l8a/TbbHrgo2T2LJU6ce2uFUfVioBZAHcY59SOVOTu?= =?us-ascii?Q?CJib6AyA301ZOpmtl5m/ricdz06juBHHUMPz0uWAcpbNox3p7j3Ufc78S?= X-Microsoft-Exchange-Diagnostics: 1;AM5PR0802MB2385;6:qqen8hiTxxPMxUNCy7g3KJ6l1GXRxWlRTdkq1HV7G4WHBt/rnkHQIqXW2qNtrpWIk4d+jAaXlKv+zy8skUk5Drn2BW8pxkFqybGo0PdRW0ngphHzvzLtojjDeDs4r5qGs2o0wjM4K0/VYHJwOxcHV7lhz5tPgoSpolLJrQnjITGIKqFASBkYK1v05rLXzaAkdQ66XHESm4INO29n9NvIwaqydrEOEFeGS5z7cSknVjG2/l0MWNK4kujEYAsfIQhALb9s37F6pCqco2Heh8L3CygkMJoe0asDC/T5yV5z3EpBH3G82XAQHIflRSPbhkMLbO4gV0HP4a0QoyRlQg9Ss9aDdQXLUBxPtY3zbVGZof7RN9z4O7p5oBgwm+NYO2Ng7CLzQCq+ePfL4vNx6DX66NX32voldVbVR81eD7d5o1I=;5:xZpJd8TD9RAmugmCFwLUIGcSMiHEptMf20pZlXtIyOI3Kmglo+ChIJCYqb6IugqoxxAr1hrFR6SkbAXQz0pScnNXNk/GbH/lgS9jSPia0a4oYUAlbXIbfnAz08+6zcxXIKbNWtRsveE1EoDyuykByxWtD+Qbe72VyS9C2QUXhPs=;24:Vtox+3I0l0MKWBQ3enLp2XRadV3lh8LXTlZnI1N2kfKRk8nc48Pc6ukK5ehhXo53Q3NZrWgVx7lR0gGUXcYNUCEYTRPE3vuOHoIhZCZDSwY= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;AM5PR0802MB2385;7:NxPzbsY5ATWQXz/cpVPjZ6+DtjcubxpO61i9RR3fmw9Q1nfbqr4nAsjpurIkSPKEIAHFDY8M6c7E47krdvz5aE9UdYRe0dWXBJLhp+dJI+NVdpLLRfywwAjJwkDSbuKvDtHlgypfJp+XnrejB6pBIGYP2R0iuR1wtCUCtGoyqAHQyhwG/una5eDwTkTiU/enjkOcrIg3o5KDdQgbotx18wS2KquqL7ED98e1sG7Cv/pMOygbW1wZnQ6H7J2koHFTjzkHcoFK/+LVA9dBcqIldCmilvxKQmFupd7WAqJ8vmwoEZUVl4rmYjvmV8SzkpSwoclFsx/veGA0ovLab7R41Q== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Feb 2017 11:06:16.5808 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0802MB2385 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id v1GB6kF6028332 Hi, On Wed, Feb 15, 2017 at 05:54:08PM -0800, Stephen Boyd wrote: > If a page is marked read only we should print out that fact, > instead of printing out that there was a page fault. Right now we > get a cryptic error message that something went wrong with an > unhandled fault, but we don't evaluate the esr to figure out that > it was a read/write permission fault. > > Instead of seeing: > > Unable to handle kernel paging request at virtual address ffff000008e460d8 > pgd = ffff800003504000 > [ffff000008e460d8] *pgd=0000000083473003, *pud=0000000083503003, *pmd=0000000000000000 > Internal error: Oops: 9600004f [#1] PREEMPT SMP > > we'll see: > > Internal error: Attempting to write read-only memory: 9600004f [#1] PREEMPT SMP It's less than ideal to lose the fault address here. Arguably we should also log that for the userspace cases. It would also be nice to keep the table dump for the kernel fault case, since dodgy page tables are a likely case there. > @@ -331,6 +331,11 @@ static int __kprobes do_page_fault(unsigned long addr, unsigned int esr, > > if (!search_exception_tables(regs->pc)) > die("Accessing user space memory outside uaccess.h routines", regs, esr); > + } else if (is_permission_fault(esr, regs)) { > + if (esr & ESR_ELx_WNR) > + die("Attempting to write read-only memory", regs, esr); > + else > + die("Attempting to read unreadable memory", regs, esr); > } We won't have looked at the exception tables yet, so won't this make probe_kernel_{read,write}(), or any other extable users unsafe? Could we update __do_kernel_fault() to report faults more thoroughly instead? Thanks, Mark. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.