* Re: [PATCH 46/61] fix Intel RNG detection @ 2006-11-21 11:22 Vassilios Kotoulas 0 siblings, 0 replies; 4+ messages in thread From: Vassilios Kotoulas @ 2006-11-21 11:22 UTC (permalink / raw) To: linux-kernel >> Dave Jones (davej@xxxxxxxxxx) wrote: >> Since I pushed an update to our Fedora users based on 2.6.18.2, a few people >> have reported they no longer have their RNG's detected. >> Here's one report: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=215144 > Hmm, I wonder if the report is valid? Jan's patch would have the correct > side effect of disabling false positives (for RNG identification). > Be good to check that it actually used to work. > > Having said that, Jan the datasheet recommendation is looser than your > implementation. It only recommends checking for manufacturer code, > you check device code as well. Do you know of any scenarios where that > would matter (I can't conceive of any)? Hi, sorry for the broken threading, I read this in the archives. My RNG worked with the older kernel 2.6.18-1.2200.fc5 I booted this kernel and made the following tests: hexdump -v /dev/hw_random here is the beginning of the output: 0000000 a7ff 1dff b312 0be0 64c9 8f83 9082 7d94 0000010 ac03 c513 ac1b b502 b93e 8f34 1a05 d417 0000020 b9cc c5d5 345f e6f6 d84b 333c c156 9007 0000030 0539 b145 7fdc 071b ea10 9145 c395 5536 0000040 7942 f8a2 f07d a5ea 2c76 a934 742c 1288 0000050 925a f710 67e6 8f68 ece2 bb23 536d bebe 0000060 1ad3 ab94 ab7b 54c9 8ce3 adaa 7f79 edd7 0000070 4c5b 0a28 66ee bc8d 90ae 0515 353e dcf5 These Numbers seem random to me :) rngtest produces the following output: [root@kra:~] rngtest -t1 </dev/hw_random rngtest 2 Copyright (c) 2004 by Henrique de Moraes Holschuh This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. rngtest: starting FIPS tests... rngtest: bits received from input: 60032 rngtest: FIPS 140-2 successes: 3 rngtest: FIPS 140-2 failures: 0 rngtest: FIPS 140-2(2001-10-10) Monobit: 0 rngtest: FIPS 140-2(2001-10-10) Poker: 0 rngtest: FIPS 140-2(2001-10-10) Runs: 0 rngtest: FIPS 140-2(2001-10-10) Long run: 0 rngtest: FIPS 140-2(2001-10-10) Continuous run: 0 rngtest: input channel speed: (min=44.617; avg=48.397; max=51.079)Kibits/s rngtest: FIPS tests speed: (min=62.129; avg=62.536; max=62.949)Mibits/s rngtest: Program run time: 1211852 microseconds rngtest: bits received from input: 120032 rngtest: FIPS 140-2 successes: 6 rngtest: FIPS 140-2 failures: 0 rngtest: FIPS 140-2(2001-10-10) Monobit: 0 rngtest: FIPS 140-2(2001-10-10) Poker: 0 rngtest: FIPS 140-2(2001-10-10) Runs: 0 rngtest: FIPS 140-2(2001-10-10) Long run: 0 rngtest: FIPS 140-2(2001-10-10) Continuous run: 0 rngtest: input channel speed: (min=44.307; avg=46.440; max=51.079)Kibits/s rngtest: FIPS tests speed: (min=59.980; avg=61.627; max=62.949)Mibits/s rngtest: Program run time: 2525610 microseconds I also updated the bugzilla report with these tests. ^ permalink raw reply [flat|nested] 4+ messages in thread
* [PATCH 00/61] 2.6.18-stable review
@ 2006-11-01 5:33 Chris Wright
2006-11-01 5:34 ` [PATCH 46/61] fix Intel RNG detection Chris Wright
0 siblings, 1 reply; 4+ messages in thread
From: Chris Wright @ 2006-11-01 5:33 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Justin Forbes, Zwane Mwaikambo, Theodore Ts'o, Randy Dunlap,
Dave Jones, Chuck Wolber, Chris Wedgwood, Michael Krufky,
torvalds, akpm, alan
This is the start of the stable review cycle for the 2.6.18.2 release.
There are 61 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let us know. If anyone is a maintainer of the proper subsystem, and
wants to add a Signed-off-by: line to the patch, please respond with it.
These patches are sent out with a number of different people on the
Cc: line. If you wish to be a reviewer, please email stable@kernel.org
to add your name to the list. If you want to be off the reviewer list,
also email us.
Responses should be made by Friday, November 3, 05:30:00 UTC.
Anything received after that time might be too late.
An all-in-one patch for this series can be found at:
http://www.kernel.org/pub/linux/kernel/people/chrisw/stable/patch-2.6.18.2-rc1.gz
if anyone wants to test this out that way.
thanks,
the -stable release team
--
^ permalink raw reply [flat|nested] 4+ messages in thread* [PATCH 46/61] fix Intel RNG detection 2006-11-01 5:33 [PATCH 00/61] 2.6.18-stable review Chris Wright @ 2006-11-01 5:34 ` Chris Wright 2006-11-20 23:45 ` Dave Jones 0 siblings, 1 reply; 4+ messages in thread From: Chris Wright @ 2006-11-01 5:34 UTC (permalink / raw) To: linux-kernel, stable Cc: Justin Forbes, Zwane Mwaikambo, Theodore Ts'o, Randy Dunlap, Dave Jones, Chuck Wolber, Chris Wedgwood, Michael Krufky, torvalds, akpm, alan, Jan Beulich, Metathronius Galabant, Michael Buesch, Greg Kroah-Hartman [-- Attachment #1: fix-intel-rng-detection.patch --] [-- Type: text/plain, Size: 9017 bytes --] -stable review patch. If anyone has any objections, please let us know. ------------------ From: Jan Beulich <jbeulich@novell.com> [PATCH] fix Intel RNG detection Previously, since determination whether there was an Intel random number generator was based on a single bit, on systems with a matching bridge device but without a firmware hub, there was a 50% chance that the code would incorrectly decide that the system had an RNG. This patch adds detection of the firmware hub to better qualify the existence of an RNG. There is one issue with the patch: I was unable to determine the LPC equivalent for the PCI bridge 8086:2430 (since the old code didn't care about which of the many devices provided by the ICH/ESB it was chose to use the PCI bridge device, but the FWH settings live in the LPC device, so the device list needed to be changed). Signed-off-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Michael Buesch <mb@bu3sch.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Chris Wright <chrisw@sous-sol.org> --- drivers/char/hw_random/intel-rng.c | 186 +++++++++++++++++++++++++++++++++++-- 1 file changed, 177 insertions(+), 9 deletions(-) --- linux-2.6.18.1.orig/drivers/char/hw_random/intel-rng.c +++ linux-2.6.18.1/drivers/char/hw_random/intel-rng.c @@ -50,6 +50,43 @@ #define INTEL_RNG_ADDR_LEN 3 /* + * LPC bridge PCI config space registers + */ +#define FWH_DEC_EN1_REG_OLD 0xe3 +#define FWH_DEC_EN1_REG_NEW 0xd9 /* high byte of 16-bit register */ +#define FWH_F8_EN_MASK 0x80 + +#define BIOS_CNTL_REG_OLD 0x4e +#define BIOS_CNTL_REG_NEW 0xdc +#define BIOS_CNTL_WRITE_ENABLE_MASK 0x01 +#define BIOS_CNTL_LOCK_ENABLE_MASK 0x02 + +/* + * Magic address at which Intel Firmware Hubs get accessed + */ +#define INTEL_FWH_ADDR 0xffff0000 +#define INTEL_FWH_ADDR_LEN 2 + +/* + * Intel Firmware Hub command codes (write to any address inside the device) + */ +#define INTEL_FWH_RESET_CMD 0xff /* aka READ_ARRAY */ +#define INTEL_FWH_READ_ID_CMD 0x90 + +/* + * Intel Firmware Hub Read ID command result addresses + */ +#define INTEL_FWH_MANUFACTURER_CODE_ADDRESS 0x000000 +#define INTEL_FWH_DEVICE_CODE_ADDRESS 0x000001 + +/* + * Intel Firmware Hub Read ID command result values + */ +#define INTEL_FWH_MANUFACTURER_CODE 0x89 +#define INTEL_FWH_DEVICE_CODE_8M 0xac +#define INTEL_FWH_DEVICE_CODE_4M 0xad + +/* * Data for PCI driver interface * * This data only exists for exporting the supported @@ -58,12 +95,50 @@ * want to register another driver on the same PCI id. */ static const struct pci_device_id pci_tbl[] = { - { 0x8086, 0x2418, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, - { 0x8086, 0x2428, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, - { 0x8086, 0x2430, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, - { 0x8086, 0x2448, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, - { 0x8086, 0x244e, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, - { 0x8086, 0x245e, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, +/* AA + { 0x8086, 0x2418, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, */ + { 0x8086, 0x2410, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* AA */ +/* AB + { 0x8086, 0x2428, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, */ + { 0x8086, 0x2420, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* AB */ +/* ?? + { 0x8086, 0x2430, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, */ +/* BAM, CAM, DBM, FBM, GxM + { 0x8086, 0x2448, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, */ + { 0x8086, 0x244c, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* BAM */ + { 0x8086, 0x248c, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* CAM */ + { 0x8086, 0x24cc, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* DBM */ + { 0x8086, 0x2641, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* FBM */ + { 0x8086, 0x27b9, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* GxM */ + { 0x8086, 0x27bd, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* GxM DH */ +/* BA, CA, DB, Ex, 6300, Fx, 631x/632x, Gx + { 0x8086, 0x244e, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, */ + { 0x8086, 0x2440, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* BA */ + { 0x8086, 0x2480, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* CA */ + { 0x8086, 0x24c0, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* DB */ + { 0x8086, 0x24d0, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* Ex */ + { 0x8086, 0x25a1, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* 6300 */ + { 0x8086, 0x2640, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* Fx */ + { 0x8086, 0x2670, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* 631x/632x */ + { 0x8086, 0x2671, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* 631x/632x */ + { 0x8086, 0x2672, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* 631x/632x */ + { 0x8086, 0x2673, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* 631x/632x */ + { 0x8086, 0x2674, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* 631x/632x */ + { 0x8086, 0x2675, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* 631x/632x */ + { 0x8086, 0x2676, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* 631x/632x */ + { 0x8086, 0x2677, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* 631x/632x */ + { 0x8086, 0x2678, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* 631x/632x */ + { 0x8086, 0x2679, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* 631x/632x */ + { 0x8086, 0x267a, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* 631x/632x */ + { 0x8086, 0x267b, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* 631x/632x */ + { 0x8086, 0x267c, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* 631x/632x */ + { 0x8086, 0x267d, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* 631x/632x */ + { 0x8086, 0x267e, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* 631x/632x */ + { 0x8086, 0x267f, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* 631x/632x */ + { 0x8086, 0x27b8, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* Gx */ +/* E + { 0x8086, 0x245e, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, */ + { 0x8086, 0x2450, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0, }, /* E */ { 0, }, /* terminate list */ }; MODULE_DEVICE_TABLE(pci, pci_tbl); @@ -138,22 +213,115 @@ static struct hwrng intel_rng = { }; +#ifdef CONFIG_SMP +static char __initdata waitflag; + +static void __init intel_init_wait(void *unused) +{ + while (waitflag) + cpu_relax(); +} +#endif + static int __init mod_init(void) { int err = -ENODEV; + unsigned i; + struct pci_dev *dev = NULL; void __iomem *mem; - u8 hw_status; + unsigned long flags; + u8 bios_cntl_off, fwh_dec_en1_off; + u8 bios_cntl_val = 0xff, fwh_dec_en1_val = 0xff; + u8 hw_status, mfc, dvc; + + for (i = 0; !dev && pci_tbl[i].vendor; ++i) + dev = pci_get_device(pci_tbl[i].vendor, pci_tbl[i].device, NULL); - if (!pci_dev_present(pci_tbl)) + if (!dev) goto out; /* Device not found. */ + /* Check for Intel 82802 */ + if (dev->device < 0x2640) { + fwh_dec_en1_off = FWH_DEC_EN1_REG_OLD; + bios_cntl_off = BIOS_CNTL_REG_OLD; + } else { + fwh_dec_en1_off = FWH_DEC_EN1_REG_NEW; + bios_cntl_off = BIOS_CNTL_REG_NEW; + } + + pci_read_config_byte(dev, fwh_dec_en1_off, &fwh_dec_en1_val); + pci_read_config_byte(dev, bios_cntl_off, &bios_cntl_val); + + mem = ioremap_nocache(INTEL_FWH_ADDR, INTEL_FWH_ADDR_LEN); + if (mem == NULL) { + pci_dev_put(dev); + err = -EBUSY; + goto out; + } + + /* + * Since the BIOS code/data is going to disappear from its normal + * location with the Read ID command, all activity on the system + * must be stopped until the state is back to normal. + */ +#ifdef CONFIG_SMP + set_mb(waitflag, 1); + if (smp_call_function(intel_init_wait, NULL, 1, 0) != 0) { + set_mb(waitflag, 0); + pci_dev_put(dev); + printk(KERN_ERR PFX "cannot run on all processors\n"); + err = -EAGAIN; + goto err_unmap; + } +#endif + local_irq_save(flags); + + if (!(fwh_dec_en1_val & FWH_F8_EN_MASK)) + pci_write_config_byte(dev, + fwh_dec_en1_off, + fwh_dec_en1_val | FWH_F8_EN_MASK); + if (!(bios_cntl_val & + (BIOS_CNTL_LOCK_ENABLE_MASK|BIOS_CNTL_WRITE_ENABLE_MASK))) + pci_write_config_byte(dev, + bios_cntl_off, + bios_cntl_val | BIOS_CNTL_WRITE_ENABLE_MASK); + + writeb(INTEL_FWH_RESET_CMD, mem); + writeb(INTEL_FWH_READ_ID_CMD, mem); + mfc = readb(mem + INTEL_FWH_MANUFACTURER_CODE_ADDRESS); + dvc = readb(mem + INTEL_FWH_DEVICE_CODE_ADDRESS); + writeb(INTEL_FWH_RESET_CMD, mem); + + if (!(bios_cntl_val & + (BIOS_CNTL_LOCK_ENABLE_MASK|BIOS_CNTL_WRITE_ENABLE_MASK))) + pci_write_config_byte(dev, bios_cntl_off, bios_cntl_val); + if (!(fwh_dec_en1_val & FWH_F8_EN_MASK)) + pci_write_config_byte(dev, fwh_dec_en1_off, fwh_dec_en1_val); + + local_irq_restore(flags); +#ifdef CONFIG_SMP + /* Tell other CPUs to resume. */ + set_mb(waitflag, 0); +#endif + + iounmap(mem); + pci_dev_put(dev); + + if (mfc != INTEL_FWH_MANUFACTURER_CODE || + (dvc != INTEL_FWH_DEVICE_CODE_8M && + dvc != INTEL_FWH_DEVICE_CODE_4M)) { + printk(KERN_ERR PFX "FWH not detected\n"); + err = -ENODEV; + goto out; + } + err = -ENOMEM; mem = ioremap(INTEL_RNG_ADDR, INTEL_RNG_ADDR_LEN); if (!mem) goto out; intel_rng.priv = (unsigned long)mem; - /* Check for Intel 82802 */ + /* Check for Random Number Generator */ err = -ENODEV; hw_status = hwstatus_get(mem); if ((hw_status & INTEL_RNG_PRESENT) == 0) -- ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH 46/61] fix Intel RNG detection 2006-11-01 5:34 ` [PATCH 46/61] fix Intel RNG detection Chris Wright @ 2006-11-20 23:45 ` Dave Jones 2006-11-21 9:05 ` Michael Buesch 0 siblings, 1 reply; 4+ messages in thread From: Dave Jones @ 2006-11-20 23:45 UTC (permalink / raw) To: Chris Wright Cc: linux-kernel, stable, Justin Forbes, Zwane Mwaikambo, Theodore Ts'o, Randy Dunlap, Chuck Wolber, Chris Wedgwood, Michael Krufky, torvalds, akpm, alan, Jan Beulich, Metathronius Galabant, Michael Buesch, Greg Kroah-Hartman On Tue, Oct 31, 2006 at 09:34:26PM -0800, Chris Wright wrote: > From: Jan Beulich <jbeulich@novell.com> > > [PATCH] fix Intel RNG detection > > Previously, since determination whether there was an Intel random number > generator was based on a single bit, on systems with a matching bridge > device but without a firmware hub, there was a 50% chance that the code > would incorrectly decide that the system had an RNG. This patch adds > detection of the firmware hub to better qualify the existence of an RNG. > > There is one issue with the patch: I was unable to determine the LPC > equivalent for the PCI bridge 8086:2430 (since the old code didn't care > about which of the many devices provided by the ICH/ESB it was chose to use > the PCI bridge device, but the FWH settings live in the LPC device, so the > device list needed to be changed). > > Signed-off-by: Jan Beulich <jbeulich@novell.com> > Signed-off-by: Michael Buesch <mb@bu3sch.de> > Signed-off-by: Andrew Morton <akpm@osdl.org> > Signed-off-by: Linus Torvalds <torvalds@osdl.org> > Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> > Signed-off-by: Chris Wright <chrisw@sous-sol.org> Since I pushed an update to our Fedora users based on 2.6.18.2, a few people have reported they no longer have their RNG's detected. Here's one report: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=215144 Dave -- http://www.codemonkey.org.uk ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH 46/61] fix Intel RNG detection 2006-11-20 23:45 ` Dave Jones @ 2006-11-21 9:05 ` Michael Buesch 0 siblings, 0 replies; 4+ messages in thread From: Michael Buesch @ 2006-11-21 9:05 UTC (permalink / raw) To: Chris Wright Cc: linux-kernel, stable, Justin Forbes, Zwane Mwaikambo, Theodore Ts'o, Randy Dunlap, Chuck Wolber, Chris Wedgwood, Michael Krufky, torvalds, akpm, alan, Jan Beulich, Metathronius Galabant, Michael Buesch, Greg Kroah-Hartman On Tuesday 21 November 2006 00:45, Dave Jones wrote: > On Tue, Oct 31, 2006 at 09:34:26PM -0800, Chris Wright wrote: > > > From: Jan Beulich <jbeulich@novell.com> > > > > [PATCH] fix Intel RNG detection > > > > Previously, since determination whether there was an Intel random number > > generator was based on a single bit, on systems with a matching bridge > > device but without a firmware hub, there was a 50% chance that the code > > would incorrectly decide that the system had an RNG. This patch adds > > detection of the firmware hub to better qualify the existence of an RNG. > > > > There is one issue with the patch: I was unable to determine the LPC > > equivalent for the PCI bridge 8086:2430 (since the old code didn't care > > about which of the many devices provided by the ICH/ESB it was chose to use > > the PCI bridge device, but the FWH settings live in the LPC device, so the > > device list needed to be changed). > > > > Signed-off-by: Jan Beulich <jbeulich@novell.com> > > Signed-off-by: Michael Buesch <mb@bu3sch.de> > > Signed-off-by: Andrew Morton <akpm@osdl.org> > > Signed-off-by: Linus Torvalds <torvalds@osdl.org> > > Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> > > Signed-off-by: Chris Wright <chrisw@sous-sol.org> > > > Since I pushed an update to our Fedora users based on 2.6.18.2, a few people > have reported they no longer have their RNG's detected. > Here's one report: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=215144 Well, this patch should acutally fix false detections. Did these people actually have a _working_ rng before? I saw a report of a mac user, for which the rng disappeared. But the previously "detected" rng didn't work either. (Work as in produces sane random numbers). So there actually wasn't a rng available all the time. -- Greetings Michael. ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2006-11-21 11:22 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-11-21 11:22 [PATCH 46/61] fix Intel RNG detection Vassilios Kotoulas -- strict thread matches above, loose matches on Subject: below -- 2006-11-01 5:33 [PATCH 00/61] 2.6.18-stable review Chris Wright 2006-11-01 5:34 ` [PATCH 46/61] fix Intel RNG detection Chris Wright 2006-11-20 23:45 ` Dave Jones 2006-11-21 9:05 ` Michael Buesch
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®