From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754861AbcDYOdT (ORCPT ); Mon, 25 Apr 2016 10:33:19 -0400 Received: from eu-smtp-delivery-143.mimecast.com ([207.82.80.143]:53472 "EHLO eu-smtp-delivery-143.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754780AbcDYOdO convert rfc822-to-8bit (ORCPT ); Mon, 25 Apr 2016 10:33:14 -0400 Subject: Re: [PATCHv3 1/5] efi/runtime-wrappers: detect FW irq flag corruption To: Matt Fleming , Ard Biesheuvel References: <1461591994-14918-1-git-send-email-mark.rutland@arm.com> <1461591994-14918-2-git-send-email-mark.rutland@arm.com> <571E25B1.8070305@arm.com> <20160425141557.GA2829@codeblueprint.co.uk> <20160425142435.GB2829@codeblueprint.co.uk> CC: Mark Rutland , "linux-efi@vger.kernel.org" , Russell King - ARM Linux , Catalin Marinas , Will Deacon , "linux-kernel@vger.kernel.org" , Leif Lindholm , "mingo@redhat.com" , "hpa@zytor.com" , "tglx@linutronix.de" , "linux-arm-kernel@lists.infradead.org" From: Robin Murphy Message-ID: <571E2A9E.3010407@arm.com> Date: Mon, 25 Apr 2016 15:33:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160425142435.GB2829@codeblueprint.co.uk> X-Originating-IP: [217.140.96.140] X-ClientProxiedBy: HE1PR02CA0084.eurprd02.prod.outlook.com (10.163.170.52) To AM4PR08MB1188.eurprd08.prod.outlook.com (10.167.92.20) X-MS-Office365-Filtering-Correlation-Id: 9a487b08-4ec5-4deb-511b-08d36d1685f3 X-Microsoft-Exchange-Diagnostics: 1;AM4PR08MB1188;2:1JE/2+CGK6FwIPX0oW2/QvG9RDPbn1LTfq5qvjJ0/omh3ES6DgIyhhzawVRtMP6gzEi0DrsJTsIeoQ39mM4gcirL3+Sb61YtTd0vlbcVx2RBBQYDdwSKughG2pU+ItF5mcIvr9a6+2p9vM8MyaftPqCXc+1J0+4crjnrFkK6GLyGAN0r3BEwg/LxKoPE0vIY;3:+cwwpZp8Jt7ccSaoOzSsmPoKmESDC1FyU5CRByl7fkn5n670Tu/DyvIh22qVUIRzZdivCcg/VPt5QmrjQKWSto5TqkIHb5e9e0ym0Qyhtb60SFHuI6r3TQ7sVACU0Gaa X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM4PR08MB1188; X-Microsoft-Exchange-Diagnostics: 1;AM4PR08MB1188;25:m+a1PRqwYnOWTeBqLjOdppS/Hg2W6f2mn9Gthi70d6Z8cgVcYl14u41s8GWAmCIImuFwDxOS3KcFGLNF9MP6m4GzHWFgpASG0r+rQe8DTYYnMWNGI5rnoagl8XFbge4+qacg0zqGUGC9swaB19aQd1NJRp7XdFu4c8iCmaNS+zyj3UOJM/ULMOuy8j0WWiAV3POHdRGynWgbJ/KjajOsWYomqc8dQMV+4mPeER6uZvpwHnLEq0Qv0UInDESqu/tN1tWF2hmVSf7IGbQUjR/Q5QBQk74hzpv6kbe/OvmdqLt2y5TE3M3xn6hqXGhkJZwkNP3+BdHFGPx2p0CD57GNXBYcDOAARv24ekY0yL6SOppvF3Z/VmLgdWmeKIlBgEzU4WN2/5UujNV8xteIDFKMJy83KuNY1RKndc8w597wcTCaRJFDU5Oq4xqQwFjWMP9U8EFRyv5oQH3JxNPG8MZP+DiAT2ChYn+gPViS126EdroH3ivJcrT+AahHYmUCx4S0s/4qd/M0dwfpMHeuMxtXG8aRjDoR5vyTvoFenqkWlngrvRbRNmrr/JG6eCrqP561/iyP+3eeoDuXvzJBxU9dr/rWxKSzpRilSaw+soDLvd8aoymeNyQKtkpRbV0Aizkq5equVqNeUImkddi2MTeaa6O+7fa7OYEkylJwMm4Z+XVxVpXVLdhrriRlKUeo72SC;20:hh3qX7WWLX9qHEU7vGU5iCh3hs+TJx1qX3/A5eenRpXsaQUNaQNoPhcHrEirL9SKGEGh/7Ogt9SSns+N9cUKEIRkroRbvmSs9NPOBCssagzbSA3iPP/30sSY6A5LlJtZW0iGRW+q+srW/wh/Jf2QVEK6txsvBeOI17vEGUrOrlRRxreECyG5AdTN//BNcD2g1gBe2rzOO+N79nV+uc3gfrvnML7Z9Yo4Alx/VsCMALsAE33muY58iWIannZzJ2ZF X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(9101521062)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026);SRVR:AM4PR08MB1188;BCL:0;PCL:0;RULEID:;SRVR:AM4PR08MB1188; X-Microsoft-Exchange-Diagnostics: 1;AM4PR08MB1188;4:W1DqUn2XsHqIND7SmbrK2Yq78CxjLigBBFopyetWz2GAfMIyQ6g7lGuPn7OLmqu15dDKLYVd4g+8w3ihhUJyFGQgHZL3XelmKrVyePd3N6nRPMgvfqGWOa9N+q8K+qZytU58B4pohmrY0LhCbu+p0Nk2QNKECivKkB31WDinxj/FTfsq6JJrU2G+HV/qK49KyQDAubAX9w0F7zbCAJmZ2ZoibUHSawhiZnIB5ViBH4sgBaFeJxXP7PzzdHkoTvjneUAHitY2vZiBPP3Wjk7klhgRGCUM6QfwEJM9U7Q2fG1po6HmZjIm7I3QM1kk3CIhbQ4V0m+uZnroyOQ4ERPAc2qqiriok78sy3JK95IFXQPS8uWhxq84X+3hYIkp4dKXXFZiSrW8PGdJXY6oAzFRxk2YEsAfAbcTVVM+bbaktWg= X-Forefront-PRVS: 0923977CCA X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(4630300001)(6049001)(6009001)(24454002)(40434004)(92566002)(64126003)(42186005)(586003)(2906002)(81166005)(59896002)(93886004)(19580395003)(19580405001)(47776003)(77096005)(23746002)(50466002)(36756003)(66066001)(33656002)(6116002)(4326007)(65816999)(65956001)(86362001)(3846002)(5890100001)(4001350100001)(189998001)(1096002)(50986999)(5001770100001)(5004730100002)(54356999)(76176999)(87266999);DIR:OUT;SFP:1101;SCL:1;SRVR:AM4PR08MB1188;H:[10.1.205.154];FPR:;SPF:None;MLV:sfv;LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1;AM4PR08MB1188;23:qezeYXHAfi66bNyy79uZPT/uINpmX1c8+sGet?= =?Windows-1252?Q?GWXLAlEtIwq56dxEbY6lMiFnOrcA6mqneJN0pPqIq1jgwVrcaW4DaQSs?= =?Windows-1252?Q?GlT1kcjMzf+0Rw4cImMy2/XYxIFYa9OcxsdT4Y5/ISLnM6IZVkGfAa8J?= =?Windows-1252?Q?kC+2D8AInqysE1xnfio+ZYIT9Z3rI489CR/Q6btvsnLvaLa/vnI5v+6w?= =?Windows-1252?Q?SImSMn5AM+BwbyFE54FZEJCLKQvpBeZwtseZmdFtE+4o1SSQ8KKCcwV/?= =?Windows-1252?Q?IepSwiNhj/sApSbXtUHn46hMoJlgw21wCmiB8vr9lSYdgYGH/KN2Dsqk?= =?Windows-1252?Q?sZGObN67EtrVMk4rJbbMWYl7j6TjBqaU8WI4h6W2cbNzXNwxPfh0Pf3h?= =?Windows-1252?Q?GI2oYhj4vNiY32MRhbAe86TcHahcwzorJ9qwVF0AV2rkCZsBbLugge2a?= =?Windows-1252?Q?muOMKpr6fz85GV6qoQkd845qT1+fbJj6LkjNWZVk4W4w5GS8X7TTKYmC?= =?Windows-1252?Q?GsUTTAXlvoSEy4Cn7hcV6+i3f8Reh4wt7zyqAGXH5yrJE65dqwq2ARFi?= =?Windows-1252?Q?+JnpT4OK2DwcAWAOlwhPxdfp4JREfRxy6+kCOGD8Lt2wq0N/MHI1e2aa?= =?Windows-1252?Q?IW01XhtYPXAKfLnpYiDVBpvxW59gFUcSvgUiOov4kkd3H3NYGqBxo9Uq?= =?Windows-1252?Q?Y37k8nvgvhVPDml9fiR3tSdHAZOZLC8CkE7Nd94HFJa9h+LjNr4/YLG5?= =?Windows-1252?Q?0bLadHKvZd4vwuyxZOgWvabGGlGQv5CwwCBLK5Rziid4AJUuPZ8JWmkk?= =?Windows-1252?Q?G6gwvhmR3KmThmvLY/1tzk0e3/6i2uyDVM6OeJIGjTNxQA4XxsB2eDAk?= =?Windows-1252?Q?EBFhBpjyfMebt7GnzfFmnFR59o6R7GtJHZ7iULMzB1stjGZ22IHuEjYy?= =?Windows-1252?Q?WGU07j6S3iAG/zOiBMOf4a/ACOwsDeZEYg5aVdiyQSyHBW9BkEf4vwtw?= =?Windows-1252?Q?igDxR16duEmGmNpc0Kuf24t5PqqOffoFavpscPLpuP3w/tX2nxtzvGfY?= =?Windows-1252?Q?ePrp9RvmxpDw6qymV3LecJQr+xakeXrzWVc?= X-Microsoft-Exchange-Diagnostics: 1;AM4PR08MB1188;5:nZJNjjmbiSoYxJYGYELJTDAHGKdnOUDX0DXVmhS24nq+/oUbCRIrjhE13iET++qIkBFMmtfRHSW1V8K631+txguODXkj4092OpjdkEX3bqEZzweYN8uZFQMSFnxdkBZF5YRQAutjlanstD8Fp23NVlxes1ja3Gg6GYwBDl0NpvdwNcihpIekLFxugdV394u6;24:YRxDJ+8alzW1AYxmD7ugYbacwzTE8+MlrWRHd8dT5zNmbPautV4Yvqj+1pg7r1j6EtYcyvPsC2tGUbyFk+lV27LOXw3puZKvPgykUxLcU7o=;7:QMyW7GAQk87ohXQF5ett2ZcwcRlgfh80KXyWyB2htVnGFSOhpXzbEwF9/2EbUME6jQD6O7ve+Nm2eci/zN25EqK/OMfZfZZSusoe9UHmqNZnHsVaCeqwBT23Fb49DBgSXZctzt0ljj3mZ2eUWyRWuBsE3A9HY7pCA0kVZxMBsCQLbbFuWDneCymyeCNLh6gokBZfpb3HpeXDVDv+U2Beuln3ISMoAUuMcE2Avd1L+Es=;20:e7nbs4BfEPuRMFMosD3H/fHMpDOx9M9iNbOV1E475fYBjdJ8EgyRfEaLmi0oUKtshboYxZhsSwDNTXGvz8uXL+oaOBzPhdHBI8OL79vYb6XYZG/UcbhSn4Gd+/oaAlyCQPnB8O/jpWI9zJ1e1GhIZrbT/Cvl4lNSHJuL3AKFmzM= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Apr 2016 14:33:08.1832 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR08MB1188 X-MC-Unique: v5M40_1SRB6CuRuVDirjeg-1 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 25/04/16 15:24, Matt Fleming wrote: > On Mon, 25 Apr, at 04:18:41PM, Ard Biesheuvel wrote: >> On 25 April 2016 at 16:15, Matt Fleming wrote: >>> On Mon, 25 Apr, at 03:12:01PM, Robin Murphy wrote: >>>>> +static void efi_call_virt_check_flags(unsigned long flags, const char *call) >>>>> +{ >>>>> + unsigned long cur_flags; >>>>> + bool mismatch; >>>>> + >>>>> + local_save_flags(cur_flags); >>>>> + >>>>> + mismatch = !!((cur_flags ^ flags) & ARCH_EFI_IRQ_FLAGS_MASK); >>>> >>>> nit: the assignment itself is already a conversion to bool, so the >>>> excitement is redundant here. >>> >>> This was intentional. I asked Mark to make this change so that it's >>> explicit for the developer that we're performing the type conversion. >> >> But replacing an implicit boolean cast with an explicit one makes >> little sense, no? Don't we simply want '!= 0' here if you need a >> boolean expression? > > Aha but '!!' is fewer characters to type!! > > I'm not that bothered as long as we don't stuff an int into a bool > without giving the programmer some idea we're doing that. It's not > about the compiler getting it wrong, more about a developer > introducing a bug when they change the code in the future. > > Unless anyone objects, I'll fix this up to use '!= 0' when I apply it. Agreed - the belt and braces approach isn't necessarily bad if the cost of cocking it up is significant, and !=0 is as explicit as you can get. After all, if Joe Random Hacker can't infer the behaviour from looking 4 lines up to see the variable definition, then I wouldn't count on him understanding !! either ;) Thanks, Robin. 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 From: Robin Murphy Subject: Re: [PATCHv3 1/5] efi/runtime-wrappers: detect FW irq flag corruption Date: Mon, 25 Apr 2016 15:33:02 +0100 Message-ID: <571E2A9E.3010407@arm.com> References: <1461591994-14918-1-git-send-email-mark.rutland@arm.com> <1461591994-14918-2-git-send-email-mark.rutland@arm.com> <571E25B1.8070305@arm.com> <20160425141557.GA2829@codeblueprint.co.uk> <20160425142435.GB2829@codeblueprint.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: 8BIT Return-path: In-Reply-To: <20160425142435.GB2829@codeblueprint.co.uk> Sender: linux-kernel-owner@vger.kernel.org To: Matt Fleming , Ard Biesheuvel Cc: Mark Rutland , "linux-efi@vger.kernel.org" , Russell King - ARM Linux , Catalin Marinas , Will Deacon , "linux-kernel@vger.kernel.org" , Leif Lindholm , "mingo@redhat.com" , "hpa@zytor.com" , "tglx@linutronix.de" , "linux-arm-kernel@lists.infradead.org" List-Id: linux-efi@vger.kernel.org On 25/04/16 15:24, Matt Fleming wrote: > On Mon, 25 Apr, at 04:18:41PM, Ard Biesheuvel wrote: >> On 25 April 2016 at 16:15, Matt Fleming wrote: >>> On Mon, 25 Apr, at 03:12:01PM, Robin Murphy wrote: >>>>> +static void efi_call_virt_check_flags(unsigned long flags, const char *call) >>>>> +{ >>>>> + unsigned long cur_flags; >>>>> + bool mismatch; >>>>> + >>>>> + local_save_flags(cur_flags); >>>>> + >>>>> + mismatch = !!((cur_flags ^ flags) & ARCH_EFI_IRQ_FLAGS_MASK); >>>> >>>> nit: the assignment itself is already a conversion to bool, so the >>>> excitement is redundant here. >>> >>> This was intentional. I asked Mark to make this change so that it's >>> explicit for the developer that we're performing the type conversion. >> >> But replacing an implicit boolean cast with an explicit one makes >> little sense, no? Don't we simply want '!= 0' here if you need a >> boolean expression? > > Aha but '!!' is fewer characters to type!! > > I'm not that bothered as long as we don't stuff an int into a bool > without giving the programmer some idea we're doing that. It's not > about the compiler getting it wrong, more about a developer > introducing a bug when they change the code in the future. > > Unless anyone objects, I'll fix this up to use '!= 0' when I apply it. Agreed - the belt and braces approach isn't necessarily bad if the cost of cocking it up is significant, and !=0 is as explicit as you can get. After all, if Joe Random Hacker can't infer the behaviour from looking 4 lines up to see the variable definition, then I wouldn't count on him understanding !! either ;) Thanks, Robin. 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 From: robin.murphy@arm.com (Robin Murphy) Date: Mon, 25 Apr 2016 15:33:02 +0100 Subject: [PATCHv3 1/5] efi/runtime-wrappers: detect FW irq flag corruption In-Reply-To: <20160425142435.GB2829@codeblueprint.co.uk> References: <1461591994-14918-1-git-send-email-mark.rutland@arm.com> <1461591994-14918-2-git-send-email-mark.rutland@arm.com> <571E25B1.8070305@arm.com> <20160425141557.GA2829@codeblueprint.co.uk> <20160425142435.GB2829@codeblueprint.co.uk> Message-ID: <571E2A9E.3010407@arm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 25/04/16 15:24, Matt Fleming wrote: > On Mon, 25 Apr, at 04:18:41PM, Ard Biesheuvel wrote: >> On 25 April 2016 at 16:15, Matt Fleming wrote: >>> On Mon, 25 Apr, at 03:12:01PM, Robin Murphy wrote: >>>>> +static void efi_call_virt_check_flags(unsigned long flags, const char *call) >>>>> +{ >>>>> + unsigned long cur_flags; >>>>> + bool mismatch; >>>>> + >>>>> + local_save_flags(cur_flags); >>>>> + >>>>> + mismatch = !!((cur_flags ^ flags) & ARCH_EFI_IRQ_FLAGS_MASK); >>>> >>>> nit: the assignment itself is already a conversion to bool, so the >>>> excitement is redundant here. >>> >>> This was intentional. I asked Mark to make this change so that it's >>> explicit for the developer that we're performing the type conversion. >> >> But replacing an implicit boolean cast with an explicit one makes >> little sense, no? Don't we simply want '!= 0' here if you need a >> boolean expression? > > Aha but '!!' is fewer characters to type!! > > I'm not that bothered as long as we don't stuff an int into a bool > without giving the programmer some idea we're doing that. It's not > about the compiler getting it wrong, more about a developer > introducing a bug when they change the code in the future. > > Unless anyone objects, I'll fix this up to use '!= 0' when I apply it. Agreed - the belt and braces approach isn't necessarily bad if the cost of cocking it up is significant, and !=0 is as explicit as you can get. After all, if Joe Random Hacker can't infer the behaviour from looking 4 lines up to see the variable definition, then I wouldn't count on him understanding !! either ;) Thanks, Robin. 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.