[Swan-dev] management of whack socket file descriptors
D. Hugh Redelmeier
hugh at mimosa.com
Fri Jun 22 14:26:55 UTC 2018
The Coverity report (at the bottom of this message) is interesting.
It was triggered by e30778728ea01dacb051276d835648e0fda0618c which
actually fixed a leak and did not introduce any new one (as far as I
know).
The flow of whack file descriptors is quite subtle and it seems that
maintainers have added leaks (and perhaps the opposite -- use after
close) over the years.
The whack socket file descriptor enables logging from pluto to go back to
the whack command. Only logging relevant to that particular command goes
back. The whack command doesn't complete until the last whack socket file
descriptor is closed in pluto.
- pluto has a whack socket for the duration of the processing of the
whack command. Mostly that processing is a single event handler.
And then the whack socket file descriptor is closed.
- If the whack processing initiates negotiation, that negotiation will
be represented by a new state object. That state object will get a
duplicate of the whack socket file descriptor. That allows logging from
the negotiation to go back to the whack command that initiated it.
- a state owns one. That one must be closed when the state is deleted
(and on certain other events)
- functions that create a state must ensure that the state gets its own
whack file descriptor. Someone has to dup a descriptor so that the
state can own one.
Refine this with the concept of a null file descriptor. For example,
some states cannot be traced back to a whack command and thus an
actual whack socket file descriptor doesn't exist. Also, after a
certain number of retries, we "release" the whack (by closing the
whack socket file descriptor).
There, you have the basic outline.
Although fairly simple in concept, the path of whack socket file
descriptors through the code has gotten too complicated to easily remember
obligations. Evidence: I've killed two leaks today. It took Coverity to
find them. I think that we need at least a notation to document these
obligations.
There are similar obligations for other resources and they too should
be documented in the code.
Unfortunately, C does not have a way of declaring those obligations.
Rust does. Perhaps we should copy their notation, as stylized
comments. Too bad they won't be enforced. Historically, that kind of
comment seem to suffer bit rot over time.
I guess we could add a wrapper around whack socket file descriptor
handling. We could make leaks and use-after-close detectable at
runtime.
File descriptor leaks should result in whack commands that don't
terminate. Since I'm unaware of complaints of this nature, it seems
likely that the leaks are on rarely executed paths. Or maybe I just don't
hear the complaints.
Use-after-free would be observable in two different ways:
- the whack command being released too soon
- logging from one whack command being translated to another command. Or
worse: appearing on a completely unrelated file or socket.
| From: scan-admin at coverity.com
| Resent-From: Antony Antony <antony at fern.phenome.org>
| To: antony at phenome.org
| Resent-To: swan-dev at lists.libreswan.org
| Date: Fri, 22 Jun 2018 08:31:58 +0000 (UTC)
| Resent-Date: Fri, 22 Jun 2018 10:35:18 +0200
| Subject: [Swan-dev] New Defects reported by Coverity Scan for
| antonyantony/libreswan
|
| Hi,
|
| Please find the latest report on new defect(s) introduced to antonyantony/libreswan found with Coverity Scan.
|
| 1 new defect(s) introduced to antonyantony/libreswan found with Coverity Scan.
| 60 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan.
|
| New defect(s) Reported-by: Coverity Scan
| Showing 1 of 1 defect(s)
|
|
| ** CID 1470137: Resource leaks (RESOURCE_LEAK)
| /programs/pluto/ipsec_doi.c: 313 in ipsecdoi_replace()
|
|
| ________________________________________________________________________________________________________
| *** CID 1470137: Resource leaks (RESOURCE_LEAK)
| /programs/pluto/ipsec_doi.c: 313 in ipsecdoi_replace()
| 307 policy = (c->policy & ~POLICY_IPSEC_MASK &
| 308 ~policy_del) | policy_add;
| 309
| 310 initiator = pick_initiator(c, policy);
| 311 passert(!HAS_IPSEC_POLICY(policy));
| 312 if (initiator != NULL) {
| >>> CID 1470137: Resource leaks (RESOURCE_LEAK)
| >>> Failing to save or close handle opened by "dup(st->st_whack_sock)" leaks it.
| 313 (void) initiator(dup_any(st->st_whack_sock),
| 314 st->st_connection, st, policy, try, st->st_import
| 315 #ifdef HAVE_LABELED_IPSEC
| 316 , st->sec_ctx
| 317 #endif
| 318 );
|
|
| ________________________________________________________________________________________________________
| To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V05UPxvVjWch-2Bd2MGckcRa-2F6FIQzoHE-2FeGfLjPxAHnMmI2-2BcDlBXS8eK3EDO-2F5Fjl6z3ueBPZWbG1BXBakNu80-3D_4HMcbsf14xheNUejmIGHntUcwhwkdYITNaUIUw0xLaqz0N8SaUULk05XZRHaJR5f4bhmTSF4djLcxwhhxI1cocKBXliSVDUUGAmdHiZpSUANxL3-2BGJViajaAekqgabDudscTDCIYE8y7iM98QSdn3KoVUXdlfokQ5p0msl9-2BygcK-2B5VZPQ-2FjomrScfQmv-2BSuj2Kqv1UthUNpPDvPcxUlrA-3D-3D
|
| To manage Coverity Scan email notifications for "antony at phenome.org", click https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V05UPxvVjWch-2Bd2MGckcRbVDbis712qZDP-2FA8y06Nq4T11LJsTCGAu8UQysrZAC89q-2FP-2B3fe1J15ziye5UyoPhoOtByWqcc6ADp6Tx8rz1FuEBlJrervxOcvY4aXgJd53T3KDIOTHFcOCaGp5NkyaQ-3D_4HMcbsf14xheNUejmIGHntUcwhwkdYITNaUIUw0xLaqz0N8SaUULk05XZRHaJR5feO8VlTIYOkX8d29cjB3KQX9etyqOYxzJJEyAFBy0860rZHmjaqkcFmPmSti474O4Gftkll9kwHQ7Z-2FYOCkTJTTg4MWXZlK5hJfTjRjlxHK3IS7KcwEG2xwebthSeqKQHr-2Bcd2-2FwZX9Cw52g0QHi-2BtQ-3D-3D
More information about the Swan-dev
mailing list