* [RFC PATCH] x86/mm/fault: Allow stack access below %rsp @ 2018-11-02 19:40 Waiman Long 2018-11-02 19:44 ` Dave Hansen 0 siblings, 1 reply; 12+ messages in thread From: Waiman Long @ 2018-11-02 19:40 UTC (permalink / raw) To: Dave Hansen, Andy Lutomirski, Peter Zijlstra, Thomas Gleixner, Ingo Molnar, Borislav Petkov Cc: H. Peter Anvin, x86, linux-kernel, Waiman Long The current x86 page fault handler allows stack access below the stack pointer if it is no more than 64k+256 bytes. Any access beyond the 64k+ limit will cause a segmentation fault. The gcc -fstack-check option generates code to probe the stack for large stack allocation to see if the stack is accessible. The newer gcc does that while updating the %rsp simultaneously. Older gcc's like gcc4 doesn't do that. As a result, an application compiled with an old gcc and the -fstack-check option may fail to start at all. % cat test.c int main() { char tmp[1024*128]; printf("### ok\n"); return 0; } % gcc -fstack-check -g -o test test.c % ./test Segmentation fault The 64k+ limit check is kind of arbitrary. So the check is now removed to just let expand_stack() decide if a segmentation fault should happen. Signed-off-by: Waiman Long <longman@redhat.com> --- arch/x86/mm/fault.c | 12 ------------ 1 file changed, 12 deletions(-) diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c index 71d4b9d..29525cf 100644 --- a/arch/x86/mm/fault.c +++ b/arch/x86/mm/fault.c @@ -1380,18 +1380,6 @@ void do_user_addr_fault(struct pt_regs *regs, bad_area(regs, sw_error_code, address); return; } - if (sw_error_code & X86_PF_USER) { - /* - * Accessing the stack below %sp is always a bug. - * The large cushion allows instructions like enter - * and pusha to work. ("enter $65535, $31" pushes - * 32 pointers and then decrements %sp by 65535.) - */ - if (unlikely(address + 65536 + 32 * sizeof(unsigned long) < regs->sp)) { - bad_area(regs, sw_error_code, address); - return; - } - } if (unlikely(expand_stack(vma, address))) { bad_area(regs, sw_error_code, address); return; -- 1.8.3.1 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [RFC PATCH] x86/mm/fault: Allow stack access below %rsp 2018-11-02 19:40 [RFC PATCH] x86/mm/fault: Allow stack access below %rsp Waiman Long @ 2018-11-02 19:44 ` Dave Hansen 2018-11-02 19:50 ` Waiman Long 0 siblings, 1 reply; 12+ messages in thread From: Dave Hansen @ 2018-11-02 19:44 UTC (permalink / raw) To: Waiman Long, Dave Hansen, Andy Lutomirski, Peter Zijlstra, Thomas Gleixner, Ingo Molnar, Borislav Petkov Cc: H. Peter Anvin, x86, linux-kernel On 11/2/18 12:40 PM, Waiman Long wrote: > The 64k+ limit check is kind of arbitrary. So the check is now removed > to just let expand_stack() decide if a segmentation fault should happen. With the 64k check removed, what's the next limit that we bump into? Is it just the stack_guard_gap space above the next-lowest VMA? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC PATCH] x86/mm/fault: Allow stack access below %rsp 2018-11-02 19:44 ` Dave Hansen @ 2018-11-02 19:50 ` Waiman Long 2018-11-02 20:11 ` Andy Lutomirski 2018-11-02 22:28 ` Dave Hansen 0 siblings, 2 replies; 12+ messages in thread From: Waiman Long @ 2018-11-02 19:50 UTC (permalink / raw) To: Dave Hansen, Dave Hansen, Andy Lutomirski, Peter Zijlstra, Thomas Gleixner, Ingo Molnar, Borislav Petkov Cc: H. Peter Anvin, x86, linux-kernel On 11/02/2018 03:44 PM, Dave Hansen wrote: > On 11/2/18 12:40 PM, Waiman Long wrote: >> The 64k+ limit check is kind of arbitrary. So the check is now removed >> to just let expand_stack() decide if a segmentation fault should happen. > With the 64k check removed, what's the next limit that we bump into? Is > it just the stack_guard_gap space above the next-lowest VMA? I think it is both the stack_guard_gap space above the next lowest VMA and the rlimit(RLIMIT_STACK). Cheers, Longman ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC PATCH] x86/mm/fault: Allow stack access below %rsp 2018-11-02 19:50 ` Waiman Long @ 2018-11-02 20:11 ` Andy Lutomirski 2018-11-02 20:34 ` Waiman Long 2018-11-02 22:28 ` Dave Hansen 1 sibling, 1 reply; 12+ messages in thread From: Andy Lutomirski @ 2018-11-02 20:11 UTC (permalink / raw) To: Waiman Long Cc: Dave Hansen, Dave Hansen, Andrew Lutomirski, Peter Zijlstra, Thomas Gleixner, Ingo Molnar, Borislav Petkov, H. Peter Anvin, X86 ML, LKML On Fri, Nov 2, 2018 at 12:50 PM Waiman Long <longman@redhat.com> wrote: > > On 11/02/2018 03:44 PM, Dave Hansen wrote: > > On 11/2/18 12:40 PM, Waiman Long wrote: > >> The 64k+ limit check is kind of arbitrary. So the check is now removed > >> to just let expand_stack() decide if a segmentation fault should happen. > > With the 64k check removed, what's the next limit that we bump into? Is > > it just the stack_guard_gap space above the next-lowest VMA? > > I think it is both the stack_guard_gap space above the next lowest VMA > and the rlimit(RLIMIT_STACK). > Did the non-working programs ever work? Because, if not, I say let them fail. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC PATCH] x86/mm/fault: Allow stack access below %rsp 2018-11-02 20:11 ` Andy Lutomirski @ 2018-11-02 20:34 ` Waiman Long 0 siblings, 0 replies; 12+ messages in thread From: Waiman Long @ 2018-11-02 20:34 UTC (permalink / raw) To: Andy Lutomirski Cc: Dave Hansen, Dave Hansen, Peter Zijlstra, Thomas Gleixner, Ingo Molnar, Borislav Petkov, H. Peter Anvin, X86 ML, LKML On 11/02/2018 04:11 PM, Andy Lutomirski wrote: > On Fri, Nov 2, 2018 at 12:50 PM Waiman Long <longman@redhat.com> wrote: >> On 11/02/2018 03:44 PM, Dave Hansen wrote: >>> On 11/2/18 12:40 PM, Waiman Long wrote: >>>> The 64k+ limit check is kind of arbitrary. So the check is now removed >>>> to just let expand_stack() decide if a segmentation fault should happen. >>> With the 64k check removed, what's the next limit that we bump into? Is >>> it just the stack_guard_gap space above the next-lowest VMA? >> I think it is both the stack_guard_gap space above the next lowest VMA >> and the rlimit(RLIMIT_STACK). >> > Did the non-working programs ever work? Because, if not, I say let them fail. The program was working before on older kernel. After the backport of the commit 1be7107fbe18 ("mm: larger stack guard gap, between vmas"), the program stopped working. I believe it is the removal of the check_stack_guard_page() function which did expand the stack. So the 64k check was actually not functional because of the stack expansion before hand, but now it does. Anyway, I see the current 64k check a very crude check on an userspace error. I think there are quite a number of more powerful userspace tools out there that can do this kind of check more effectively. Kernel isn't the right place to do that. Cheers, Longman ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC PATCH] x86/mm/fault: Allow stack access below %rsp 2018-11-02 19:50 ` Waiman Long 2018-11-02 20:11 ` Andy Lutomirski @ 2018-11-02 22:28 ` Dave Hansen 2018-11-05 5:11 ` Andy Lutomirski 2018-11-05 16:27 ` Waiman Long 1 sibling, 2 replies; 12+ messages in thread From: Dave Hansen @ 2018-11-02 22:28 UTC (permalink / raw) To: Waiman Long, Dave Hansen, Andy Lutomirski, Peter Zijlstra, Thomas Gleixner, Ingo Molnar, Borislav Petkov Cc: H. Peter Anvin, x86, linux-kernel On 11/2/18 12:50 PM, Waiman Long wrote: > On 11/02/2018 03:44 PM, Dave Hansen wrote: >> On 11/2/18 12:40 PM, Waiman Long wrote: >>> The 64k+ limit check is kind of arbitrary. So the check is now removed >>> to just let expand_stack() decide if a segmentation fault should happen. >> With the 64k check removed, what's the next limit that we bump into? Is >> it just the stack_guard_gap space above the next-lowest VMA? > I think it is both the stack_guard_gap space above the next lowest VMA > and the rlimit(RLIMIT_STACK). The gap seems to be hundreds of megabytes, typically where RLIMIT_STACK is 8MB by default, so RLIMIT_STACK is likely to be the practical limit that will be hit. So, practically, we've taken a ~64k area that we would on-demand extend the stack into in one go, and turned that into a the full ~8MB area that you could have expanded into anyway, but all at once. That doesn't seem too insane, especially since we don't physically back the 8MB or anything. Logically, it also seems like you *should* be able to touch any bit of the stack within the rlimit. But, on the other hand, as our comments say: "Accessing the stack below %sp is always a bug." Have we been unsuccessful in convincing our gcc buddies of this? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC PATCH] x86/mm/fault: Allow stack access below %rsp 2018-11-02 22:28 ` Dave Hansen @ 2018-11-05 5:11 ` Andy Lutomirski 2018-11-05 5:14 ` Andy Lutomirski 2018-11-05 16:27 ` Waiman Long 1 sibling, 1 reply; 12+ messages in thread From: Andy Lutomirski @ 2018-11-05 5:11 UTC (permalink / raw) To: Dave Hansen Cc: Waiman Long, Dave Hansen, Andrew Lutomirski, Peter Zijlstra, Thomas Gleixner, Ingo Molnar, Borislav Petkov, H. Peter Anvin, X86 ML, LKML On Fri, Nov 2, 2018 at 3:28 PM Dave Hansen <dave.hansen@intel.com> wrote: > > On 11/2/18 12:50 PM, Waiman Long wrote: > > On 11/02/2018 03:44 PM, Dave Hansen wrote: > >> On 11/2/18 12:40 PM, Waiman Long wrote: > >>> The 64k+ limit check is kind of arbitrary. So the check is now removed > >>> to just let expand_stack() decide if a segmentation fault should happen. > >> With the 64k check removed, what's the next limit that we bump into? Is > >> it just the stack_guard_gap space above the next-lowest VMA? > > I think it is both the stack_guard_gap space above the next lowest VMA > > and the rlimit(RLIMIT_STACK). > > The gap seems to be hundreds of megabytes, typically where RLIMIT_STACK > is 8MB by default, so RLIMIT_STACK is likely to be the practical limit > that will be hit. So, practically, we've taken a ~64k area that we > would on-demand extend the stack into in one go, and turned that into a > the full ~8MB area that you could have expanded into anyway, but all at > once. > > That doesn't seem too insane, especially since we don't physically back > the 8MB or anything. Logically, it also seems like you *should* be able > to touch any bit of the stack within the rlimit. > > But, on the other hand, as our comments say: "Accessing the stack below > %sp is always a bug." Have we been unsuccessful in convincing our gcc > buddies of this? FWIW, the old code is a bit bogus. Why are we restricting the range of stack expending addresses for user code without restricting the range of kernel uaccess addresses that would do the same thing? So I think I agree with the patch. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC PATCH] x86/mm/fault: Allow stack access below %rsp 2018-11-05 5:11 ` Andy Lutomirski @ 2018-11-05 5:14 ` Andy Lutomirski 2018-11-05 17:20 ` Dave Hansen 0 siblings, 1 reply; 12+ messages in thread From: Andy Lutomirski @ 2018-11-05 5:14 UTC (permalink / raw) To: Andrew Lutomirski Cc: Dave Hansen, Waiman Long, Dave Hansen, Peter Zijlstra, Thomas Gleixner, Ingo Molnar, Borislav Petkov, H. Peter Anvin, X86 ML, LKML On Sun, Nov 4, 2018 at 9:11 PM Andy Lutomirski <luto@kernel.org> wrote: > > On Fri, Nov 2, 2018 at 3:28 PM Dave Hansen <dave.hansen@intel.com> wrote: > > > > On 11/2/18 12:50 PM, Waiman Long wrote: > > > On 11/02/2018 03:44 PM, Dave Hansen wrote: > > >> On 11/2/18 12:40 PM, Waiman Long wrote: > > >>> The 64k+ limit check is kind of arbitrary. So the check is now removed > > >>> to just let expand_stack() decide if a segmentation fault should happen. > > >> With the 64k check removed, what's the next limit that we bump into? Is > > >> it just the stack_guard_gap space above the next-lowest VMA? > > > I think it is both the stack_guard_gap space above the next lowest VMA > > > and the rlimit(RLIMIT_STACK). > > > > The gap seems to be hundreds of megabytes, typically where RLIMIT_STACK > > is 8MB by default, so RLIMIT_STACK is likely to be the practical limit > > that will be hit. So, practically, we've taken a ~64k area that we > > would on-demand extend the stack into in one go, and turned that into a > > the full ~8MB area that you could have expanded into anyway, but all at > > once. > > > > That doesn't seem too insane, especially since we don't physically back > > the 8MB or anything. Logically, it also seems like you *should* be able > > to touch any bit of the stack within the rlimit. > > > > But, on the other hand, as our comments say: "Accessing the stack below > > %sp is always a bug." Have we been unsuccessful in convincing our gcc > > buddies of this? > > FWIW, the old code is a bit bogus. Why are we restricting the range > of stack expending addresses for user code without restricting the > range of kernel uaccess addresses that would do the same thing? > > So I think I agree with the patch. I should add: if this patch is *not* applied, then I think we'll need to replace the sw_error_code check with user_mode(regs) to avoid an info leak if CET is enabled. Because, with CET, WRUSS will allow a *kernel* mode access (where regs->sp is the kernel stack pointer) with user permissions. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC PATCH] x86/mm/fault: Allow stack access below %rsp 2018-11-05 5:14 ` Andy Lutomirski @ 2018-11-05 17:20 ` Dave Hansen 2018-11-05 19:21 ` Andy Lutomirski 0 siblings, 1 reply; 12+ messages in thread From: Dave Hansen @ 2018-11-05 17:20 UTC (permalink / raw) To: Andy Lutomirski Cc: Waiman Long, Dave Hansen, Peter Zijlstra, Thomas Gleixner, Ingo Molnar, Borislav Petkov, H. Peter Anvin, X86 ML, LKML On 11/4/18 9:14 PM, Andy Lutomirski wrote: > I should add: if this patch is *not* applied, then I think we'll > need to replace the sw_error_code check with user_mode(regs) to avoid > an info leak if CET is enabled. Because, with CET, WRUSS will allow > a *kernel* mode access (where regs->sp is the kernel stack pointer) > with user permissions. Are you saying that WRUSS, if it faults will set the "user" page fault error code bit? I seem to have some rough recollection about it being that way, and the shadow-stack spec does say: paging access control checks will be treated as a user-mode shadow stack store But the SDM says: For all instruction fetches and most data accesses, this distinction is determined by the current privilege level (CPL): accesses made while CPL < 3 are supervisor-mode accesses, while accesses made while CPL = 3 are user-mode accesses. It would certainly be ideal if things affecting the core architecture like this were in the SDM itself before we merged them. It makes things like this a lot easier to figure out. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC PATCH] x86/mm/fault: Allow stack access below %rsp 2018-11-05 17:20 ` Dave Hansen @ 2018-11-05 19:21 ` Andy Lutomirski 0 siblings, 0 replies; 12+ messages in thread From: Andy Lutomirski @ 2018-11-05 19:21 UTC (permalink / raw) To: Dave Hansen Cc: Andrew Lutomirski, Waiman Long, Dave Hansen, Peter Zijlstra, Thomas Gleixner, Ingo Molnar, Borislav Petkov, H. Peter Anvin, X86 ML, LKML On Mon, Nov 5, 2018 at 9:20 AM Dave Hansen <dave.hansen@intel.com> wrote: > > > On 11/4/18 9:14 PM, Andy Lutomirski wrote: > > I should add: if this patch is *not* applied, then I think we'll > > need to replace the sw_error_code check with user_mode(regs) to avoid > > an info leak if CET is enabled. Because, with CET, WRUSS will allow > > a *kernel* mode access (where regs->sp is the kernel stack pointer) > > with user permissions. > > Are you saying that WRUSS, if it faults will set the "user" page fault > error code bit? I seem to have some rough recollection about it being > that way, and the shadow-stack spec does say: > > paging access control checks will be treated as a user-mode > shadow stack store > I believe so, and it would make sense for it to work this way. I would love some instructions for directly accessing normal user memory, too. Maybe a prefix? > But the SDM says: > > For all instruction fetches and most data accesses, this > distinction is determined by the current privilege level (CPL): > accesses made while CPL < 3 are supervisor-mode accesses, while > accesses made while CPL = 3 are user-mode accesses. > > It would certainly be ideal if things affecting the core architecture > like this were in the SDM itself before we merged them. It makes things > like this a lot easier to figure out. Agreed. The current documentation situation is not so good. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC PATCH] x86/mm/fault: Allow stack access below %rsp 2018-11-02 22:28 ` Dave Hansen 2018-11-05 5:11 ` Andy Lutomirski @ 2018-11-05 16:27 ` Waiman Long 2018-11-05 17:51 ` Dave Hansen 1 sibling, 1 reply; 12+ messages in thread From: Waiman Long @ 2018-11-05 16:27 UTC (permalink / raw) To: Dave Hansen, Dave Hansen, Andy Lutomirski, Peter Zijlstra, Thomas Gleixner, Ingo Molnar, Borislav Petkov Cc: H. Peter Anvin, x86, linux-kernel On 11/02/2018 06:28 PM, Dave Hansen wrote: > On 11/2/18 12:50 PM, Waiman Long wrote: >> On 11/02/2018 03:44 PM, Dave Hansen wrote: >>> On 11/2/18 12:40 PM, Waiman Long wrote: >>>> The 64k+ limit check is kind of arbitrary. So the check is now removed >>>> to just let expand_stack() decide if a segmentation fault should happen. >>> With the 64k check removed, what's the next limit that we bump into? Is >>> it just the stack_guard_gap space above the next-lowest VMA? >> I think it is both the stack_guard_gap space above the next lowest VMA >> and the rlimit(RLIMIT_STACK). > The gap seems to be hundreds of megabytes, typically where RLIMIT_STACK > is 8MB by default, so RLIMIT_STACK is likely to be the practical limit > that will be hit. So, practically, we've taken a ~64k area that we > would on-demand extend the stack into in one go, and turned that into a > the full ~8MB area that you could have expanded into anyway, but all at > once. > > That doesn't seem too insane, especially since we don't physically back > the 8MB or anything. Logically, it also seems like you *should* be able > to touch any bit of the stack within the rlimit. > > But, on the other hand, as our comments say: "Accessing the stack below > %sp is always a bug." Have we been unsuccessful in convincing our gcc > buddies of this? With gcc 4.4.7, the object code for the sample program in the commit log are: 0x00000000004004c4 <+0>: push %rbp 0x00000000004004c5 <+1>: mov %rsp,%rbp 0x00000000004004c8 <+4>: push %rbx 0x00000000004004c9 <+5>: sub $0x18,%rsp 0x00000000004004cd <+9>: lea -0x2ff8(%rsp),%rax 0x00000000004004d5 <+17>: movq $0x0,(%rax) 0x00000000004004dc <+24>: mov %rsp,%rax 0x00000000004004df <+27>: mov %rax,%rbx 0x00000000004004e2 <+30>: lea -0x3ff8(%rsp),%rax 0x00000000004004ea <+38>: lea -0x43008(%rsp),%rdx 0x00000000004004f2 <+46>: jmp 0x400501 <main+61> 0x00000000004004f4 <+48>: movq $0x0,(%rax) 0x00000000004004fb <+55>: sub $0x1000,%rax 0x0000000000400501 <+61>: cmp %rdx,%rax 0x0000000000400504 <+64>: ja 0x4004f4 <main+48> 0x0000000000400506 <+66>: movq $0x0,(%rdx) 0x000000000040050d <+73>: sub $0x40010,%rsp 0x0000000000400514 <+80>: mov %rsp,%rax 0x0000000000400517 <+83>: add $0xf,%rax 0x000000000040051b <+87>: shr $0x4,%rax 0x000000000040051f <+91>: shl $0x4,%rax 0x0000000000400523 <+95>: mov %rax,-0x18(%rbp) 0x0000000000400527 <+99>: mov $0x400638,%edi 0x000000000040052c <+104>: callq 0x4003b8 <puts@plt> 0x0000000000400531 <+109>: mov $0x0,%eax 0x0000000000400536 <+114>: mov %rbx,%rsp 0x0000000000400539 <+117>: mov -0x8(%rbp),%rbx 0x000000000040053d <+121>: leaveq 0x000000000040053e <+122>: retq With a newer gcc 4.8.5, the object code becomes 0x000000000040052d <+0>: push %rbp 0x000000000040052e <+1>: mov %rsp,%rbp 0x0000000000400531 <+4>: lea -0x1020(%rsp),%rsp 0x0000000000400539 <+12>: mov $0xfffffffffffc0000,%r11 0x0000000000400540 <+19>: lea (%rsp,%r11,1),%r11 0x0000000000400544 <+23>: cmp %r11,%rsp 0x0000000000400547 <+26>: je 0x400557 <main+42> 0x0000000000400549 <+28>: sub $0x1000,%rsp 0x0000000000400550 <+35>: orq $0x0,(%rsp) 0x0000000000400555 <+40>: jmp 0x400544 <main+23> 0x0000000000400557 <+42>: lea 0x1020(%rsp),%rsp 0x000000000040055f <+50>: mov $0x400600,%edi 0x0000000000400564 <+55>: callq 0x400410 <puts@plt> 0x0000000000400569 <+60>: mov $0x0,%eax 0x000000000040056e <+65>: leaveq 0x000000000040056f <+66>: retq So gcc had changed to avoid doing that, but my main concern are old binaries that were compiled with old gcc. Cheers, Longman ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC PATCH] x86/mm/fault: Allow stack access below %rsp 2018-11-05 16:27 ` Waiman Long @ 2018-11-05 17:51 ` Dave Hansen 0 siblings, 0 replies; 12+ messages in thread From: Dave Hansen @ 2018-11-05 17:51 UTC (permalink / raw) To: Waiman Long, Dave Hansen, Andy Lutomirski, Peter Zijlstra, Thomas Gleixner, Ingo Molnar, Borislav Petkov Cc: H. Peter Anvin, x86, linux-kernel On 11/5/18 8:27 AM, Waiman Long wrote: > So gcc had changed to avoid doing that, but my main concern are old > binaries that were compiled with old gcc. Yeah, fair enough. FWIW, I don't have any strong feelings about this patch either way, but supporting old binaries/compilers without crashing seems fairly important. I'm yet to see any major downsides to your patch. ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2018-11-05 19:22 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-11-02 19:40 [RFC PATCH] x86/mm/fault: Allow stack access below %rsp Waiman Long 2018-11-02 19:44 ` Dave Hansen 2018-11-02 19:50 ` Waiman Long 2018-11-02 20:11 ` Andy Lutomirski 2018-11-02 20:34 ` Waiman Long 2018-11-02 22:28 ` Dave Hansen 2018-11-05 5:11 ` Andy Lutomirski 2018-11-05 5:14 ` Andy Lutomirski 2018-11-05 17:20 ` Dave Hansen 2018-11-05 19:21 ` Andy Lutomirski 2018-11-05 16:27 ` Waiman Long 2018-11-05 17:51 ` Dave Hansen
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).