lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 26 Oct 2007 10:48:39 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	"Huang, Ying" <ying.huang@...el.com>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...hat.com>,
	Andi Kleen <ak@...e.de>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Chandramouli Narayanan <mouli@...ux.intel.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: [PATCH 1/3 -v4] x86_64 EFI runtime service support: EFI basic
 runtime service support

On Fri, 26 Oct 2007, Huang, Ying wrote:

> On Thu, 2007-10-25 at 18:09 +0200, Thomas Gleixner wrote:
> > > EFI runtime
> > > services initialization are implemented in efi.c. Some x86_64
> > > specifics are worth noting here. On x86_64, parameters passed to UEFI
> > > firmware services need to follow the UEFI calling convention. For this
> > > purpose, a set of functions named lin2win<x> (<x> is the number of
> > > parameters) are implemented. EFI function calls are wrapped before
> > > calling the firmware service.
> > 
> > Why needs this to be called lin2win? We do not call Windows, we call
> > EFI services, so please use a naming convention which is related to
> > the functionality of the code.
> > 
> > > + *
> > > + *  Function calling ABI conversion from SYSV to Windows for x86_64
> > 
> > Again, these are wrappers to access EFI and not Windows.
> 
> EFI uses the Windows x86_64 calling convention. The lin2win may be a
> more general naming convention that can be used for some other code (the
> NDISwrapper?) in the future. Do you agree?

I agree not at all. I do not care whether the EFI creators smoked the
Windows-crackpipe or some other hallucinogen when they decided to use
this calling convention. We definitely do not want to think about
NDISwrapper or any other Windows related hackery in the kernel.

I still do not understand why we need all this EFI hackery at all
aside of the possible usage for saving a crash dump on FLASH, which we
could do directly from the kernel as well.

    tglx
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ