1 Nov
2018
1 Nov
'18
5:56 p.m.
On Thu, Nov 1, 2018 at 10:48 AM ron minnich <rminnich(a)gmail.com> wrote:
On Thu, Nov 1, 2018 at 9:44 AM Warner Losh <imp(a)bsdimp.com> wrote:
Well, if the nose of a camel comes in under the tent, the rest of the camel
is sure to follow... Parsing a string path is rock simple, but are there
two arguments or three for this command, and what happens if they are too
long, or negative when you expect and fd, or or or. The CVE-archive is
littered with people who thought parsing in the kernel was simple and
easy...
There's another school of thought too that says the kernel has no
business parsing strings with all the security implications of doing so...
yeah, it's an interesting question. But Unix is based on parsing strings.
The kernel already parses lots of strings for paths, for all kinds of
reasons, so adding another element in the kernel that uses paths seems
acceptable.
The bigger problem for Plan 9 that started to bite was
i8n. All the Plan 9
messages are English, oops. All the control messages are english. And so
on.
And, further, that network architecture I referenced is much less
efficient than the BSD model -- 5 system calls per accept! so that was
starting to hit us here on the Akaros project, since we imported the entire
Plan 9 network stack into akaros, along with the drivers. Linux left us in
the dust on network connections/second. We were going to change it had
Akaros continued.
That's the other reason to not do stings in the kernel: parsing is takes
time.
I'll grant there's a balance here: A single int fd is nice so you don't
have to pass a pointer to the device call function and provides a level of
abstraction that blocks many bad data attacks. But even with this interface
there's been issues with improper range checks for some interfaces.
Warner