Hi, On Sun, Jan 03, 2010 at 11:42:52AM +0100, olafbuddenha...@gmx.net wrote: > On Sat, Jan 02, 2010 at 12:11:38PM +0100, Carl Fredrik Hammar wrote: > > On Sat, Jan 02, 2010 at 08:12:17AM +0100, olafbuddenha...@gmx.net > > wrote: > > > On Fri, Jan 01, 2010 at 10:36:35PM +0100, Carl Fredrik Hammar wrote: > > > MIG does have a c_string type after all, which is used to define the > > string_t type used in the Hurd. > > I see. I just remembered that I was quite stumped to see string_t > defined with a constant size; but I didn't remember that it actually is > c_string of a constant size, not just a char array...
Same here. :-) > But if Mach actually knows C strings, are you sure the kernel doesn't > actually perform the check for 0-termination itself in the IPC code?... Yes, I attached gdb to a translator receiving an unterminated string and the string was indeed unterminated on arrival. Also, I don't think Mach's IPC knows about C strings, only MIG. > (Otherwise, the implementations of kernel functions like device_open() > would have to make sure strings are always terminated, too.) It seems device_open() doesn't check for it, but fixing MIG would cover this too. > > > > Fixing MIG seems much easier and safer. > > > > > > Yes -- but also more invasive... You'll have to find someone > > > confident enough to ack/commit the change :-) > > > I haven't looked yet, but I can't imagine it being less invasive than > > adding checks in *every* single program that receives strings in > > messages. > > I said more invasive. I didn't say more work. That's quite a different > thing :-) I still don't see how changing MIG is invasive... Regards, Fredrik
