linux-kernel - Re: [PATCH 1/2] UEFI arm64: add noefi boot param

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]

Message-ID: <20140806132021.GB15082@console-pimps.org>
Date:	Wed, 6 Aug 2014 14:20:21 +0100
From:	Matt Fleming <matt@...sole-pimps.org>
To:	Leif Lindholm <leif.lindholm@...aro.org>
Cc:	Dave Young <dyoung@...hat.com>, catalin.marinas@....com,
	will.deacon@....com, matt.fleming@...el.com,
	ard.biesheuvel@...aro.org, msalter@...hat.com,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	linux-efi@...r.kernel.org
Subject: Re: [PATCH 1/2] UEFI arm64: add noefi boot param

On Wed, 06 Aug, at 02:06:23PM, Leif Lindholm wrote:
> On Wed, Aug 06, 2014 at 04:38:25PM +0800, Dave Young wrote:
> > 
> > Adding a noefi boot param like in X86 to disable efi runtime services support.
> > 
> > This will be useful for debugging uefi problems. Also it will be useful
> > for later kexec/kdump work. Kexec on uefi support in X86 depends on a fixed vm
> > area specific for uefi runtime 1:1 mapping, kernel will switch to a different
> > page table for any uefi runtime callback in virtual mode. In arm64 similar
> > work probably is necessary. But kexec boot will just works with 'noefi' with
> > the limitaion of lacking runtime services. The runtime services is not critical
> > for kdump kernel for now. So as for kexec/kdump just leave the 1:1 mapping a
> > future work.
> 
> Since this is really turning an x86-specific feature into a generic
> one, could it be moved to core code?
> Maybe an efi.mask, reusing the efi_enabled defines, with an
> efi_disabled macro?
 
Why the new efi_disabled() and efi.mask? This is all achievable with
efi_enabled() and efi.flags, in fact, this kind of thing is exactly why
they were invented.

> Also, since this patch (and its x86 predecessor) is not really
> "noefi", could this be integrated with the "efi=" patch
> (http://permalink.gmane.org/gmane.linux.kernel.efi/4405),
> as an efi=noruntime option?
> 
> On x86, due to CSM, "noefi" was a useful fallback for completely
> broken (U)EFI implementations - but on an arm* UEFI system, there will
> be no fallback. Could it be wrapped in a kernel hacking config option?
 
I don't mind making "noefi" a synonym for "efi=noruntime" on x86, as
long as we keep "noefi" around with the same semantics it's always had.

And certainly if you're coming at this anew (like on arm(64)), I agree
"efi=noruntime" just makes a ton more sense than "noefi".

-- 
Matt Fleming, Intel Open Source Technology Center
--
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/