linux-kernel - Re: [PATCH v4 07/12] efi: passing kexec necessary efi data via setup

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20131202024914.GD3999@dhcp-16-126.nay.redhat.com>
Date:	Mon, 2 Dec 2013 10:49:15 +0800
From:	Dave Young <dyoung@...hat.com>
To:	Borislav Petkov <bp@...en8.de>
Cc:	toshi.kani@...com, linux-kernel@...r.kernel.org,
	linux-efi@...r.kernel.org, x86@...nel.org, mjg59@...f.ucam.org,
	hpa@...or.com, James.Bottomley@...senPartnership.com,
	vgoyal@...hat.com, ebiederm@...ssion.com, horms@...ge.net.au,
	kexec@...ts.infradead.org, greg@...ah.com, matt@...sole-pimps.org
Subject: Re: [PATCH v4 07/12] efi: passing kexec necessary efi data via
 setup_data

On 11/29/13 at 05:46pm, Borislav Petkov wrote:
> On Fri, Nov 29, 2013 at 05:14:16PM +0800, Dave Young wrote:
> > That's reserved for future extension use, who knows if we will need to
> > pass other fields in the future.
> 
> Hrrmmm, 8*64 = 64 Bytes?? And you can't change it later because of the
> situation where machines might be using older kexec-tools?

Right, compatibility is the reason.

> 
> > > Static function - no need for "efi_" prefix.
> > 
> > Ok. I'm not very satisfied with the function name, any better
> > suggestion?
> > 
> > reuse_config
> > use_old_config_phys_addr
> > update_config_entry_with_phys_addr
> 
> Looks like we're applying quirks so apply_quirks()?

Ok, it looks better, will use apply_quirks, thank you.

> 
> And those kexec-specific quirks need to be behind CONFIG_KEXEC too, btw.

All these setup_data passing, remapping etc. is mostly for kexec, add
a lot of contiditional #if #endif makes the code a mess. I would prefer
to not do this if you are not strongly object. 

> 
> > Since Matt suggest to extend the function for other possible field
> > other than smbios, so I would like to move comment to the front
> > of the function like below:
> > /*
> >  * For kexec kernel there's some special config table entries which will be
> >  * converted to virtual addresses after entering virtual mode. In kexec kernel
> >  * we need the physical addresses instead, thus passing them via setup_data
> >  * and update the entries to physical addresses in this function.
> >  *
> >  * Currently only handles smbios which is necessary for HP z420.
> >  */
> 
> That's better.
> 
> > Is there any idea in your mind how to add the code for HP only?
> 
> DMI?

I'm confused how to connect this with DMI..

> 
> > Yes, __map_region return an error code will be better. Will you send
> > a patch for __map_region? or I can add one more patch along with next
> > version.
> 
> I was going to wait for your patches to settle down first so that I
> don't disturb your work.
> 
> But if you want to fix this, I certainly wouldn't want to stop you :)
> but please do so in a prepatch before your series which addresses only
> this issue.

Ok, so I will leave this to you after this series settle down.

Thanks
Dave
--
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/