[TUHS] UNIX of choice these days?

[Warner Losh]

On Mon, Sep 25, 2017 at 8:16 AM, Clem Cole <clemc at ccc.com> wrote:

>
>
> On Mon, Sep 25, 2017 at 8:07 AM, Norman Wilson <norman at oclsc.org> wrote:
>
>> ​...​
>>
>> I too am saddened to see such a retrograde step, but perhaps
>> I'm biased.  When I arrived in 1127, the kernel had /proc but
>> still had ptrace as well.  Why?  Because no one was brave enough
>> to wade into sdb and adb.
>>
>> ​...
>>
>>
>> I can sympathize with FreeBSD excuse someone cited elsewhere,
>> that nobody used the code so it should go--I'm always in favour
>> of improving programs by chopping sutff out--but I think the
>> decision here was backwards.  The proper answer would have been
>> to teach ps et al to use /proc, not to invent a new complex of
>> system calls.
>>
> ​+1 that was my point.   If the application code had been available @ UCB
> earlier before the proliferation,
> I think and /proc has been part of 4.2 or at least 4.3 not 4.4, I think
> there would have been a better chance
> of it being used.
>
> I also agree about garbage collection, but this is a case where the right
> solution would have been to try to get people to use the new interface.​
> The problem was ptrace was 'good enough' and there was no incentive so no
> one did it.
>

In the case of procfs and FreeBSD, the issues were more complicated and
nuanced. The original /proc code came from 4.4BSD, and interacted with a
number of kernel subsystems. These subsystems were undergoing evolution at
the time (including a rather concerted rewrite of the VM to unify the
buffer cache). This churn there lead to inevitable changes being needed to
procfs to keep up with the new interfaces and such. Over time, there grew
the feeling that there some something quite wrong with procfs (rightly or
wrongly). There was a belief there were a number of unanticipated security
issues that were lingering in the code, but due to the changes not only in
API to the other sub-systems, but also in semantics. Kernel hackers that
studied the problem came away with an uneasy feeling, but nothing
actionable. This was the back-drop that slowed its adoption into new
utilities in the FreeBSD tree and kept people from wanting to push it
further until these misgivings could be explored and addressed. In the end,
it was easier to have a better understood code base (ptrace) that had an
icky interface over one that was cleaner, but that had clouds over it. As
fewer and fewer things used /proc, it became easier and easier to ignore,
and at some point people started worrying that this code that was basically
unused could be an attack vector on the systems, so it was retired.

It's been a number of years since all this went down, so my memory of it
may be clouded. Plus, I was FreeBSD's security officer for a time, and I'm
purposely not going back to my notes from the time since I promised to keep
all that business confidential (and I'm not exactly sure where they are).
So, there may be the odd detail wrong, or imprecision of language, but the
main thrust is there: new with issues that are hard to quantify, but have
potential for embarrassment should the misgivings bear fruit militates for
staying with the old. It also didn't help there were no strong supporters
willing to stand behind the code, which didn't help with the misgivings.
Had it not exited the tree then, the push to MP would have counted it as a
casualty absent a strong maintainer to make it MP safe.


> Mark Litton's thesis was DBX which was being written when 4.2 was being
> developed.   If Mark had had /proc the simplicity would have been
> compelling.   But once the code was written, it was hard to justify
> switching.
>
> It's my same observation about why Fortran still is #1 in the high end of
> the business.   It's just not interesting to replace it.
>
> So what I'm asking us to try to do, is not just look at the technology in
> a vacuum.   Why was it not interesting to /proc for BSD.   Clearly, Linux
> added it (differently than Eighth Edition of course and the 4.4
> implementation was much more like V8 that Linux would settle).   People did
> do the work to use it.
>
> So why did *BSD not bring those versions of the utilities back?
>
> My >>guess<< while they had added some things (like /proc) it was
> different again and we got into the BSD != Linux stuff - which has been the
> UNIX war all over again.
>

There might have been a bit of that too, but it was background noise. The
misgivings about the code, and the lack of a strong maintainer to cope with
the misgivings drive the decision. No one was there to bar the door when
the grim reaper came.

Sigh....
>
>
>
>
>>
>> I dislike how Linux has tossed information about processes and
>> other system-related data into the same namespace (and now that
>> there is /sys as well as /proc, I wonder whether it's time to
>> divorce them, or even to move /proc into /sys/proc), but the
>> general direction of moving things into the file system makes
>> sense.
>
> I agree, but let's just create a /sys/proc namespace and try to be
> consistent.  Here is a case where I wish *BSD would just pick up the Linux
> solution and be done with it.  It's not worth arguing.,​
>
>

The Linux solution has two barriers to entry though: GPL means the code
can't be shared and even if it could the radically different structures of
the kernel means little could be shared. So it would be, at best a
compatible implementation. There's bits of /proc for linux in the FreeBSD
Linux execution environment, but not the full thing.


> I have some qualms about adding more and more code to
>> the kernel that just does string processing (making the kernel
>> bigger and more complicated, and widening the attack surface
>> for bad guys),
>
> ​+1​
>
>
>
>> though; maybe most of that stuff belongs not in
>> the OS proper but in a user-mode program that reads /dev/mem
>> and presents as a file system.
>
> ​Agree although, I would love to see consistency and moving towards one
> namespace & associated API that we all used.​
>
>

I'm not so sure about that. I hate /dev/kmem solutions to problems, or any
solution that has to have many round-trips between the kernel and userland,
especially on MP systems where locking and consistency issues clash with
the desire for maximum performance...

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170925/3593a125/attachment.html>