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

On Mon, Sep 25, 2017 at 8:07 AM, Norman Wilson <norman@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.