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:31:19 +0800
From:	"Huang, Ying" <ying.huang@...el.com>
To:	"H. Peter Anvin" <hpa@...or.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Andi Kleen <ak@...e.de>, Thomas Gleixner <tglx@...utronix.de>
Cc:	Arjan van de Ven <arjan@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...hat.com>,
	Chandramouli Narayanan <mouli@...ux.intel.com>,
	LKML <linux-kernel@...r.kernel.org>, pjones@...hat.com
Subject: Re: [PATCH 1/3 -v4] x86_64 EFI runtime service support: EFI basic
	runtime service support

On Thu, 2007-10-25 at 15:29 -0700, H. Peter Anvin wrote:
> Eric W. Biederman wrote:
> > "H. Peter Anvin" <hpa@...or.com> writes:
> > 
> >> Eric W. Biederman wrote:
> >>>> Ying claimed that GOP requires EFI runtime services.  Is that not true?
> >>> None of the EFI framebuffer patches that I saw used EFI runtime services.
> >>>
> >> Ying, could you please clarify this situation?
> >>
> >> (Eric: do note that there are two EFI framebuffer standard, UGA and
> >> GOP. Apparently UGA is obsolete and we have always been at war with GOP at the
> >> moment.)
> > 
> > Peter please look back in your email archives to yesterday and
> > see Ying's patch:
> > 
> > [PATCH 1/2 -v2 resend] x86_64 EFI boot support: EFI frame buffer driver
> > 
> > All of the data the GOP needs is acquired through the a query made
> > by the bootloader and passed through screen info.
> > 
> 
> Then I fully agree with your assessment.

EFI framebuffer doesn't depend on EFI runtime service.

But EFI variable service depends on EFI runtime service, and most people
think it is useful. It can be used to:

- Provide a standard method to communicate with BIOS, such as specifying
the boot device or bootloader for the next boot.
- Provide a standard method to write the OOPS information to flash.

To improve the reliability of OOPS information writing, the virtual mode
of EFI should be used. And through mapping all memory area used by EFI
to the same virtual address across kexec, EFI can work with kexec under
virtual mode just like that of IA-64.

So, I think the EFI runtime service is useful and it does not break
anything. But the code duplication between efi_32.c and efi_64.c should
be eliminated and I will work on this.

Best Regards,
Huang Ying
-
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