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
| ||
|
Date: Mon, 4 Aug 2014 13:19:59 +0100 From: Matt Fleming <matt@...sole-pimps.org> To: Josh Triplett <josh@...htriplett.org> Cc: Matt Fleming <matt.fleming@...el.com>, Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, "H. Peter Anvin" <hpa@...or.com>, x86@...nel.org, linux-efi@...r.kernel.org, linux-kernel@...r.kernel.org, Srihari Vijayaraghavan <linux.bug.reporting@...il.com>, Andrew Morton <akpm@...ux-foundation.org>, Matthew Garrett <mjg59@...f.ucam.org> Subject: Re: [PATCH] efi-bgrt: Add error handling; inform the user when ignoring the BGRT On Fri, 01 Aug, at 09:11:54AM, Josh Triplett wrote: > > The original bug report was about an allocation failure for a fairly > reasonable BGRT size. We can certainly prohibit absurdly huge ones (for > instance, bigger than the maximum likely screen resolution times 4 bytes > per pixel), but allocation failures may well occur for smaller sizes, > and I don't think we want to spew a massive warning for that either. Oh, dammit, that's my bad. I misread the allocation size and thought it was huge, but now realise it was only 6MB or so. Sorry Josh. I was worried that this was the first reported instance of a BGRT claiming to be valid but with a bogusly large image size. I've never been so happy to be wrong. However, the fact that the allocation failed is worth investigating - this machine appears to have GBs of ram. Perhaps we should switch to requesting pages directly instead of relying on kmalloc()? I appreciate that the BGRT code isn't mission critical or anything like that, and that failing the alloc isn't the end of the world, but if we have code in the kernel it should really be as robust as possible. I don't think trying to kmalloc() ~6MB can claim to be robust. -- 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/
Powered by blists - more mailing lists