* [dpdk-dev] [PATCH] vfio: free mp_reply msgs in failure cases
@ 2019-08-16 12:13 Jim Harris
2019-08-20 13:13 ` Burakov, Anatoly
2019-10-14 11:17 ` David Marchand
0 siblings, 2 replies; 9+ messages in thread
From: Jim Harris @ 2019-08-16 12:13 UTC (permalink / raw)
To: dev, anatoly.burakov
The code checks both rte_mp_request_sync() return
code and that the number of messages in the reply
equals 1. If rte_mp_request_sync() succeeds but
there was more than one message, those messages
would get leaked.
Found via code review by Anatoly Burakov of patches
that used the vhost code as a template for using
rte_mp_request_sync().
Signed-off-by: Jim Harris <james.r.harris@intel.com>
---
lib/librte_eal/linux/eal/eal_vfio.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/lib/librte_eal/linux/eal/eal_vfio.c b/lib/librte_eal/linux/eal/eal_vfio.c
index 501c74f23..d9541b122 100644
--- a/lib/librte_eal/linux/eal/eal_vfio.c
+++ b/lib/librte_eal/linux/eal/eal_vfio.c
@@ -264,7 +264,7 @@ vfio_open_group_fd(int iommu_group_num)
int vfio_group_fd;
char filename[PATH_MAX];
struct rte_mp_msg mp_req, *mp_rep;
- struct rte_mp_reply mp_reply;
+ struct rte_mp_reply mp_reply = {0};
struct timespec ts = {.tv_sec = 5, .tv_nsec = 0};
struct vfio_mp_param *p = (struct vfio_mp_param *)mp_req.param;
@@ -320,9 +320,9 @@ vfio_open_group_fd(int iommu_group_num)
RTE_LOG(ERR, EAL, " bad VFIO group fd\n");
vfio_group_fd = 0;
}
- free(mp_reply.msgs);
}
+ free(mp_reply.msgs);
if (vfio_group_fd < 0)
RTE_LOG(ERR, EAL, " cannot request group fd\n");
return vfio_group_fd;
@@ -554,7 +554,7 @@ static int
vfio_sync_default_container(void)
{
struct rte_mp_msg mp_req, *mp_rep;
- struct rte_mp_reply mp_reply;
+ struct rte_mp_reply mp_reply = {0};
struct timespec ts = {.tv_sec = 5, .tv_nsec = 0};
struct vfio_mp_param *p = (struct vfio_mp_param *)mp_req.param;
int iommu_type_id;
@@ -584,8 +584,8 @@ vfio_sync_default_container(void)
p = (struct vfio_mp_param *)mp_rep->param;
if (p->result == SOCKET_OK)
iommu_type_id = p->iommu_type_id;
- free(mp_reply.msgs);
}
+ free(mp_reply.msgs);
if (iommu_type_id < 0) {
RTE_LOG(ERR, EAL, "Could not get IOMMU type for default container\n");
return -1;
@@ -1021,7 +1021,7 @@ int
vfio_get_default_container_fd(void)
{
struct rte_mp_msg mp_req, *mp_rep;
- struct rte_mp_reply mp_reply;
+ struct rte_mp_reply mp_reply = {0};
struct timespec ts = {.tv_sec = 5, .tv_nsec = 0};
struct vfio_mp_param *p = (struct vfio_mp_param *)mp_req.param;
@@ -1049,9 +1049,9 @@ vfio_get_default_container_fd(void)
free(mp_reply.msgs);
return mp_rep->fds[0];
}
- free(mp_reply.msgs);
}
+ free(mp_reply.msgs);
RTE_LOG(ERR, EAL, " cannot request default container fd\n");
return -1;
}
@@ -1127,7 +1127,7 @@ rte_vfio_get_container_fd(void)
{
int ret, vfio_container_fd;
struct rte_mp_msg mp_req, *mp_rep;
- struct rte_mp_reply mp_reply;
+ struct rte_mp_reply mp_reply = {0};
struct timespec ts = {.tv_sec = 5, .tv_nsec = 0};
struct vfio_mp_param *p = (struct vfio_mp_param *)mp_req.param;
@@ -1181,9 +1181,9 @@ rte_vfio_get_container_fd(void)
free(mp_reply.msgs);
return vfio_container_fd;
}
- free(mp_reply.msgs);
}
+ free(mp_reply.msgs);
RTE_LOG(ERR, EAL, " cannot request container fd\n");
return -1;
}
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [dpdk-dev] [PATCH] vfio: free mp_reply msgs in failure cases
2019-08-16 12:13 [dpdk-dev] [PATCH] vfio: free mp_reply msgs in failure cases Jim Harris
@ 2019-08-20 13:13 ` Burakov, Anatoly
2019-08-20 13:16 ` Harris, James R
2019-10-14 11:17 ` David Marchand
1 sibling, 1 reply; 9+ messages in thread
From: Burakov, Anatoly @ 2019-08-20 13:13 UTC (permalink / raw)
To: Jim Harris, dev
On 16-Aug-19 1:13 PM, Jim Harris wrote:
> The code checks both rte_mp_request_sync() return
> code and that the number of messages in the reply
> equals 1. If rte_mp_request_sync() succeeds but
> there was more than one message, those messages
> would get leaked.
>
> Found via code review by Anatoly Burakov of patches
> that used the vhost code as a template for using
> rte_mp_request_sync().
>
> Signed-off-by: Jim Harris <james.r.harris@intel.com>
> ---
> lib/librte_eal/linux/eal/eal_vfio.c | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/lib/librte_eal/linux/eal/eal_vfio.c b/lib/librte_eal/linux/eal/eal_vfio.c
> index 501c74f23..d9541b122 100644
> --- a/lib/librte_eal/linux/eal/eal_vfio.c
> +++ b/lib/librte_eal/linux/eal/eal_vfio.c
> @@ -264,7 +264,7 @@ vfio_open_group_fd(int iommu_group_num)
> int vfio_group_fd;
> char filename[PATH_MAX];
> struct rte_mp_msg mp_req, *mp_rep;
> - struct rte_mp_reply mp_reply;
> + struct rte_mp_reply mp_reply = {0};
> struct timespec ts = {.tv_sec = 5, .tv_nsec = 0};
> struct vfio_mp_param *p = (struct vfio_mp_param *)mp_req.param;
>
> @@ -320,9 +320,9 @@ vfio_open_group_fd(int iommu_group_num)
> RTE_LOG(ERR, EAL, " bad VFIO group fd\n");
> vfio_group_fd = 0;
> }
> - free(mp_reply.msgs);
> }
>
> + free(mp_reply.msgs);
That's not quite correct. This fixes the problem of missing free() when
nb_received mismatches, but this /adds/ a problem of doing an
unnecessary free() when rte_mp_request_sync() returns -1. Same for other
places, i believe.
--
Thanks,
Anatoly
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [dpdk-dev] [PATCH] vfio: free mp_reply msgs in failure cases
2019-08-20 13:13 ` Burakov, Anatoly
@ 2019-08-20 13:16 ` Harris, James R
2019-08-20 13:22 ` Burakov, Anatoly
0 siblings, 1 reply; 9+ messages in thread
From: Harris, James R @ 2019-08-20 13:16 UTC (permalink / raw)
To: Burakov, Anatoly; +Cc: dev
> On Aug 20, 2019, at 6:13 AM, Burakov, Anatoly <anatoly.burakov@intel.com> wrote:
>
>> On 16-Aug-19 1:13 PM, Jim Harris wrote:
>> The code checks both rte_mp_request_sync() return
>> code and that the number of messages in the reply
>> equals 1. If rte_mp_request_sync() succeeds but
>> there was more than one message, those messages
>> would get leaked.
>> Found via code review by Anatoly Burakov of patches
>> that used the vhost code as a template for using
>> rte_mp_request_sync().
>> Signed-off-by: Jim Harris <james.r.harris@intel.com>
>> ---
>> lib/librte_eal/linux/eal/eal_vfio.c | 16 ++++++++--------
>> 1 file changed, 8 insertions(+), 8 deletions(-)
>> diff --git a/lib/librte_eal/linux/eal/eal_vfio.c b/lib/librte_eal/linux/eal/eal_vfio.c
>> index 501c74f23..d9541b122 100644
>> --- a/lib/librte_eal/linux/eal/eal_vfio.c
>> +++ b/lib/librte_eal/linux/eal/eal_vfio.c
>> @@ -264,7 +264,7 @@ vfio_open_group_fd(int iommu_group_num)
>> int vfio_group_fd;
>> char filename[PATH_MAX];
>> struct rte_mp_msg mp_req, *mp_rep;
>> - struct rte_mp_reply mp_reply;
>> + struct rte_mp_reply mp_reply = {0};
>> struct timespec ts = {.tv_sec = 5, .tv_nsec = 0};
>> struct vfio_mp_param *p = (struct vfio_mp_param *)mp_req.param;
>> @@ -320,9 +320,9 @@ vfio_open_group_fd(int iommu_group_num)
>> RTE_LOG(ERR, EAL, " bad VFIO group fd\n");
>> vfio_group_fd = 0;
>> }
>> - free(mp_reply.msgs);
>> }
>> + free(mp_reply.msgs);
>
> That's not quite correct. This fixes the problem of missing free() when nb_received mismatches, but this /adds/ a problem of doing an unnecessary free() when rte_mp_request_sync() returns -1. Same for other places, i believe.
This would just resolve to free(NULL) in the -1 case.
Jim
>
> --
> Thanks,
> Anatoly
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [dpdk-dev] [PATCH] vfio: free mp_reply msgs in failure cases
2019-08-20 13:16 ` Harris, James R
@ 2019-08-20 13:22 ` Burakov, Anatoly
0 siblings, 0 replies; 9+ messages in thread
From: Burakov, Anatoly @ 2019-08-20 13:22 UTC (permalink / raw)
To: Harris, James R; +Cc: dev
On 20-Aug-19 2:16 PM, Harris, James R wrote:
>
>
>> On Aug 20, 2019, at 6:13 AM, Burakov, Anatoly <anatoly.burakov@intel.com> wrote:
>>
>>> On 16-Aug-19 1:13 PM, Jim Harris wrote:
>>> The code checks both rte_mp_request_sync() return
>>> code and that the number of messages in the reply
>>> equals 1. If rte_mp_request_sync() succeeds but
>>> there was more than one message, those messages
>>> would get leaked.
>>> Found via code review by Anatoly Burakov of patches
>>> that used the vhost code as a template for using
>>> rte_mp_request_sync().
>>> Signed-off-by: Jim Harris <james.r.harris@intel.com>
>>> ---
>>> lib/librte_eal/linux/eal/eal_vfio.c | 16 ++++++++--------
>>> 1 file changed, 8 insertions(+), 8 deletions(-)
>>> diff --git a/lib/librte_eal/linux/eal/eal_vfio.c b/lib/librte_eal/linux/eal/eal_vfio.c
>>> index 501c74f23..d9541b122 100644
>>> --- a/lib/librte_eal/linux/eal/eal_vfio.c
>>> +++ b/lib/librte_eal/linux/eal/eal_vfio.c
>>> @@ -264,7 +264,7 @@ vfio_open_group_fd(int iommu_group_num)
>>> int vfio_group_fd;
>>> char filename[PATH_MAX];
>>> struct rte_mp_msg mp_req, *mp_rep;
>>> - struct rte_mp_reply mp_reply;
>>> + struct rte_mp_reply mp_reply = {0};
>>> struct timespec ts = {.tv_sec = 5, .tv_nsec = 0};
>>> struct vfio_mp_param *p = (struct vfio_mp_param *)mp_req.param;
>>> @@ -320,9 +320,9 @@ vfio_open_group_fd(int iommu_group_num)
>>> RTE_LOG(ERR, EAL, " bad VFIO group fd\n");
>>> vfio_group_fd = 0;
>>> }
>>> - free(mp_reply.msgs);
>>> }
>>> + free(mp_reply.msgs);
>>
>> That's not quite correct. This fixes the problem of missing free() when nb_received mismatches, but this /adds/ a problem of doing an unnecessary free() when rte_mp_request_sync() returns -1. Same for other places, i believe.
>
> This would just resolve to free(NULL) in the -1 case.
>
Ah, you're right! We did fix that bug :)
With that in mind,
Acked-by: Anatoly Burakov <anatoly.burakov@intel.com>
--
Thanks,
Anatoly
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [dpdk-dev] [PATCH] vfio: free mp_reply msgs in failure cases
2019-08-16 12:13 [dpdk-dev] [PATCH] vfio: free mp_reply msgs in failure cases Jim Harris
2019-08-20 13:13 ` Burakov, Anatoly
@ 2019-10-14 11:17 ` David Marchand
2019-10-14 13:49 ` Harris, James R
1 sibling, 1 reply; 9+ messages in thread
From: David Marchand @ 2019-10-14 11:17 UTC (permalink / raw)
To: Jim Harris; +Cc: dev, Burakov, Anatoly
On Fri, Aug 16, 2019 at 9:19 PM Jim Harris <james.r.harris@intel.com> wrote:
>
> The code checks both rte_mp_request_sync() return
> code and that the number of messages in the reply
> equals 1. If rte_mp_request_sync() succeeds but
> there was more than one message, those messages
> would get leaked.
>
> Found via code review by Anatoly Burakov of patches
> that used the vhost code as a template for using
> rte_mp_request_sync().
The patch looks fine, I just want to make sure its title reflect what it fixes.
Can you give some insights of how common this issue is? If there are
known cases where it happens?
I might have spotted another issue (could be worth a followup patch
later if confirmed), please see below.
>
> Signed-off-by: Jim Harris <james.r.harris@intel.com>
> ---
> lib/librte_eal/linux/eal/eal_vfio.c | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/lib/librte_eal/linux/eal/eal_vfio.c b/lib/librte_eal/linux/eal/eal_vfio.c
> index 501c74f23..d9541b122 100644
> --- a/lib/librte_eal/linux/eal/eal_vfio.c
> +++ b/lib/librte_eal/linux/eal/eal_vfio.c
[snip]
> @@ -1021,7 +1021,7 @@ int
> vfio_get_default_container_fd(void)
> {
> struct rte_mp_msg mp_req, *mp_rep;
> - struct rte_mp_reply mp_reply;
> + struct rte_mp_reply mp_reply = {0};
> struct timespec ts = {.tv_sec = 5, .tv_nsec = 0};
> struct vfio_mp_param *p = (struct vfio_mp_param *)mp_req.param;
>
> @@ -1049,9 +1049,9 @@ vfio_get_default_container_fd(void)
> free(mp_reply.msgs);
> return mp_rep->fds[0];
Do we have a use after free on mp_rep which points to &mp_reply.msgs[0] ?
> }
> - free(mp_reply.msgs);
> }
>
> + free(mp_reply.msgs);
> RTE_LOG(ERR, EAL, " cannot request default container fd\n");
> return -1;
> }
--
David Marchand
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [dpdk-dev] [PATCH] vfio: free mp_reply msgs in failure cases
2019-10-14 11:17 ` David Marchand
@ 2019-10-14 13:49 ` Harris, James R
2019-10-14 14:47 ` David Marchand
0 siblings, 1 reply; 9+ messages in thread
From: Harris, James R @ 2019-10-14 13:49 UTC (permalink / raw)
To: David Marchand; +Cc: dev, Burakov, Anatoly
On 10/14/19, 4:18 AM, "David Marchand" <david.marchand@redhat.com> wrote:
On Fri, Aug 16, 2019 at 9:19 PM Jim Harris <james.r.harris@intel.com> wrote:
>
> The code checks both rte_mp_request_sync() return
> code and that the number of messages in the reply
> equals 1. If rte_mp_request_sync() succeeds but
> there was more than one message, those messages
> would get leaked.
>
> Found via code review by Anatoly Burakov of patches
> that used the vhost code as a template for using
> rte_mp_request_sync().
The patch looks fine, I just want to make sure its title reflect what it fixes.
Can you give some insights of how common this issue is? If there are
known cases where it happens?
Hi David,
I don't think this issue is common at all. I don't have any known cases in mind - it was only found via code inspection.
I might have spotted another issue (could be worth a followup patch
later if confirmed), please see below.
>
> Signed-off-by: Jim Harris <james.r.harris@intel.com>
> ---
> lib/librte_eal/linux/eal/eal_vfio.c | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/lib/librte_eal/linux/eal/eal_vfio.c b/lib/librte_eal/linux/eal/eal_vfio.c
> index 501c74f23..d9541b122 100644
> --- a/lib/librte_eal/linux/eal/eal_vfio.c
> +++ b/lib/librte_eal/linux/eal/eal_vfio.c
[snip]
> @@ -1021,7 +1021,7 @@ int
> vfio_get_default_container_fd(void)
> {
> struct rte_mp_msg mp_req, *mp_rep;
> - struct rte_mp_reply mp_reply;
> + struct rte_mp_reply mp_reply = {0};
> struct timespec ts = {.tv_sec = 5, .tv_nsec = 0};
> struct vfio_mp_param *p = (struct vfio_mp_param *)mp_req.param;
>
> @@ -1049,9 +1049,9 @@ vfio_get_default_container_fd(void)
> free(mp_reply.msgs);
> return mp_rep->fds[0];
Do we have a use after free on mp_rep which points to &mp_reply.msgs[0] ?
You're right. It needs to save mp_rep->fds[0] into a local variable before we free that array. That would be a good follow-up patch!
-Jim
> }
> - free(mp_reply.msgs);
> }
>
> + free(mp_reply.msgs);
> RTE_LOG(ERR, EAL, " cannot request default container fd\n");
> return -1;
> }
--
David Marchand
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [dpdk-dev] [PATCH] vfio: free mp_reply msgs in failure cases
2019-10-14 13:49 ` Harris, James R
@ 2019-10-14 14:47 ` David Marchand
2019-10-14 14:50 ` Harris, James R
2019-10-15 18:38 ` David Marchand
0 siblings, 2 replies; 9+ messages in thread
From: David Marchand @ 2019-10-14 14:47 UTC (permalink / raw)
To: Harris, James R, Burakov, Anatoly; +Cc: dev
On Mon, Oct 14, 2019 at 3:49 PM Harris, James R
<james.r.harris@intel.com> wrote:
> On 10/14/19, 4:18 AM, "David Marchand" <david.marchand@redhat.com> wrote:
>
> On Fri, Aug 16, 2019 at 9:19 PM Jim Harris <james.r.harris@intel.com> wrote:
> >
> > The code checks both rte_mp_request_sync() return
> > code and that the number of messages in the reply
> > equals 1. If rte_mp_request_sync() succeeds but
> > there was more than one message, those messages
> > would get leaked.
> >
> > Found via code review by Anatoly Burakov of patches
> > that used the vhost code as a template for using
> > rte_mp_request_sync().
>
> The patch looks fine, I just want to make sure its title reflect what it fixes.
> Can you give some insights of how common this issue is? If there are
> known cases where it happens?
>
> Hi David,
>
> I don't think this issue is common at all. I don't have any known cases in mind - it was only found via code inspection.
Anatoly, Jim,
Not really inspired for the title, what do you think of:
vfio: fix potential leak with multiprocess
Plus, it deserves a Fixes: line.
Fixes: 83a73c5fef66 ("vfio: use generic multi-process channel")
Cc: stable@dpdk.org
If you are okay with this, I will do the change when applying.
--
David Marchand
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [dpdk-dev] [PATCH] vfio: free mp_reply msgs in failure cases
2019-10-14 14:47 ` David Marchand
@ 2019-10-14 14:50 ` Harris, James R
2019-10-15 18:38 ` David Marchand
1 sibling, 0 replies; 9+ messages in thread
From: Harris, James R @ 2019-10-14 14:50 UTC (permalink / raw)
To: David Marchand; +Cc: Burakov, Anatoly, dev
> On Oct 14, 2019, at 7:47 AM, David Marchand <david.marchand@redhat.com> wrote:
>
> On Mon, Oct 14, 2019 at 3:49 PM Harris, James R
> <james.r.harris@intel.com> wrote:
>> On 10/14/19, 4:18 AM, "David Marchand" <david.marchand@redhat.com> wrote:
>>
>>> On Fri, Aug 16, 2019 at 9:19 PM Jim Harris <james.r.harris@intel.com> wrote:
>>>
>>> The code checks both rte_mp_request_sync() return
>>> code and that the number of messages in the reply
>>> equals 1. If rte_mp_request_sync() succeeds but
>>> there was more than one message, those messages
>>> would get leaked.
>>>
>>> Found via code review by Anatoly Burakov of patches
>>> that used the vhost code as a template for using
>>> rte_mp_request_sync().
>>
>> The patch looks fine, I just want to make sure its title reflect what it fixes.
>> Can you give some insights of how common this issue is? If there are
>> known cases where it happens?
>>
>> Hi David,
>>
>> I don't think this issue is common at all. I don't have any known cases in mind - it was only found via code inspection.
>
> Anatoly, Jim,
>
> Not really inspired for the title, what do you think of:
> vfio: fix potential leak with multiprocess
>
> Plus, it deserves a Fixes: line.
> Fixes: 83a73c5fef66 ("vfio: use generic multi-process channel")
> Cc: stable@dpdk.org
>
> If you are okay with this, I will do the change when applying.
I am ok with those changes. Thanks!
>
> --
> David Marchand
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [dpdk-dev] [PATCH] vfio: free mp_reply msgs in failure cases
2019-10-14 14:47 ` David Marchand
2019-10-14 14:50 ` Harris, James R
@ 2019-10-15 18:38 ` David Marchand
1 sibling, 0 replies; 9+ messages in thread
From: David Marchand @ 2019-10-15 18:38 UTC (permalink / raw)
To: Harris, James R, Burakov, Anatoly; +Cc: dev
On Mon, Oct 14, 2019 at 4:47 PM David Marchand
<david.marchand@redhat.com> wrote:
>
> On Mon, Oct 14, 2019 at 3:49 PM Harris, James R
> <james.r.harris@intel.com> wrote:
> > On 10/14/19, 4:18 AM, "David Marchand" <david.marchand@redhat.com> wrote:
> >
> > On Fri, Aug 16, 2019 at 9:19 PM Jim Harris <james.r.harris@intel.com> wrote:
> > >
> > > The code checks both rte_mp_request_sync() return
> > > code and that the number of messages in the reply
> > > equals 1. If rte_mp_request_sync() succeeds but
> > > there was more than one message, those messages
> > > would get leaked.
> > >
> > > Found via code review by Anatoly Burakov of patches
> > > that used the vhost code as a template for using
> > > rte_mp_request_sync().
> >
> > The patch looks fine, I just want to make sure its title reflect what it fixes.
> > Can you give some insights of how common this issue is? If there are
> > known cases where it happens?
> >
> > Hi David,
> >
> > I don't think this issue is common at all. I don't have any known cases in mind - it was only found via code inspection.
>
> Anatoly, Jim,
>
> Not really inspired for the title, what do you think of:
> vfio: fix potential leak with multiprocess
>
> Plus, it deserves a Fixes: line.
> Fixes: 83a73c5fef66 ("vfio: use generic multi-process channel")
> Cc: stable@dpdk.org
>
> If you are okay with this, I will do the change when applying.
Applied, thanks.
--
David Marchand
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2019-10-15 18:39 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-08-16 12:13 [dpdk-dev] [PATCH] vfio: free mp_reply msgs in failure cases Jim Harris
2019-08-20 13:13 ` Burakov, Anatoly
2019-08-20 13:16 ` Harris, James R
2019-08-20 13:22 ` Burakov, Anatoly
2019-10-14 11:17 ` David Marchand
2019-10-14 13:49 ` Harris, James R
2019-10-14 14:47 ` David Marchand
2019-10-14 14:50 ` Harris, James R
2019-10-15 18:38 ` David Marchand
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).