| 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: Sat, 9 Apr 2016 13:37:42 +0100 From: One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk> To: Andrew Kelley <superjoe30@...il.com> Cc: linux-kernel@...r.kernel.org Subject: Re: alternatives to null-terminated byte arrays in syscalls in the future? On Fri, 8 Apr 2016 14:04:00 -0700 Andrew Kelley <superjoe30@...il.com> wrote: > The open syscall looks like this: > > SYSCALL_DEFINE3(open, const char __user *, filename, int, flags, umode_t, mode) > > filename is a null terminated byte array. Null termination is one way > to handle lengths of byte arrays, but arguably a better way is to keep > track of the length in a separate field. Many programming languages > use pointer + length instead of null termination for various reasons. > > When it's time to make a syscall such as open, software which does not > have a null character at the end of byte arrays are forced to allocate > memory, do a memcpy, insert a null byte, perform the open syscall, > then deallocate the memory. That should only happen if the language wasn't carefully thought out. If your name objects include both the length and the space available so you can do array offset validation then - you can check if the \0 will fit - your app or interreter can add space for \0 or even include it specifically I would also be very surprised if most applications doing such conversions even showed up meaningfully in the profiling. pathname syscalls are not the most common ones being executed. Alan
Powered by blists - more mailing lists