RW writes:
> Yes, getting a monotonically increasing value from binuptime() is
> simple, but the xor issue is secondary to the problem I was referring
> to when I quoted the arm code for get_cyclecount().
BTW, I just checked - the code you quoted does not exist / no longer
exists anywhere in the
On Wed, 03 Oct 2012 11:32:45 +0200
Dag-Erling Smørgrav wrote:
> RW writes:
> > It doesn't compute it in a weird way for amd64 and most i386
> > systems. Where possible, get_cyclecount is just a wrapper for
> > rdtsc, which I think it will be for all the systems you quoted
> > (with the possible e
On Wed, 03 Oct 2012 13:42:03 +0200
Dag-Erling Smørgrav wrote:
> RW writes:
> > As I pointed-out before if you use binuptime() you cant use entropy
> > estimation based on bit-shifting time differences.
>
> Forgot to answer this: yes you can. The last time I raised the
> issue, I also provided s
RW writes:
> As I pointed-out before if you use binuptime() you cant use entropy
> estimation based on bit-shifting time differences.
Forgot to answer this: yes you can. The last time I raised the issue, I
also provided sample code for reimplementing get_cyclecount() in terms
of binuptime(). Ba
RW writes:
> It doesn't compute it in a weird way for amd64 and most i386 systems.
> Where possible, get_cyclecount is just a wrapper for rdtsc, which I
> think it will be for all the systems you quoted (with the possible
> exception of virtualbox).
No. All the machines I tested it on had TSCs,
On Tue, 02 Oct 2012 19:22:40 +0200
Dag-Erling Smørgrav wrote:
> 2) I modified the program to create a histogram of the lower bits and
>looked at that in gnuplot. It was immediately obvious that the
>distribution is extremely non-uniform. I suspect that this is - at
>least in part -
Dag-Erling Smørgrav writes:
> http://people.freebsd.org/~des/attachtimes-text.txz
1) There is a bug in the program - I made a couple of changes which I
didn't like but didn't fully revert. The (argc != 0) in main()
should actually be (argc == 0).
2) I modified the program to create a hist
Dag-Erling Smørgrav writes:
> If you give me a couple of days, I'll try to come up with a patch that
> collects and stores attach times during boot so we can gather and
> analyse real data.
Here's the data:
http://people.freebsd.org/~des/attachtimes-text.txz
The tarball contains one directory
Dag-Erling Smørgrav writes:
> With a sub-minute cycle time, I can get a couple of hundred thousand
> samples per machine over the weekend.
Uh, not even close. My sleep-deprived brain substituted 86400 for 1440.
I should still get 10 - 20 thousand samples, though.
DES
--
Dag-Erling Smørgrav - d
Bruce Evans writes:
> I should have objected more strongly when it was implemented.
So let's kill it :)
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
T
On Fri, 28 Sep 2012, [utf-8] Dag-Erling Sm??rgrav wrote:
Bruce Evans writes:
"Dag-Erling Sm??rgrav" writes:
RW writes:
binuptime(&bt);
return (bt.frac ^ bt.sec);
Why the heck does it xor the integer and fractional parts together?
Because most of the entropy is in the fractional part,
T
I now have two EPIAs, a laptop and a VirtualBox VM gathering data using
this patch:
http://people.freebsd.org/~des/software/attachtimes.diff
If you want to join in, here's how to prepare a USB stick:
fetch http://people.freebsd.org/~des/software/attachtimes.tgz
dd if=/dev/zero of=/dev/da0
Bruce Evans writes:
> "Dag-Erling Smørgrav" writes:
> > RW writes:
> > > binuptime(&bt);
> > > return (bt.frac ^ bt.sec);
> > Why the heck does it xor the integer and fractional parts together?
> Because most of the entropy is in the fractional part,
This is not about entropy, it's about implem
On Thu, 27 Sep 2012, [utf-8] Dag-Erling Sm??rgrav wrote:
RW writes:
static __inline uint64_t
get_cyclecount(void)
{
struct bintime bt;
binuptime(&bt);
return (bt.frac ^ bt.sec);
}
Why the heck does it xor the integer and fractional parts together?
That makes no sens
RW writes:
> static __inline uint64_t
> get_cyclecount(void)
> {
> struct bintime bt;
>
> binuptime(&bt);
> return (bt.frac ^ bt.sec);
>
> }
Why the heck does it xor the integer and fractional parts together?
That makes no sense at all. I would ha
On Thu, 27 Sep 2012 10:56:24 +0100
Ben Laurie wrote:
> On Thu, Sep 27, 2012 at 10:49 AM, Dag-Erling Smørgrav
> wrote:
> > RW writes:
> >> "Dag-Erling Smørgrav" writes:
> >> > You can't rely on the existence of a TSC. I would suggest using
> >> > the fractional part of binuptime instead.
> >> g
Ben Laurie writes:
> We should certainly see how things look on slow systems, but note that
> if the resolution is lower, then the measurements will also be smaller
> (assuming attachment takes similar time), and so we will claim less
> entropy anyway :-)
Ah, I forgot about Pawel's flsl() trick.
On Thu, Sep 27, 2012 at 10:49 AM, Dag-Erling Smørgrav wrote:
> RW writes:
>> "Dag-Erling Smørgrav" writes:
>> > You can't rely on the existence of a TSC. I would suggest using the
>> > fractional part of binuptime instead.
>> get_cyclecount() is supposed to be platform independent and should
>>
RW writes:
> "Dag-Erling Smørgrav" writes:
> > You can't rely on the existence of a TSC. I would suggest using the
> > fractional part of binuptime instead.
> get_cyclecount() is supposed to be platform independent and should
> fall-back to nanotime(9) if TSC or equivalent is absent.
I just tho
Dag-Erling Smørgrav writes:
> If you give me a couple of days, I'll try to come up with a patch that
> collects and stores attach times during boot so we can gather and
> analyse real data.
Here's the patch, as a superset of Pawel's. The output looks like this:
des@crashbox ~% sysctl -b hw.atta
On Tuesday, September 25, 2012 4:05:34 pm Mariusz Gromada wrote:
> Our task is to check if there are any autocorrelations in the X(w,t)
> process, which means checking if there are any dependencies between
> random variables X(w,t1) and X(w,t2) where t1 < t2.
Just to state an obvious fact (not s
On Tue, 25 Sep 2012 11:36:31 +0200
Mariusz Gromada wrote:
> Here we did some initial testing, mainly based on charts, which showed
> typical noise in time. But again, it requires a formal proof.
When you say formal proof lets be clear that you aren't actually
proving anything about entropy.
Ent
W dniu 2012-09-25 11:05, Ben Laurie pisze:
I created dummy driver which was registering three dummy drivers, so it
was provoking three device_attach() calls on every kldload. Mariusz
verified the observations and there was no correlation between the
times.
Sorry to those that are bored, but ..
Pawel Jakub Dawidek writes:
> "Dag-Erling Smørgrav" writes:
> > (I don't even need PXE - they'll probably boot faster from USB
> > sticks or disks)
> And probably more reliable. My netbooted test machines occasionally
> don't boot and you don't want to find out in the morning that the whole
> pro
On Tue, Sep 25, 2012 at 12:58:37PM +0200, Dag-Erling Smørgrav wrote:
> Pawel Jakub Dawidek writes:
> > Note that this fake data is the hardest to gather entropy from, as it
> > doesn't interact with any external hardware. I'm all for testing it on
> > real hardware and I expect to be able to gathe
>
>
> You cannot conclude that - no test can tell you it, but this test
> rather obviously does not, since what it tests is the equality of
> probability distributions, so what you can now say is that the
> distribution is square. A completely predictable sequence, say 0..63,
> would satisfy that.
2012/9/25 Mariusz Gromada
>
> Empirically, it seems to me that these numbers are actually unlikely
>> to be correlated with each other, but that has not been tested.
>>
>
>
> Another yes, you are right. We need much more data to check if we have a
> stochastic process consisted of independent rand
Pawel Jakub Dawidek writes:
> Note that this fake data is the hardest to gather entropy from, as it
> doesn't interact with any external hardware. I'm all for testing it on
> real hardware and I expect to be able to gather even more entropy from
> it (so discarding less than top 7 bits). The probl
On Tue, Sep 25, 2012 at 11:28:13AM +0200, Dag-Erling Smørgrav wrote:
> Ben Laurie writes:
> > Not that I dislike Pawel's approach, it seems promising, I'm just
> > pointing out the weakness of the analysis.
>
> It is also based on fake data.
>
> If you give me a couple of days, I'll try to come
Ben Laurie writes:
> Not that I dislike Pawel's approach, it seems promising, I'm just
> pointing out the weakness of the analysis.
It is also based on fake data.
If you give me a couple of days, I'll try to come up with a patch that
collects and stores attach times during boot so we can gather
On Tue, Sep 25, 2012 at 6:32 AM, Pawel Jakub Dawidek wrote:
> On Tue, Sep 25, 2012 at 12:10:13AM +0200, Mariusz Gromada wrote:
>> W dniu 2012-09-24 23:56, Mariusz Gromada pisze:
>>
>> > Ok, finally I have some formal results. To be completely honest I need
>> > to point out that, in fact, we have
On Mon, Sep 24, 2012 at 10:56 PM, Mariusz Gromada
wrote:
> W dniu 2012-09-23 17:17, Pawel Jakub Dawidek pisze:
>
>> On Sun, Sep 23, 2012 at 02:37:48AM +0200, Mariusz Gromada wrote:
>>>
>>> W dniu 2012-09-22 21:53, Pawel Jakub Dawidek pisze:
Mariusz, can you confirm my findings?
>>>
>>>
>
On Tue, Sep 25, 2012 at 12:10:13AM +0200, Mariusz Gromada wrote:
> W dniu 2012-09-24 23:56, Mariusz Gromada pisze:
>
> > Ok, finally I have some formal results. To be completely honest I need
> > to point out that, in fact, we have a discrete data (for example
> > integers 0, 1, ..., 63, but not c
W dniu 2012-09-24 23:56, Mariusz Gromada pisze:
Ok, finally I have some formal results. To be completely honest I need
to point out that, in fact, we have a discrete data (for example
integers 0, 1, ..., 63, but not continues numbers spread across 0 and
63). That is way I am going to use two sa
W dniu 2012-09-23 17:17, Pawel Jakub Dawidek pisze:
On Sun, Sep 23, 2012 at 02:37:48AM +0200, Mariusz Gromada wrote:
W dniu 2012-09-22 21:53, Pawel Jakub Dawidek pisze:
Mariusz, can you confirm my findings?
Pawel,
Your conclusions can be easily confirmed by shape analysis of the EDF.
Usually
On Sun, Sep 23, 2012 at 02:37:48AM +0200, Mariusz Gromada wrote:
> W dniu 2012-09-22 21:53, Pawel Jakub Dawidek pisze:
> > Mariusz, can you confirm my findings?
>
> Pawel,
>
> Your conclusions can be easily confirmed by shape analysis of the EDF.
> Usually maximum quantile difference (called D-
On Sat, 22 Sep 2012 01:20:32 +0200
Dag-Erling Smørgrav wrote:
> RW writes:
> > They key will therefore *accumulate* entropy across multiple
> > reseeds.
>
> Forgot to address this. By definition, there can never be more
> entropy in Yarrow than the key size. So it *does* throw away entropy
> i
W dniu 2012-09-22 21:53, Pawel Jakub Dawidek pisze:
Mariusz, can you confirm my findings?
Pawel,
Your conclusions can be easily confirmed by shape analysis of the EDF.
Usually maximum quantile difference (called D-statistic) gives you a
kind of overview, function shape gives you a strong fee
On Sat, Sep 22, 2012 at 10:03:23AM +0200, Pawel Jakub Dawidek wrote:
> If discarding top ten bit in case of such dummy driver is enough, we
> could probably discard less from drivers that interact with real
> hardware, but even with 43 device_attach() calls during boot on similar
> hardware and ass
On Thu, Sep 20, 2012 at 07:58:51AM -0400, John Baldwin wrote:
> On Thursday, September 20, 2012 6:21:04 am Pawel Jakub Dawidek wrote:
> > I agree, we should do such analysis for much more devices and different
> > kind of devices. A platform might be an important factor as well.
> > It is hard to c
On Wed, Sep 19, 2012 at 07:28:36PM +0100, RW wrote:
> On Tue, 18 Sep 2012 23:14:22 +0200
> Pawel Jakub Dawidek wrote:
>
> > Hi.
> >
>
> > The patch is here:
> >
> > http://people.freebsd.org/~pjd/patches/harvest_device_attach.patch
> >
> > Comments?
> >
>
> + attachtime = get_cycleco
RW writes:
> They key will therefore *accumulate* entropy across multiple reseeds.
Forgot to address this. By definition, there can never be more entropy
in Yarrow than the key size. So it *does* throw away entropy in the
sense that if it accumulated, say, 900 bits of entropy pre-boot (to pick
RW writes:
> Dag-Erling Smørgrav writes:
> > RW writes:
> > > Reseeding doesn't throw away entropy
> > Yes, it does.
> Would you elaborate? I don't see what you mean by that?
Never mind. I read through the code multiple times without seeing the
line where it mixes in the old key. It does it i
On 09/21/2012 12:09 AM, Pawel Jakub Dawidek wrote:
> On Thu, Sep 20, 2012 at 11:08:15PM -0700, David O'Brien wrote:
>> On Fri, Sep 21, 2012 at 07:35:49AM +0200, Pawel Jakub Dawidek wrote:
>>> Note that adding sysctl to turn off entropy harvesting from
>>> device_attach() is pretty useless, as sysct
On Thu, Sep 20, 2012 at 11:08:15PM -0700, David O'Brien wrote:
> On Fri, Sep 21, 2012 at 07:35:49AM +0200, Pawel Jakub Dawidek wrote:
> > Note that adding sysctl to turn off entropy harvesting from
> > device_attach() is pretty useless, as sysctls can be changed once we
> > start userland and then
On Wed, Sep 19, 2012 at 03:34:59PM -0700, David O'Brien wrote:
> On Tue, Sep 18, 2012 at 11:14:22PM +0200, Pawel Jakub Dawidek wrote:
> > I experimented a bit with collecting entropy from the time it takes for
> > device_attach() to run (in CPU cycles). It seems that those times have
> > enough var
On Fri, Sep 21, 2012 at 07:35:49AM +0200, Pawel Jakub Dawidek wrote:
> Note that adding sysctl to turn off entropy harvesting from
> device_attach() is pretty useless, as sysctls can be changed once we
> start userland and then all device_attach() are already called (modulo
> drivers loaded later).
On Thu, Sep 20, 2012 at 11:32:53AM +0100, Jonathan Anderson wrote:
> As I believe theraven@ pointed out a couple of days ago: it is very
> silly indeed that we are taking data generated by the kernel (process
...
I thought I had mentioned something like this in the rc.d thread,
but it seems it wa
On Thu, 20 Sep 2012 08:32:36 +0100
Jonathan Anderson wrote:
> On Wednesday, 19 September 2012 at 21:46, RW wrote:
> > extra bits may make the difference between secure and insecure
>
> I'm sorry, this may be a bit pedantic, but I have to object to the
> terms "secure" and "insecure" used without
On Thu, 20 Sep 2012 11:05:32 +0200
Dag-Erling Smørgrav wrote:
> RW writes:
> > Dag-Erling Smørgrav writes:
> > > I would also suggest modifying yarrow to block reseeding as long
> > > as possible, ideally right up until the first time something asks
> > > for a random number, since reseeding thr
On Thursday, September 20, 2012 6:21:04 am Pawel Jakub Dawidek wrote:
> On Wed, Sep 19, 2012 at 11:10:51PM +0100, RW wrote:
> > On Wed, 19 Sep 2012 22:53:32 +0200
> > Pawel Jakub Dawidek wrote:
> >
> >
> > > Here's how the distribution looks like for device_attach() times of my
> > > sound card.
On Wed, Sep 19, 2012 at 11:10:51PM +0100, RW wrote:
> On Wed, 19 Sep 2012 22:53:32 +0200
> Pawel Jakub Dawidek wrote:
>
>
> > Here's how the distribution looks like for device_attach() times of my
> > sound card. The times were 26bit numbers, so this is after discarding
> > top ten bits, which le
Jonathan Anderson writes:
> I must've missed that e-mail. Sounds great: I'd love to see such
> statistics.
Yes, it went to a list with a much higher SNR than this one.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
freebsd-security@freebsd.org mailing l
On Thursday, 20 September 2012 at 11:30, Dag-Erling Smørgrav wrote:
> which is why when I proposed this last week I also proposed a scheme to
> record what we feed into Yarrow pre-boot so we could inspect it and
> compare it across multiple boots.
I must've missed that e-mail. Sounds great: I'd lo
On Thursday, 20 September 2012 at 11:21, Pawel Jakub Dawidek wrote:
> It would be ideal if we could provide properly seeded PRNG even for
> single-user mode, so eliminating initrandom altogether is also an
> option
Amen to that. :)
As I believe theraven@ pointed out a couple of days ago: it is
Jonathan Anderson writes:
> For instance: on an embedded board with few devices, that uses FDT
> rather than bus enumeration whatsits, perhaps the time is more
> deterministic and therefore yields less entropy.
The idea is that attach() initializes the hardware, which is where the
unpredictabilit
On Thursday, 20 September 2012 at 10:20, Dag-Erling Smørgrav wrote:
> Please understand that the timers used here have a resolution of around
> 1e-8 to 1e-10 seconds. You may be able to predict the first six digits
> with reasonable accuracy - in fact, the first four or five will almost
> always
Pawel Jakub Dawidek writes:
> http://people.freebsd.org/~pjd/patches/harvest_device_attach.2.patch
You can replace highbit(x) - 9 with flsll(x) - 10. Unfortunately, we
don't have flsll() in the kernel, but here's a simple implementation:
/*
* Find last bit set in an unsigned long long. Assume
RW writes:
> You're basing a model for all devices on a single sound card, that
> doesn't seem safe to me. Isn't it possible that a device could take a
> long and well defined time?
Please understand that the timers used here have a resolution of around
1e-8 to 1e-10 seconds. You may be able to
RW writes:
> Dag-Erling Smørgrav writes:
> > I would also suggest modifying yarrow to block reseeding as long as
> > possible, ideally right up until the first time something asks for a
> > random number, since reseeding throws away all accumulated entropy.
> reseeding doesn't throw away entropy
On Wed, Sep 19, 2012 at 9:20 PM, Pawel Jakub Dawidek wrote:
> On Wed, Sep 19, 2012 at 08:59:15PM +0100, Ben Laurie wrote:
>> On Wed, Sep 19, 2012 at 8:29 PM, Pawel Jakub Dawidek
>> wrote:
>> > On Wed, Sep 19, 2012 at 07:30:52PM +0100, Jonathan Anderson wrote:
>> >> > If all the times are more or
On Thu, Sep 20, 2012 at 7:54 AM, Jonathan Anderson wrote:
> On Wednesday, 19 September 2012 at 20:47, Ben Laurie wrote:
>
> Erring on the side of underestimation is wise here.
>
> I agree wholeheartedly, but underestimation means "calculating the correct
> value and then applying a safety factor"
On Wednesday, 19 September 2012 at 21:46, RW wrote:
> extra bits may make the difference between secure and insecure
I'm sorry, this may be a bit pedantic, but I have to object to the terms
"secure" and "insecure" used without qualification. :) Perhaps you mean
"predictable" and "unpredictable"?
On Wednesday, 19 September 2012 at 20:47, Ben Laurie wrote:
> Erring on the side of underestimation is wise here.
I agree wholeheartedly, but underestimation means "calculating the correct
value and then applying a safety factor" rather than "picking an arbitrary
number and hoping it's low eno
On Wed, Sep 19, 2012 at 09:29:23PM +0200, Pawel Jakub Dawidek wrote:
Here's how the distribution looks like for device_attach() times of my
sound card. The times were 26bit numbers, so this is after discarding
top ten bits, which leave us with 16 lower bits of pure entropy:)
http://people.freeb
On Wed, Sep 19, 2012 at 03:34:59PM -0700, David O'Brien (@FreeBSD) wrote:
> On Tue, Sep 18, 2012 at 11:14:22PM +0200, Pawel Jakub Dawidek wrote:
> > I experimented a bit with collecting entropy from the time it takes for
> > device_attach() to run (in CPU cycles). It seems that those times have
> >
On Wed, Sep 19, 2012 at 03:34:59PM -0700, David O'Brien (@FreeBSD) wrote:
> Index: sys/sys/random.h
> @@ -57,6 +58,7 @@ struct harvest_select {
> int point_to_point;
> int interrupt;
> int swi;
> + int device;
> };
Should be "int devprobe".
__
On Tue, Sep 18, 2012 at 11:14:22PM +0200, Pawel Jakub Dawidek wrote:
> I experimented a bit with collecting entropy from the time it takes for
> device_attach() to run (in CPU cycles). It seems that those times have
> enough variation that we can use it for entropy harvesting. It happens
> even bef
On Wed, 19 Sep 2012 22:53:32 +0200
Pawel Jakub Dawidek wrote:
> Here's how the distribution looks like for device_attach() times of my
> sound card. The times were 26bit numbers, so this is after discarding
> top ten bits, which leave us with 16 lower bits of pure entropy:)
>
> http://peop
On Wed, Sep 19, 2012 at 09:29:23PM +0200, Pawel Jakub Dawidek wrote:
> On Wed, Sep 19, 2012 at 07:30:52PM +0100, Jonathan Anderson wrote:
> > > If all the times are more or less equally probable in this range […]
> >
> > They're very unlikely to be equally probable. It would make sense to do
> >
On Wed, 19 Sep 2012 20:59:15 +0100
Ben Laurie wrote:
> On Wed, Sep 19, 2012 at 8:29 PM, Pawel Jakub Dawidek
> wrote:
> > On Wed, Sep 19, 2012 at 07:30:52PM +0100, Jonathan Anderson wrote:
> >> > If all the times are more or less equally probable in this range
> >> > […]
> >>
> >> They're very unl
On Wed, Sep 19, 2012 at 08:59:15PM +0100, Ben Laurie wrote:
> On Wed, Sep 19, 2012 at 8:29 PM, Pawel Jakub Dawidek wrote:
> > On Wed, Sep 19, 2012 at 07:30:52PM +0100, Jonathan Anderson wrote:
> >> > If all the times are more or less equally probable in this range […]
> >>
> >> They're very unlike
On Wed, Sep 19, 2012 at 8:29 PM, Pawel Jakub Dawidek wrote:
> On Wed, Sep 19, 2012 at 07:30:52PM +0100, Jonathan Anderson wrote:
>> > If all the times are more or less equally probable in this range […]
>>
>> They're very unlikely to be equally probable. It would make sense to do some
>> characte
On Wed, Sep 19, 2012 at 07:30:52PM +0100, Jonathan Anderson wrote:
> > If all the times are more or less equally probable in this range […]
>
> They're very unlikely to be equally probable. It would make sense to do some
> characterization of these times and their statistics: a highly non-uniform
On Wed, Sep 19, 2012 at 7:30 PM, Jonathan Anderson
wrote:
> On Tuesday, 18 September 2012 at 22:14, Pawel Jakub Dawidek wrote:
>> […] we have more
>> than 19 bits of entropy from this one call, but I reduced if to four
>> bits only, because there are devices that are much faster to attach.
>>
>
>
On Tuesday, 18 September 2012 at 22:14, Pawel Jakub Dawidek wrote:
> I experimented a bit with collecting entropy from the time it takes for
> device_attach() to run (in CPU cycles). It seems that those times have
> enough variation that we can use it for entropy harvesting. It happens
> even befor
On Tue, 18 Sep 2012 23:14:22 +0200
Pawel Jakub Dawidek wrote:
> Hi.
>
> The patch is here:
>
> http://people.freebsd.org/~pjd/patches/harvest_device_attach.patch
>
> Comments?
>
+ attachtime = get_cyclecount() - attachtime;
the above line is redundant since random_harvest() alre
On Wed, 19 Sep 2012 17:28:46 +0200
Dag-Erling Smørgrav wrote:
> I would also suggest modifying yarrow to block reseeding as long as
> possible, ideally right up until the first time something asks for a
> random number, since reseeding throws away all accumulated entropy.
reseeding doesn't thro
Pawel Jakub Dawidek writes:
> I experimented a bit with collecting entropy from the time it takes for
> device_attach() to run (in CPU cycles). It seems that those times have
> enough variation that we can use it for entropy harvesting. It happens
> even before root is mounted, so pretty early.
E
Hi.
I experimented a bit with collecting entropy from the time it takes for
device_attach() to run (in CPU cycles). It seems that those times have
enough variation that we can use it for entropy harvesting. It happens
even before root is mounted, so pretty early.
On the machine I'm testing it, wh
80 matches
Mail list logo
