Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933393AbeALLZe (ORCPT + 1 other); Fri, 12 Jan 2018 06:25:34 -0500 Received: from userp2120.oracle.com ([156.151.31.85]:54156 "EHLO userp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932740AbeALLZb (ORCPT ); Fri, 12 Jan 2018 06:25:31 -0500 Date: Fri, 12 Jan 2018 12:24:50 +0100 From: Daniel Kiper To: Ard Biesheuvel Cc: Ingo Molnar , linux-efi@vger.kernel.org, Linux Kernel Mailing List , the arch/x86 maintainers , xen-devel , Boris Ostrovsky , "H. Peter Anvin" , Juergen Gross , Konrad Rzeszutek Wilk , Thomas Gleixner Subject: Re: [PATCH 0/4] x86/xen/efi: Initialize UEFI secure boot state during dom0 boot Message-ID: <20180112112450.GD21705@olila.local.net-space.pl> References: <1515507745-17391-1-git-send-email-daniel.kiper@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8771 signatures=668652 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=773 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801120153 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: Hi Ard, On Thu, Jan 11, 2018 at 12:51:07PM +0000, Ard Biesheuvel wrote: > On 9 January 2018 at 14:22, Daniel Kiper wrote: > > Hi, > > > > Initialize UEFI secure boot state during dom0 boot. Otherwise the kernel > > may not even know that it runs on secure boot enabled platform. > > Hi Daniel, > > I must say, I am not too thrilled with the approach you have chosen > here. #including .c files in other .c files, and using #defines to > override C functions or other stub functionality is rather fragile. In TBH I do not like it too. Sadly I have not find a better solution for that. I wish to avoid code duplication as much as possible because otherwise it will fall out of sync sooner or later (usually sooner). Similar thing happened in different part of Xen EFI code a few months ago. > particular, it means we have to start caring about not breaking > Xen/x86 code when making modifications to the EFI stub, and that code > is already difficult enough to maintain, given that it is shared > between ARM, arm64 and x86, and runs either from the decompressor or > the kernel proper (arm64) but in the context of the UEFI firmware. I understand that. > None of the stub code currently runs in ordinary kernel context. Yep. > So please, could you try to find another way to do this? I am happy to improve the situation, however, I am afraid that it is difficult here. Stub and kernel proper are separate entities and simple linking does not work. So, It seems to me that only play with includes will allow us to not duplicate the code. However, if you have a better idea I am happy to implement it. Daniel