On 2 Jul 2015, at 00:07, Simon J. Gerraty s...@juniper.net wrote:
Mark Murray ma...@freebsd.org wrote:
* src/sys/dev/random/random_adaptors.c src/sys/dev/random/random_adaptors.h
- Remove; plugability is no longer used. Compile-time algorithm
selection is the way to go.
Errr we use
On Sat, Jul 25, 2015 at 10:30:55AM -0700, John-Mark Gurney wrote:
Alexey Dokuchaev wrote this message on Sat, Jul 25, 2015 at 14:36 +:
On Fri, Jul 24, 2015 at 07:59:35AM +0100, Mark R V Murray wrote:
[...]
Heck, piping in mic data to /dev/random is a good way to seed the
rng on
kpn...@pobox.com wrote this message on Sun, Jul 26, 2015 at 18:51 -0400:
Microphones don???t typically exist on virtual machines, servers,
appliances/embedded gadgets, and trusted computers. Nice idea for the
desktop, but far from universal.
Personally, I _hate_ the idea of having a
On 25 Jul 2015, at 07:26, John-Mark Gurney j...@funkthat.com wrote:
Once you have enough useful bits in /dev/random, you can NEVER run out
of useful bits from /dev/random...
[Well, not quite NEVER, but not for a few millennia.]
So is your position effectively anti-harvesting, or at
On 25 Jul 2015, at 06:06, Scott Long scott4l...@yahoo.com wrote:
I’m working on a premise of “tools, not policy”. I’d like there to be
enough harvesting points for the box owner to get the warm fuzzies.
If they choose to use less, fine by me.
Sure, and that’s not an unreasonable goal,
On Jul 25, 2015, at 8:36 AM, Alexey Dokuchaev da...@freebsd.org wrote:
On Fri, Jul 24, 2015 at 07:59:35AM +0100, Mark R V Murray wrote:
[...]
Heck, piping in mic data to /dev/random is a good way to seed the
rng on many machines.
Well, sure, but what if you don't have microphone? I want
On Fri, Jul 24, 2015 at 07:59:35AM +0100, Mark R V Murray wrote:
[...]
Heck, piping in mic data to /dev/random is a good way to seed the
rng on many machines.
Well, sure, but what if you don't have microphone? I want lots
of choices, in anticipation of only a subset being usable.
I like
On 25 Jul 2015, at 17:05, Scott Long scott4l...@yahoo.com wrote:
What you posted this morning for review is a great start. Thanks for the
productive conversation on this.
:-)
I will do the same/similar for networking and for file ATIME mods.
What else causes grief for you?
M
--
Mark
Alexey Dokuchaev wrote this message on Sat, Jul 25, 2015 at 14:36 +:
On Fri, Jul 24, 2015 at 07:59:35AM +0100, Mark R V Murray wrote:
[...]
Heck, piping in mic data to /dev/random is a good way to seed the
rng on many machines.
Well, sure, but what if you don't have microphone? I
Mark R V Murray wrote this message on Sat, Jul 25, 2015 at 09:22 +0100:
On 25 Jul 2015, at 07:26, John-Mark Gurney j...@funkthat.com wrote:
Once you have enough useful bits in /dev/random, you can NEVER run out
of useful bits from /dev/random...
[Well, not quite NEVER, but not for a
Mark R V Murray wrote this message on Fri, Jul 24, 2015 at 07:59 +0100:
On 24 Jul 2015, at 02:25, John-Mark Gurney j...@funkthat.com wrote:
I would like to point out that the goal of collecting large amounts
is starting to fall out of favor, and I happen to agree with the likes
of
Scott Long wrote this message on Fri, Jul 24, 2015 at 23:06 -0600:
On Jul 24, 2015, at 12:59 AM, Mark R V Murray ma...@freebsd.org wrote:
On 24 Jul 2015, at 02:25, John-Mark Gurney j...@funkthat.com wrote:
Heck, piping in mic data to /dev/random is a good way to seed the
rng on
On Jul 25, 2015, at 2:10 AM, Mark R V Murray ma...@freebsd.org wrote:
On 25 Jul 2015, at 06:06, Scott Long scott4l...@yahoo.com wrote:
I’m working on a premise of “tools, not policy”. I’d like there to be
enough harvesting points for the box owner to get the warm fuzzies.
If they
On 25 Jul 2015, at 18:46, John-Mark Gurney j...@funkthat.com wrote:
Mark R V Murray wrote this message on Sat, Jul 25, 2015 at 09:22 +0100:
On 25 Jul 2015, at 07:26, John-Mark Gurney j...@funkthat.com wrote:
Once you have enough useful bits in /dev/random, you can NEVER run out
of useful
Scott Long wrote this message on Sat, Jul 25, 2015 at 10:04 -0600:
On Jul 25, 2015, at 8:36 AM, Alexey Dokuchaev da...@freebsd.org wrote:
On Fri, Jul 24, 2015 at 07:59:35AM +0100, Mark R V Murray wrote:
[...]
Heck, piping in mic data to /dev/random is a good way to seed the
rng on
Mark R V Murray wrote this message on Sat, Jul 25, 2015 at 20:24 +0100:
On 25 Jul 2015, at 19:31, John-Mark Gurney j...@funkthat.com wrote:
virtual machines have things like virtio_random, most embedded gadgets
have an ADC that could be used... Appliances a little more difficult,
but
On 25 Jul 2015, at 19:31, John-Mark Gurney j...@funkthat.com wrote:
virtual machines have things like virtio_random, most embedded gadgets
have an ADC that could be used... Appliances a little more difficult,
but trusted computers probably have a hardware RNG anyways…
You need to research
On 24 Jul 2015, at 02:25, John-Mark Gurney j...@funkthat.com wrote:
I would like to point out that the goal of collecting large amounts
is starting to fall out of favor, and I happen to agree with the likes
of djb[1] that we don't need an infinite amount of entropy collected by
the system.
On Fri, 2015-07-24 at 07:59 +0100, Mark R V Murray wrote:
On 24 Jul 2015, at 02:25, John-Mark Gurney j...@funkthat.com wrote:
I would like to point out that the goal of collecting large amounts
is starting to fall out of favor, and I happen to agree with the likes
of djb[1] that we
On 24 Jul 2015, at 16:25, Ian Lepore i...@freebsd.org wrote:
But keep in mind that loader(8) is optional and not used at all on some
non-x86 systems.
Duly noted. It’s on my TODO list to talk to you embedded folks about this.
M
--
Mark R V Murray
On Jul 24, 2015, at 12:59 AM, Mark R V Murray ma...@freebsd.org wrote:
On 24 Jul 2015, at 02:25, John-Mark Gurney j...@funkthat.com wrote:
I would like to point out that the goal of collecting large amounts
is starting to fall out of favor, and I happen to agree with the likes
of
On 23 Jul 2015, at 14:45, Scott Long scott4l...@yahoo.com wrote:
OK - I’m sold! I’ll make a kernel option defaulting to off. :-)
Hi Mark,
Thanks for making this concession. I wanted to add a bit of historical
perspective. When Yarrow was introduced in the previous decade, it was
On 23 Jul 2015, at 18:30, Alexey Dokuchaev da...@freebsd.org wrote:
[ Guys, please teach your MUA to wrap messages over 72-76 boundary and trim
excessive/irrelevant quoting, thank you. ]
Oops sorry!
So far it looks like this to me (having read no papers):
1) Fortuna attempts to get
Scott Long wrote this message on Thu, Jul 23, 2015 at 07:45 -0600:
On Jul 23, 2015, at 1:03 AM, Mark R V Murray ma...@freebsd.org wrote:
On 23 Jul 2015, at 00:53, Warner Losh i...@bsdimp.com wrote:
Neither filesystem operations nor allocations are random events. They
are
On Jul 23, 2015, at 1:03 AM, Mark R V Murray ma...@freebsd.org wrote:
On 23 Jul 2015, at 00:53, Warner Losh i...@bsdimp.com wrote:
Neither filesystem operations nor allocations are random events. They
are trivially influenced by user code. A malicious attacker could create
repeated
[ Guys, please teach your MUA to wrap messages over 72-76 boundary and trim
excessive/irrelevant quoting, thank you. ]
On Thu, Jul 23, 2015 at 07:45:14AM -0600, Scott Long via svn-src-all wrote:
On Jul 23, 2015, at 1:03 AM, Mark R V Murray ma...@freebsd.org wrote:
Fortuna was developed to
On 23 Jul 2015, at 00:53, Warner Losh i...@bsdimp.com wrote:
Neither filesystem operations nor allocations are random events. They are
trivially influenced by user code. A malicious attacker could create
repeated patterns of allocations or filesystem activity through the
syscall path
On 23 Jul 2015, at 08:59, Jeff Roberson jrober...@jroberson.net wrote:
OK - I?m sold! I?ll make a kernel option defaulting to off. :-)
There are other sources that occur less frequently than millions of times
per-second that may still provide some usefull entropy while being less
On Thu, 23 Jul 2015, Mark R V Murray wrote:
On 23 Jul 2015, at 00:53, Warner Losh i...@bsdimp.com wrote:
Neither filesystem operations nor allocations are random events. They are
trivially influenced by user code. A malicious attacker could create repeated
patterns of allocations or
On Tue, 30 Jun 2015, Mark Murray wrote:
Author: markm
Date: Tue Jun 30 17:00:45 2015
New Revision: 284959
URL: https://svnweb.freebsd.org/changeset/base/284959
Log:
Huge cleanup of random(4) code.
* GENERAL
- Update copyright.
- Make kernel options for RANDOM_YARROW and RANDOM_DUMMY. Set
On 22 Jul 2015, at 22:42, Jeff Roberson jrober...@jroberson.net wrote:
On Tue, 30 Jun 2015, Mark Murray wrote:
- Add harvesting of slab allocator events. This needs to be checked for
weighing down the allocator code.
Neither filesystem operations nor allocations are random events.
On Jul 22, 2015, at 4:53 PM, Jeff Roberson jrober...@jroberson.net wrote:
On Wed, 22 Jul 2015, Mark R V Murray wrote:
On 22 Jul 2015, at 22:42, Jeff Roberson jrober...@jroberson.net wrote:
On Tue, 30 Jun 2015, Mark Murray wrote:
- Add harvesting of slab allocator events. This needs
On Wed, 22 Jul 2015, Mark R V Murray wrote:
On 22 Jul 2015, at 22:42, Jeff Roberson jrober...@jroberson.net wrote:
On Tue, 30 Jun 2015, Mark Murray wrote:
- Add harvesting of slab allocator events. This needs to be checked for
weighing down the allocator code.
Neither filesystem
Mark R V Murray ma...@freebsd.org wrote:
On Thu, Jul 02, 2015 at 11:36:27AM -0700, Simon J. Gerraty wrote:
Sound like you just need to be able to select a single KLD at boot time?
Mark, do you have an estimate of when loadable modules will be supported
again?
We've been holding off sync'ing
Mark, do you have an estimate of when loadable modules will be supported
again?
About a week, I’d say.
Thanks! Will keep an eye out.
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe,
On 19 Jul 2015, at 20:40, Simon J. Gerraty s...@juniper.net wrote:
Mark R V Murray ma...@freebsd.org wrote:
On Thu, Jul 02, 2015 at 11:36:27AM -0700, Simon J. Gerraty wrote:
Sound like you just need to be able to select a single KLD at boot time?
Mark, do you have an estimate of when
CC’ing to original lists.
Kip’s problem has come to conclusion, and our final (private) email
is forwarded to the lists with permission.
It should be noted that Kip was importing CURRENT to a fork of
FreeBSD, and there was a potential merging problem that may have
caused a link failure.
M
On
On 17 Jul 2015, at 07:47, Adrian Chadd adrian.ch...@gmail.com wrote:
hi,
So I'll have to update the AP images that I build, as now I have to
add that sysctl to things.
Well, measure the effect. It may not be as bad as it may seem! :-)
It also means everyone has to update their /etc
hi,
So I'll have to update the AP images that I build, as now I have to
add that sysctl to things.
It also means everyone has to update their /etc after updating or
they'll end up with this particular mode not being disabled.
i think we need to get this better documented so people aren't bitten
On Thu, 2015-07-16 at 06:39 +0100, Mark Murray wrote:
On 15 Jul 2015, at 23:43, Adrian Chadd adrian.ch...@gmail.com wrote:
- Add harvesting of slab allocator events. This needs to be checked for
weighing down the allocator code.
Hi,
Is this really doing it upon every one of
On 16 Jul 2015, at 15:08, Ian Lepore i...@freebsd.org wrote:
On Thu, 2015-07-16 at 06:39 +0100, Mark Murray wrote:
On 15 Jul 2015, at 23:43, Adrian Chadd adrian.ch...@gmail.com wrote:
- Add harvesting of slab allocator events. This needs to be checked for
weighing down the allocator
On Thu, Jul 16, 2015 at 3:28 PM, K. Macy km...@freebsd.org wrote:
I discovered this when I MFC'd and my kernel wouldn't link because of
unresolved symbols. I thought I had put the issue aside when I added
RANDOM_DUMMY to my kernel config.
However, I just hit this:
while
I discovered this when I MFC'd and my kernel wouldn't link because of
unresolved symbols. I thought I had put the issue aside when I added
RANDOM_DUMMY to my kernel config.
However, I just hit this:
while (!random_alg_context.ra_seeded()) {
if (nonblock) {
On 15 Jul 2015, at 23:43, Adrian Chadd adrian.ch...@gmail.com wrote:
- Add harvesting of slab allocator events. This needs to be checked for
weighing down the allocator code.
Hi,
Is this really doing it upon every one of those events? eg, for each
mbuf alloc through UMA?
Only if
On 30 June 2015 at 10:00, Mark Murray ma...@freebsd.org wrote:
Author: markm
Date: Tue Jun 30 17:00:45 2015
New Revision: 284959
URL: https://svnweb.freebsd.org/changeset/base/284959
- Add harvesting of FFS atime events. This needs to be checked for
weighing down the FS code.
- Add
On 2 Jul 2015, at 00:07, Simon J. Gerraty s...@juniper.net wrote:
Mark Murray ma...@freebsd.org wrote:
* src/sys/dev/random/random_adaptors.c src/sys/dev/random/random_adaptors.h
- Remove; plugability is no longer used. Compile-time algorithm
selection is the way to go.
Errr we use
On 2 July 2015 at 12:17, Arthur Mesh am...@juniper.net wrote:
On Thu, Jul 02, 2015 at 12:13:54PM -0700, Adrian Chadd wrote:
Could we please get something like this implemented in upstream
FreeBSD? I'm sure a number of vendors would like to see a (not by
default) FIPS-140 random number
Mark R V Murray ma...@freebsd.org wrote:
- Remove; plugability is no longer used. Compile-time algorithm
selection is the way to go.
Errr we use that and need it.
Please put it back.
Do you really need full the plugability (including run-time selection
of algorithm), or do you
On Thu, Jul 02, 2015 at 11:36:27AM -0700, Simon J. Gerraty wrote:
Sound like you just need to be able to select a single KLD at boot time?
Quite possibly.
Will confirm...
Hello,
We need to be able to select a random adaptor at load time. I.e. loader
is the one selecting it based on
On 2 July 2015 at 11:55, Simon J. Gerraty s...@juniper.net wrote:
Mark R V Murray ma...@freebsd.org wrote:
If so, can I confirm that you may be rolling your own non-Yarrow/Fortuna
mixer(s)?
AFAIK no mixer allowed; just direct SP800-90 compliant HMAC-DRBG.
You can probably guess why we don't
On Thu, Jul 02, 2015 at 12:13:54PM -0700, Adrian Chadd wrote:
Could we please get something like this implemented in upstream
FreeBSD? I'm sure a number of vendors would like to see a (not by
default) FIPS-140 random number generator provided. It'd certainly be
a good check list item for
On 2 Jul 2015, at 20:28, Arthur Mesh am...@juniper.net wrote:
On Thu, Jul 02, 2015 at 08:21:31PM +0100, Mark R V Murray wrote:
I.e., if the box is configured to boot in FIPS mode, it should use NIST
SP800-90 HMAC-DRBG adaptor. Otherwise, it uses the default FreeBSD
adaptor (Fortuna I
On 2 Jul 2015, at 19:36, Simon J. Gerraty s...@juniper.net wrote:
Mark R V Murray ma...@freebsd.org wrote:
- Remove; plugability is no longer used. Compile-time algorithm
selection is the way to go.
Errr we use that and need it.
Please put it back.
Do you really need full the
Mark R V Murray ma...@freebsd.org wrote:
If so, can I confirm that you may be rolling your own non-Yarrow/Fortuna
mixer(s)?
AFAIK no mixer allowed; just direct SP800-90 compliant HMAC-DRBG.
You can probably guess why we don't agree that's a brilliant arrangement
but its not an argument we can
On 2 Jul 2015, at 19:42, Arthur Mesh am...@juniper.net wrote:
On Thu, Jul 02, 2015 at 11:36:27AM -0700, Simon J. Gerraty wrote:
Sound like you just need to be able to select a single KLD at boot time?
Quite possibly.
Will confirm...
Hello,
We need to be able to select a random
On 2 Jul 2015, at 19:55, Simon J. Gerraty s...@juniper.net wrote:
Mark R V Murray ma...@freebsd.org wrote:
If so, can I confirm that you may be rolling your own non-Yarrow/Fortuna
mixer(s)?
AFAIK no mixer allowed; just direct SP800-90 compliant HMAC-DRBG.
You can probably guess why we
On Thu, Jul 02, 2015 at 08:21:31PM +0100, Mark R V Murray wrote:
I.e., if the box is configured to boot in FIPS mode, it should use NIST
SP800-90 HMAC-DRBG adaptor. Otherwise, it uses the default FreeBSD
adaptor (Fortuna I guess).
No problem!
Could you please let me know your
Mark Murray ma...@freebsd.org wrote:
* src/sys/dev/random/random_adaptors.c src/sys/dev/random/random_adaptors.h
- Remove; plugability is no longer used. Compile-time algorithm
selection is the way to go.
Errr we use that and need it.
Please put it back.
Whether we agree with NIST's
58 matches
Mail list logo
