Re: removing toxic emailers

[Patrick McGehearty via Gcc]

To provide a face-to-face example of how banning can work without
a formal written policy, I been in the leadership of a social gaming
organization with chapters in various places. Our local group typically
has 30-40 people show up at events and over the 30+ years of our
existence, we've had multiple hundreds of different people participate.
Those numbers somewhat match the number of active participants on
this mailing list (to an order of magnitude at least).

Like participants of this mailing list, we discourage disagreeable
behavior because we lose participants if a few people make it
unpleasant for the rest of us. When someone goes over the line,
we (one or more people in the leadership) takes them aside (privately
if possible) and politely point out their behavior is not
doing them or the group any favors. If they seem to understand
and agree to do better, that can be the end of it. Some people
may need guidance more than once, but good intentions count.

There have been a very small number of attendees to our group who's
behavior is unacceptable and will not be tolerated. I can think of only
three specific cases in the last 15 years. In each case, there was a
broad consensus that the group would be better off without them.
There have been many more cases where someone started going over the
line but pulled back when corrected. With positive intervention, their
behavior was modified and they continued in the group.

I believe the same approach could work here. When someone goes over
the line, a respected leader with a talent for calming things down
could suggest to them privately that perhaps they might tone it down
to a more appropriate level of discourse. There is a skill to calming
done tempers and not everyone has the right talents for that, but the
right intervention can help.

While I have been irritated at some of the emails, I have not seen
behavior that is severe enough to build a broad consensus for banning.
To be very clear, I am not complaining about what position anyone
has taken, only about when they present their point of view
in a hostile or offensive way or presume the opposing point
of view represents the face of evil. Hostility does not tend to
change anyone's mind.

I don't believe a formal policy is necessary. It should be
clear when someone is way over the line and cannot accept
counseling and guidance. At that point, the steering committee
can give warning and finally take the necessary action.

- Patrick McGehearty


On 4/14/2021 4:24 PM, Jeff Law via Gcc wrote:


On 4/14/2021 2:39 PM, Ian Lance Taylor wrote:
On Wed, Apr 14, 2021 at 9:08 AM Jeff Law via Gcc  
wrote:

once or twice when physical violence with threatened, but that's about
it (aside from spammers).  I don't think we want to get too deep into
moderation and the like -- IMHO it should be an extremely rare event.
As much as I disagree with some of the comments that have been made I
don't think they've risen to the level of wanting/needing to ban those
individuals from posting.

I think it's useful to observe that there are a reasonable number of
people who will refuse to participate in a project in which the
mailing list has regular personal attacks and other kinds of abusive
behavior.  I know this because I've spoken with such people myself.
They simply say "that project is not for me" and move on.

So we don't get the choice between "everyone is welcome" and "some
people are kicked off the list."  We get the choice between "some
people decline to participate because it is unpleasant" and "some
people are kicked off the list."

Given the choice of which group of people are going to participate and
which group are not, which group do we want?

(I'm raising this as a kind of first principle.  If there is a system
for banning people from the list, there are various things to discuss
as to how that might work.  And I've seen it work effectively in other
communities.  But if we don't agree on that first principle, there is
no point to continuing.)


It's been a long time, but I think when we've banned someone it's been 
through the steering committee.


But yes, I understand your point and it's a good one and I think we 
can probably find some common ground there -- but even so I think 
banning should be a rare event and some official outreach to the 
offender should happen first.



jeff

Re: FYI/RFC: strub: machine-independent stack scrubbing

[Patrick McGehearty via Gcc]

I don't have any special expertise in this matter, but the
possibility occurs to me that if the caller is an improperly vetted
runtime linked-in agent such as a device driver, then the stack
scrubbing might accidently or intentionally be omitted, reopening
the security hole that stack scrubbing is intended to close.

Having the scrubbing occur in the calle means the callee controls
what information is returned, making it responsible for its own
security.

Someone with a deeper understanding of the security reasons for
stack scrubbing may know whether my concern has any basis.

- Patrick McGehearty


On 7/14/2021 12:28 AM, Alexandre Oliva wrote:

I've been working on an implementation of stack scrubbing, strub for
short.  It's quite different from the one that Embecosm folks presented
at the Cauldron, in that this one aims to be machine-independent.
Instead of machine-specific tweaking of epilogue logic to zero out a
function's own stack frame, this design performs scrubbing at callers,
passing to strubbed functions a watermark pointer, that they update as
they move the stack pointer.  The caller performs the stack cleaning up
as a "finally" block after the call.

- functions explicitly marked for strubbing, or internal-to-a-unit
functions that use variables marked as requiring strubbing, just have
their signature modified to add the watermark pointer, and they update
the watermark at the end of the prologue and after alloca calls.

- for functions that require strubbing (say, for using variables that
require strubbing) but whose interface cannot be modified, the body is
split into a clone, and the function is turned into a wrapper that calls
the clone with its modified calling conventions, and then performs the
strubbing.  Variable argument lists and of builtin apply args are passed
as extra arguments to the wrapped function, so that these features are
not obstacles to strubbing.  Large (> 4 words) arguments that are not
gimple registers are passed by reference from the wrapper to the wrapped
clone, to avoid duplicate copying.

This is currently prototyped with an implementation that enables
strubbing for nearly every function.  Some exceptions are always_inline
functions, and externally-visible functions with attributes that prevent
cloning/splitting.

Inlining strubbed functions into non-strubbed ones is not allowed (this
would reverse the wrapping); I'm yet to figure out how to enable
inlining of a wrapped body when the wrapper gets inlined into a strubbed
function.  Furthermore, I'm yet to implement logic to prevent strubbed
functions from calling non-strubbed functions.

The prototype bootstraps on x86_64-linux-gnu, and builds some working
cross toolchains.  I expect to contribute it not long after it's
completed.  For now, I look forward to feedback on any potentially
objectionable implementation details that I've described, and I welcome
advice on some issues described below.


I've added a builtin that returns the stack address, and 3 new entry
points in libgcc, each one also associated with a builtin: one to be
called before a strubbed function, to initialize the watermark to be
passed to it, one to update the watermark, and one to clean the stack up
to the watermark.  I'm considering making them independently inlineable,
inlining none of them at -O0, the first one at -O[1gs], the second one
at -O2, and all of them at -O3.

Functions and variables with strubbing functionality are to be marked
with an attribute, and I'm leaning towards naming it "strub".  For
functions, I intend the attribute to take a parameter, to select between
the two strubbing modes, or to disable strubbing, whether enabling or
preventing calls from strubbing functions.  Internally, I'm using a
numeric encoding for this attribute parameter, but I'm considering using
such mnemonic terms as "at_calls", "internal", "callable", and
"disabled".  WDYT?

I'm also considering the possibility of adding yet another scrubbing
mode, that would select optional machine-dependent epilogue logic, as
implemented by Embecosm.  That will depend on schedule and on whether
this possibility is found to be useful.  Extending it to catch
exceptions and perform strubbing of the propagating frame seems more
challenging than the caller-based strubbing I've implemented, with
exception support.  I could use feedback on the usefulness of this
strubbing mode (and on any issues with the others :-)


The prototype uses modified copies of create_wrapper and expand_thunk
for the wrapping.  I find the body copying and dropping wasteful,
constraining, and, in some cases, bug-inducing (taking address of labels
comes to mind).  I wonder if it would be acceptable to introduce
wrapping logic to short-circuit the process, moving the body instead of
copying it, and introducing hooks to grant callers better control over
argument passing.  The approaches to va_list and apply_args, and to
passing some arguments by reference could presumably be useful to other
future wrap