| 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: Fri, 27 Sep 2013 22:15:37 +0100 From: Russell King - ARM Linux <linux@....linux.org.uk> To: Vojtech Bocek <vbocek@...il.com> Cc: linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org Subject: Re: About atags_proc buffer size On Fri, Sep 27, 2013 at 11:09:13PM +0200, Vojtech Bocek wrote: > It only needs to survive until init_atags_procfs is called, because it is > copied to another buffer for procfs entry. Can I be sure it survives until > that? My guess is that it is likely to survive, but not certain. > > I suppose it is possible to somehow protect that bit of ram until it is > read by init_atags_procfs, but I wonder if you even want to do that in > mainline - if majority of devices doesn't use such big tag lists, then > it is probably that device's vendor problem. I've met this problem on two > devices so far though, both of them Android phones, one is the HTC One > (that is MSM APQ8064 SoC) and I unfortunately can't remember the first > one - I discarded it as usual Android kernel's mess. We've been through several early allocators - particularly one which allocates from the bottom of memory upwards, which would overwrite the ATAGs long before init_atags_procfs gets called. If we rely on the behaviour of the current early allocator not to touch that, and it changes in the future, that's going to be rather too fragile. -- 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