Re: [TUHS] Unix APIs: elegant or not?

[Warner Losh <imp@bsdimp.com>]

[-- Attachment #1: Type: text/plain, Size: 1850 bytes --]

On Thu, Nov 1, 2018 at 10:48 AM ron minnich <rminnich@gmail.com> wrote:

>
>
> On Thu, Nov 1, 2018 at 9:44 AM Warner Losh <imp@bsdimp.com> wrote:
>
>>
>>
>> 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.
>

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...


> 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

[-- Attachment #2: Type: text/html, Size: 2759 bytes --]