| 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: Sun, 1 Nov 2009 16:35:05 -0500 (EST) From: "Ryan C. Gordon" <icculus@...ulus.org> To: Måns Rullgård <mans@...sr.com> cc: linux-kernel@...r.kernel.org Subject: Re: FatELF patches... > It's not the size of the kernel patch I'm worried about. What worries > me is the disk space needed when *all* my executables and libraries > are suddenly 3, 4, or 5 times the size they need to be. Then don't make FatELF files with 5 binaries in it. Or don't make FatELF files at all. I glued two full Ubuntu installs together as a proof of concept, but I think if Ubuntu did this as a distribution-wide policy, then people would probably choose a different distribution. Then again, I hope Ubuntu uses FatELF on a handful of binaries, and removes the /lib64 and /lib32 directories. > There is also the issue of speed to launch these things. It *has* to > be slower than executing a native file directly. In that there will be one extra read of 128 bytes, yes, but I'm not sure that's a measurable performance hit. For regular ELF files, the overhead is approximately one extra branch instruction. Considering that most files won't be FatELF, that seems like an acceptable cost. > It's far too easy to use computers already. That's the reason for the > spam problem. Clearly that's going to remain as a philosophical difference between us, so I won't waste your time trying to dissuade you. --ryan. -- 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