Re: [PATCH v3 1/6] argo: lower level of noisy connection-refused log

["Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>]

On 6/11/26 11:26 AM, Jan Beulich wrote:
> On 09.06.2026 13:57, Daniel Smith wrote:
> > From: Jason Andryuk <jason.andryuk@xxxxxxx>
> > Date: Mon, 08 Jun 2026 19:16:01 -0400
> >   > On 2026-06-08 15:54, Daniel P. Smith wrote:
> >   > > On 5/26/26 5:58 PM, dmukhin@xxxxxxxx wrote:
> >   > >> --- a/xen/common/argo.c
> >   > >> +++ b/xen/common/argo.c
> >   > >> @@ -2034,10 +2034,9 @@ sendv(struct domain *src_d, xen_argo_addr_t
> >   > >> *src_addr,
> >   > >>                                           src_id.domain_id);
> >   > >>       if ( !ring_info )
> >   > >>       {
> >   > >> -        gprintk(XENLOG_ERR,
> >   > >> -                "argo: vm%u connection refused, src (vm%u:%x) dst
> >   > >> (vm%u:%x)\n",
> >   > >> -                current->domain->domain_id, src_id.domain_id,
> >   > >> src_id.aport,
> >   > >> -                dst_addr->domain_id, dst_addr->aport);
> >   > >> +        argo_dprintk("vm%u connection refused, src (vm%u:%x) dst
> >   > >> (vm%u:%x)\n",
> >   > >> +                     current->domain->domain_id, src_id.domain_id,
> >   > >> src_id.aport,
> >   > >> +                     dst_addr->domain_id, dst_addr->aport);
> >   > >>           ret = -ECONNREFUSED;
> >   > >>       }
> >   > >
> >   > > My apologies but this is not the wisest approach, hitting this is a real
> >   > > error and shouldn't be getting silenced.
> >   >
> >   > -ECONNREFUSED is still returned, and that is the important part, I think?
> >   >
> >
> > Absolutely not. Argo at its essence is a security protocol where you want to 
> > minimize the amount of implicit trust we have to have with the endpoint. 
> > Telling a bad actor he did a bad action tells you nothing. The send operation 
> > is the critical security path and you must have an auditable record that an 
> > endpoint misbehaved. If yo want to implicitly trust your end point after 
> > passing the accees check, then you can just use grants.
> Yet then - is potentially spamming the log an appropriate model? Furthermore
> gprintk()-s are, by default, rate-limited in release builds, and hence there
> isn't going to reliably be an "auditable record" anyway. If you want logging
> for auditing purposes, I think you'll need to add separate logging (not to
> the system console).
I must strongly object to the characterization of this logging as 
"spamming the log." The mechanism is functioning exactly as designed.
Argo uses rate-limited logging to report attempts to write to a ring 
that does not exist. Argo also exposes explicit interfaces for a domain 
to determine whether a ring is available and whether access has been 
granted. When software attempts an operation without first verifying 
these preconditions through the provided mechanisms, the resulting log 
message is both expected and necessary. It is not the role of the 
logging interface to remain silent in the face of incorrect usage.
Blaming the interface for correctly surfacing misuse, rather than 
addressing the software that fails to use the capability properly, 
inverts the proper assignment of responsibility. Logging exists to make 
such problems visible; suppressing it does not solve the underlying 
issue.This is especially true in this case, where failed attempts to 
send to a ring is of security relevance.
Consider the direct parallel: a domain is started with the expectation 
that a peer domain will establish a grant mapping for predetermined 
grant reference, instead of coordinating through xenstore. If the first 
domain attempts the mapping without performing or waiting for the proper 
xenstore coordination, the system will correctly log the invalid grant 
reference[1]. The appropriate response in that case is to correct the 
lack of coordination in the domain's startup sequence, not to disable 
the log message that reveals the misuse. The same principle applies here.
Proposals to remove or disable this logging in response to observed 
misuse should be rejected on principle. The correct course of action is 
to ensure that calling code uses the established discovery and 
access-control interfaces before attempting operations on rings.
[1] 
https://elixir.bootlin.com/xen/v4.21.1/source/xen/common/grant_table.c#L1071
V/r,
Daniel P. Smith