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
| ||
|
Message-ID: <50C95832.5030306@zytor.com> Date: Wed, 12 Dec 2012 20:23:14 -0800 From: "H. Peter Anvin" <hpa@...or.com> To: Yinghai Lu <yinghai@...nel.org> CC: "Eric W. Biederman" <ebiederm@...ssion.com>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org> Subject: Re: kexec and struct boot_params On 12/12/2012 06:49 PM, Yinghai Lu wrote: >> >> Hi, Peter, >> >> What's your decision about this? >> >> Do you mean have one boot_params mask in initdata and AND that with >> boot_params from bootloader >> to clean not used bytes? >> >> So later will not need to check >> if (boot_params.hdr.xloadflags & USE_EXT_BOOT_PARAMS) >> ? >> >> I worked out other patches that remove kdump 896M limitation. >> would like to post those patches to get more testing. >> those are needed for bigger system with lots of pcie devices. > > > ping! > I still want to do what I mentioned before, because we need to not rely on the initialized/16-bit portion so much: 1. add a field in the uninitialized portion, call it "sentinel"; 2. make sure the byte position corresponding to the "sentinel" field is nonzero in the bzImage file; 3. if the kernel boots up and sentinel is nonzero, erase those fields that you identified as uninitialized; 4. assign a proper boot loader ID to kexec, so we have a way of dealing with this kind of debacles in the future (that is what the bootloader ID is for: it gives us a way to work around bootloader-specific problems.) We also need to formalize the 64-bit entry point properly, including all the entry conditions and so forth. That needs to be documented. Eric, any thoughts or additional opinions? -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- 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