A512_CTX SHA384_CTX;
>
>
> -/*** SHA-256/384/512 Function Prototypes **/
> -
> -void SHA256_Init(SHA256_CTX *);
> -void SHA256_Update(SHA256_CTX*, const u_int8_t*, size_t);
> -void SHA256_Final(u_int8_t[SHA256_DIGEST_LENGTH], SHA256_CTX*);
> -char* SHA256_End(SHA256_CTX*, char[SHA256_DIGEST_STRING_LENGTH]);
> -char* SHA256_Data(const u_int8_t*, size_t,
> char[SHA256_DIGEST_STRING_LENGTH]);
> +/*** SHA-384/512 Function Prototypes **/
>
> void SHA384_Init(SHA384_CTX*);
> void SHA384_Update(SHA384_CTX*, const u_int8_t*, size_t);
> @@ -137,4 +84,6 @@ char* SHA512_Data(const u_int8_t*, size_
> }
> #endif /* __cplusplus */
>
> +#include "sha256.h"
> +
> #endif /* __SHA2_H__ */
>
> Modified: head/sys/crypto/sha2/sha256.h
> ==
> --- head/sys/crypto/sha2/sha256.h Sun Mar 16 01:22:23 2014
> (r263217)
> +++ head/sys/crypto/sha2/sha256.h Sun Mar 16 01:43:23 2014
> (r263218)
> @@ -29,12 +29,14 @@
> #ifndef _SHA256_H_
> #define _SHA256_H_
>
> +#ifndef _KERNEL
> #include
> +#endif
>
> typedef struct SHA256Context {
> uint32_t state[8];
> uint64_t count;
> - unsigned char buf[64];
> + uint8_t buf[64];
> } SHA256_CTX;
>
> __BEGIN_DECLS
> @@ -42,9 +44,11 @@ void SHA256_Init(SHA256_CTX *);
> void SHA256_Update(SHA256_CTX *, const void *, size_t);
> void SHA256_Final(unsigned char [32], SHA256_CTX *);
> char *SHA256_End(SHA256_CTX *, char *);
> +char *SHA256_Data(const void *, unsigned int, char *);
> +#ifndef _KERNEL
> char *SHA256_File(const char *, char *);
> char *SHA256_FileChunk(const char *, char *, off_t, off_t);
> -char *SHA256_Data(const void *, unsigned int, char *);
> +#endif
> __END_DECLS
>
> #endif /* !_SHA256_H_ */
>
> Modified: head/sys/crypto/sha2/sha256c.c
> ==
> --- head/sys/crypto/sha2/sha256c.cSun Mar 16 01:22:23 2014
> (r263217)
> +++ head/sys/crypto/sha2/sha256c.cSun Mar 16 01:43:23 2014
> (r263218)
> @@ -30,7 +30,11 @@ __FBSDID("$FreeBSD$");
> #include
> #include
>
> +#ifdef _KERNEL
> +#include
> +#else
> #include
> +#endif
>
> #include "sha256.h"
>
>
--
Mark R V Murray
signature.asc
Description: Message signed with OpenPGP using GPGMail
To many things would break if sha256 was really
> removed…
Oops! Thanks! *blush*
M
--
Mark R V Murray
signature.asc
Description: Message signed with OpenPGP using GPGMail
esumption that since we had discussed it in person that
this would be OK, so my fault.
I'd prefer not to churn by backing out, but will do so if needed.
M
--
Mark R V Murray
signature.asc
Description: Message signed with OpenPGP using GPGMail
confirmed r255361 does not exhibit the boot failure.
I can't find that thread :-(
M
--
Mark R V Murray
signature.asc
Description: Message signed with OpenPGP using GPGMail
On 7 Sep 2013, at 18:20, Dag-Erling Smørgrav wrote:
> Mark R V Murray writes:
>> Dag-Erling Smørgrav writes:
>>> Umm, this should have been submitted to secteam@ for review.
>> I made the presumption that since we had discussed it in person that
>> this wou
;ll do that.
> So, this is a provisional OK from my part. *However*, I did not review
> the new harvesting queue in detail, and a bug there could, in the worst
> case, result in all the harvested entropy being discarded and Yarrow
> receiving kilobyte upon kilobyte of zeroes; so I'd like to get a second
> opinion.
Of course!
M
--
Mark R V Murray
signature.asc
Description: Message signed with OpenPGP using GPGMail
On 12 Oct 2013, at 17:27, Adrian Chadd wrote:
> hihi,
>
> I've just test booted this on a MIPS board. It doesn't hang at boot waiting
> for entropy.
>
> http://people.freebsd.org/~adrian/mips/20131012-ar9344-boot-1.txt
>
> Thanks!
You are mo
ang. I think DES's patch will help there too (not that
> anyone
> testing our ZFS patches reported any hangs... including when testing GELI --
> this was
> before DES's patch).
urandom is a symlink to random.
M
--
Mark R V Murray
signature.asc
Description: Message signed with OpenPGP using GPGMail
talled box even if using random(4)
> for
> apache? (it wants to default to /dev/random anyways)
Yup! No worse than usual.
M
--
Mark R V Murray
signature.asc
Description: Message signed with OpenPGP using GPGMail
On 12 Oct 2013, at 17:49, "Teske, Devin" wrote:
> Doubly-thanks!
Glad to be useful.
M
--
Mark R V Murray
signature.asc
Description: Message signed with OpenPGP using GPGMail
On 13 Oct 2013, at 01:07, Ian Lepore wrote:
> It looks like the cause of the problem is that both the dummy and the
> yarrow generators register, dummy first, and so it gets chosen even
> though yarrow is available.
Correct diagnosis!
This is now fixed; sorry for the hassle.
M
--
t of the kernel, so
> cannot provide the patch.
Ah - I know what is going on here. Fix coming, thanks!
M
--
Mark R V Murray
signature.asc
Description: Message signed with OpenPGP using GPGMail
y)
@@ -10,7 +10,8 @@
SRCS+= nehemiah.c
SRCS+= ivy.c
.endif
-SRCS+= randomdev_soft.c yarrow.c hash.c
+SRCS+= randomdev_soft.c random_harvestq.c live_entropy_sources.c
+SRCS+= yarrow.c hash.c rwfile.c
SRCS+= rijndael-alg-fst.c rijndael-api-fst.c sha2.c
SRCS+= bus_if.h device_if.h vnode_if.h opt_cpu.h opt_random.h
M
--
Mark R V Murray
signature.asc
Description: Message signed with OpenPGP using GPGMail
from the kernel is making so@
very uncomfortable, and there is too much scope for error there.
We'll settle it down properly in 11.*.
M
--
Mark R V Murray
signature.asc
Description: Message signed with OpenPGP using GPGMail
On 13 Oct 2013, at 17:18, Ian Lepore wrote:
> On Sun, 2013-10-13 at 16:18 +0100, Mark R V Murray wrote:
>> On 13 Oct 2013, at 16:13, Konstantin Belousov wrote:
>>> Surely this works, thank you. The rwfile.c content probably should be
>>> taken under the #ifdef RANDOM
On 13 Oct 2013, at 19:08, Adrian Chadd wrote:
> Hi Mark,
>
> Can we make the VFS random seeding stuff a compile time option, so we can
> disable it for the embedded platforms where we'll never use it?
Like 'options RANDOM_RWFILE'?
M
--
Mark R V Murray
signatu
are at least 12 bytes of it, so the semantic fix isn't backwards or a
>> buffer overrun.
>>
>
>
> Mark - did you initially mean the address of the mbuf m_data pointer,
> or the data payload itself?
As Bruce says - the address of payload data itself. We don’t have 12-byte
pointers in FreeBSD. :-)
M
--
Mark R V Murray
signature.asc
Description: Message signed with OpenPGP using GPGMail
On 2 Nov 2013, at 09:32, Mark R V Murray wrote:
>> Mark - did you initially mean the address of the mbuf m_data pointer,
>> or the data payload itself?
>
> As Bruce says - the address of payload data itself. We don’t have 12-byte
> pointers in FreeBSD. :-)
Cancel that
On 2 Nov 2013, at 22:28, Bruce Evans wrote:
> On Sat, 2 Nov 2013, Mark R V Murray wrote:
>
>> On 2 Nov 2013, at 09:32, Mark R V Murray wrote:
>>>> Mark - did you initially mean the address of the mbuf m_data pointer,
>>>> or the data payload itself?
>
On 30 May 2014, at 09:42, Michael Tuexen wrote:
> On 29 May 2014, at 21:21, Mark R V Murray wrote:
>
>>
>> On 29 May 2014, at 19:27, Michael Tuexen wrote:
>>
>>> On 29 May 2014, at 20:15, Mark R V Murray wrote:
>>>
>>>>
k cycle?
Definitely not! The value is in the low bits; wrap is of little consequence.
M
--
Mark R V Murray
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
he register. When running it on a
> kernel
> not defining _PMC_USER_READ_WRITE_, I get a core with Illegal instruction.
No. That only enables _write_ access. That’s on ARMv7. What’s in ARMv6 may also
work.
> Let me build a kernel with the above define and retest.
Pleas
On 16 Jun 2014, at 20:38, Michael Tuexen wrote:
> Hmm, the documentation reads
Which docs are you using?
I’m using DDI0360F. (And that could easily be a wrong choice).
M
--
Mark R V Murray
___
svn-src-all@freebsd.org mailing list
h
likely follow up and exclude the
architectures that are unproven.
M
On 17 Jun 2014, at 10:52, Michael Tuexen wrote:
> On 16 Jun 2014, at 22:13, Mark R V Murray wrote:
> Hi Mark,
>
> I just adopted the comments to the code change. So here is the improved patch:
>
>
his
slightly! (It won’t be for a week or two).
M
--
Mark R V Murray
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
> On 31 Oct 2014, at 14:22, Dag-Erling Smørgrav wrote:
>
> Andrey Chernov writes:
>> Mark Murray writes:
>>> Deleted:
>>> head/etc/rc.d/initrandom
>> It should be added to ObsoleteFiles.inc
>
> Good catch, fixe
ork and
> persistence!
Thank you!
>> Reviewed by:trasz,des(partial),imp(partial?),rwatson(partial?)
>
> Must... resist... tentation to make a joke about "imp(partial?)"…
*snigger* :-)
M
--
Mark R V Murray
___
svn
nt@ for more details:
> https://lists.freebsd.org/pipermail/freebsd-current/2014-October/053039.html
Will do. Thanks for the reminder.
> This also should have had “Relnotes: yes” in the commit message because this
> deserves to be put in the release notes for 11.0
Oops. :-(
like it's not getting enough entropy now?
>>
>>
>>
>> -adrian
>>
>
> Me too, on amd64 box. The machine gets hung for several minutes after
> 'writing entropy file' until random is unblocked. Anecdotally, banging
> on the keyboard trying to
eed progress
options RANDOM_FORTUNA # Use the Fortuna CSPRNG
--
Mark R V Murray
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
feed_dev_random "${entropy_dir}"/*
> fi
> ;;
> esac
>
> - case ${entropy_file} in
> + case ${entropy_file:=/entropy} in
> [Nn][Oo] | '')
> ;;
> *)
> - if [
immediately before kick_init.
>
> Approved by: so (self)
Not discussed with: markm(author)
M
--
Mark R V Murray
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
ev/random/yarrow.c
> ==
> --- head/sys/dev/random/yarrow.c Sun Nov 2 01:47:27 2014
> (r273957)
> +++ head/sys/dev/random/yarrow.c Sun Nov 2 02:01:55 20
> On 2 Nov 2014, at 09:59, Andrey Chernov wrote:
>
> On 02.11.2014 12:45, Mark R V Murray wrote:
>> Hi DES,
>>
>> I’m scared witless of this being on-by-default, for the reason given in the
>> removed comment. I’d much prefer to see it only turned on if a
e kernel options.
Compiling both into the kernel is possible, but tricky, so I didn’t do it
this time round. The reason for the trickiness is that randomdev_soft.c gets
compiled for each hash (Yarrow, Fortuna) with hash-specific #defines set.
Not insoluble, but I just didn’t get to it.
I’ll fix the
> On 2 Nov 2014, at 12:41, Dag-Erling Smørgrav wrote:
>
> Mark R V Murray writes:
>> I’m scared witless of this being on-by-default, for the reason given
>> in the removed comment. I’d much prefer to see it only turned on if a
>> kernel option is set, and the emb
> On 2 Nov 2014, at 12:42, Dag-Erling Smørgrav wrote:
>
> Mark R V Murray writes:
>> DES’s change makes no difference in a Tier-1 platform, except
>> potentially hiding a security problem.
>
> I will assume that you did not read the discussion that lead up to my
&g
> On 2 Nov 2014, at 13:22, Ian Lepore wrote:
>
> On Sun, 2014-11-02 at 09:45 +0000, Mark R V Murray wrote:
>> Hi DES,
>>
>> I´m scared witless of this being on-by-default, for the reason given in the
>> removed comment. I´d much prefer to see it only turned
> On 2 Nov 2014, at 19:07, Adrian Chadd wrote:
>
> On 2 November 2014 05:08, Mark R V Murray wrote:
>>
>>> On 2 Nov 2014, at 12:51, Dag-Erling Smørgrav wrote:
>>>
>>> Jan Beich writes:
>>>> I have a minimalistic kernel where everything
the signal catch, is dropped. Also,
> unbound sleep does not drop random_adaptor_lock, which means that
> you cannot module which could provide some more randomness for you,
> while any thread is stuck in read loop.
Hi
I don’t quite follow what you
le
> is loaded while thread is blocked, module cannot register, while
> reading thread cannot make progress.
I’m sorry, I don’t understand this.
M
--
Mark R V Murray
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
RqTNAt9T8F
> 7f5bGvcMHfkIOQIUanxlganUW2ZgVaDPYQADjrEsfqD2pTwwK7glN0jXKJ9YStGW
> kzbjAQil9X/fliVSzPubbO0XTqAtjnPwONBbjw06vlrwZlkHbLOTz0VVZ3cAJcei
> 4CkCiEQtuFWbD9QVCUe6snztRRTI542dIlWSDPhSxYV3+hrkCgCeJ3fMvTutf7YZ
> ejIPZ/NOkhddVmvjMHKw
> =XrYs
> -END PGP SIGNATURE-
>
itably-endowed ARMs a register similar to the x86 TSC register.
>>
>
> Hi,
>
> Regression issue:
> This commit prevents RPI-B from booting.
Thanks, I’ll look at it ASAP.
M
--
Mark R V Murray
___
svn-src-all@freebsd.org mai
On 29 May 2014, at 12:05, Hans Petter Selasky wrote:
> On 05/22/14 09:09, Mark R V Murray wrote:
>>
>> On 21 May 2014, at 21:15, Hans Petter Selasky wrote:
>>
>>> On 05/14/14 21:11, Mark Murray wrote:
>>>> Author: markm
>>>> Date: Wed M
s the problem; too many #ifdefs.
M
--
Mark R V Murray
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
On 29 May 2014, at 19:27, Michael Tuexen wrote:
> On 29 May 2014, at 20:15, Mark R V Murray wrote:
>
>>
>> On 29 May 2014, at 19:13, Michael Tuexen wrote:
>>
>>>> I can make it work on RPI, but trying to find what else it will/won’t work
>>
;> that's the trouble with randomness, you can't really tell..
>> I remember a part of a paper on the topic by Adams S, et al.
>> I think it was towards the end of the paper.
>
> I stand corrected... the number selected in the paper was 9
Well spotted!
Before someone m
policy”, there is SOME level of protection
that you must allow for to prevent completely idiotic admins to foul things up!
> Opinions?
“Pah!”?
M
--
Mark R V Murray
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-s
m_init_func_t(void);
> typedef void random_deinit_func_t(void);
>
> void randomdev_init_harvester(void (*)(const void *, u_int, u_int, enum
> random_entropy_source));
> -void randomdev_init_reader(u_int (*)(uint8_t *, u_int));
> +void randomdev_init_reader(void (*)(uint8_t *, u_int));
> void randomdev_deinit_harvester(void);
> void randomdev_deinit_reader(void);
>
> /* Stub/fake routines for when no entropy processor is loaded */
> -extern u_int dummy_random_read_phony(uint8_t *, u_int);
> +extern void dummy_random_read_phony(uint8_t *, u_int);
>
> /* kern.random sysctls */
> #ifdef SYSCTL_DECL/* from sysctl.h */
>
--
Mark R V Murray
signature.asc
Description: Message signed with OpenPGP using GPGMail
:07:47
> 2016 (r303035)
> @@ -10,6 +10,7 @@ arm/broadcom/bcm2835/bcm2835_gpio.c opt
> arm/broadcom/bcm2835/bcm2835_intr.c standard
> arm/broadcom/bcm2835/bcm2835_machdep.cstandard
> arm/broadcom/bcm2835/bcm2835_mbox.c standard
> +arm/broadcom/bcm2835/bcm2835_rng.c optional random
> arm/broadcom/bcm2835/bcm2835_sdhci.c optional sdhci
> arm/broadcom/bcm2835/bcm2835_spi.coptional bcm2835_spi
> arm/broadcom/bcm2835/bcm2835_vcio.c standard
>
> Modified: head/sys/boot/fdt/dts/arm/bcm2835.dtsi
> ==
> --- head/sys/boot/fdt/dts/arm/bcm2835.dtsiTue Jul 19 18:05:25 2016
> (r303034)
> +++ head/sys/boot/fdt/dts/arm/bcm2835.dtsiTue Jul 19 18:07:47 2016
> (r303035)
> @@ -396,6 +396,14 @@
> };
> };
>
> + rng {
> + compatible = "broadcom,bcm2835-rng",
> + "broadcom,bcm2708-rng";
> + reg = <0x104000 0x20>;
> + interrupts = <69>;
> + interrupt-parent = <&intc>;
> + };
> +
> bsc0 {
> #address-cells = <1>;
> #size-cells = <0>;
>
> Modified: head/sys/boot/fdt/dts/arm/bcm2836.dtsi
> ==
> --- head/sys/boot/fdt/dts/arm/bcm2836.dtsiTue Jul 19 18:05:25 2016
> (r303034)
> +++ head/sys/boot/fdt/dts/arm/bcm2836.dtsiTue Jul 19 18:07:47 2016
> (r303035)
> @@ -389,6 +389,14 @@
> };
> };
>
> + rng {
> + compatible = "broadcom,bcm2835-rng",
> + "broadcom,bcm2708-rng";
> + reg = <0x104000 0x20>;
> + interrupts = <69>;
> + interrupt-parent = <&intc>;
> + };
> +
> bsc0 {
> #address-cells = <1>;
> #size-cells = <0>;
>
> Modified: head/sys/sys/random.h
> ==
> --- head/sys/sys/random.h Tue Jul 19 18:05:25 2016(r303034)
> +++ head/sys/sys/random.h Tue Jul 19 18:07:47 2016(r303035)
> @@ -90,6 +90,7 @@ enum random_entropy_source {
> RANDOM_PURE_NEHEMIAH,
> RANDOM_PURE_RNDTEST,
> RANDOM_PURE_VIRTIO,
> + RANDOM_PURE_BROADCOM,
> ENTROPYSOURCE
> };
>
>
--
Mark R V Murray
signature.asc
Description: Message signed with OpenPGP using GPGMail
> On 20 Oct 2018, at 22:09, Conrad Meyer wrote:
>
> Author: cem
> Date: Sat Oct 20 21:09:12 2018
> New Revision: 339492
> URL: https://svnweb.freebsd.org/changeset/base/339492
>
> Log:
> Fortuna: ...
... and a few others.
Thanks, Conrad, for picking these up! Having code reviewed well is
ity.
> Whether we agree with NIST's ideas about how randomness should be
> handled or not, we need to to be able to comply and we do not want to
> burn their desired arrangement into our kernels.
Sound like you just need to be able to select
> On 2 Jul 2015, at 19:36, Simon J. Gerraty wrote:
>
> Mark R V Murray wrote:
>>>> - Remove; plugability is no longer used. Compile-time algorithm
>>>> selection is the way to go.
>>>
>>> Errr we use that and need it.
>>> Please
adaptor (Fortuna I guess).
No problem!
Could you please let me know your implementation’s API? If I have that,
or at least an approximation, I can make a framework in which you can
insert your code.
> We do not need ability to switch adaptors at run-time.
Excellen
> On 2 Jul 2015, at 19:55, Simon J. Gerraty wrote:
>
> Mark R V Murray 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 gue
> On 2 Jul 2015, at 20:28, Arthur Mesh 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
&
>> Address review.
>
> This commit message sucks...
>
>> Differential Revision: https://reviews.freebsd.org/D2924
>>
>
> --
> Andriy Gapon
>
--
Mark R V Murray
___
svn-src-all@freebsd.org mailing list
ht
gt; > or DUMMY, they ask for it, otherwise they get FORTUNA.
>
> I started getting kernel panics on boot after this commit.
> Can you look at this:
>
> https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests/1177/console
> <https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests/1177/c
> On 13 Jul 2015, at 08:40, Mark R V Murray wrote:
>
>> I started getting kernel panics on boot after this commit.
>> Can you look at this:
>>
>> https://jenkins.freebsd.org/job/FreeBSD_HEAD-tests/1177/console
>> <https://jenkins.freebsd.org/job/Free
over 80 columns).
Yes - this is overly conservative ;-)
I’ve done a further tightening up, but I want to let it settle and not
churn the code.
M
--
Mark R V Murray
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
they are off.
See ‘sysctl kern.random.harvest.mask_symbolic’ and note that the
disabled sources are in [].
I have yet to do a full set of benchmarks, but I have discussed
this with RWatson. A silly benchmark (make world) shows little
effect, but I will be doing this properly in coming months.
In an
ally?
> The "WHAT" column of w(1) is already pretty narrow.
No. This column is statically sized.
The “what" column” prints arbitrary length lines. I’ve hardly ever
seen anything long in practice though.
M
--
Mark R V Murray
___
svn-src
den the host field so that a full IPv6 address will be seen.
>
> Relnotes: yes!
Damn you! ;-)
I’ve just had to install the kitchen sink to do this!
(The building is a bit out of date; the optional ports
don’t exist, and installing textproc/fpo resulted in a
tool that did not make a readab
do MFC this back to
> stable/10.
I’m not yet planning an MFC to 10.x
> -adrian
M
—
Mark R V Murray
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
On 17 Jul 2015, at 23:14, K. Macy wrote:
>
> On Fri, Jul 17, 2015 at 3:01 PM, Mark R V Murray wrote:
>>
>>> On 17 Jul 2015, at 22:39, K. Macy wrote:
>>> Like I said, the linking issue isn't a concern. My problem is that
>>> it's not bootin
It would be nice to keep
> the style at least for the files where you added random harvesting and which
> are already mostly style compliant. E.g., what about wrapping lines at
> position somewhere between 72 and 80 ?
I’ll look, thanks!
M
--
Mark R V Murray
> On 19 Jul 2015, at 20:40, Simon J. Gerraty wrote:
>
> Mark R V Murray 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
at each
UMA harvesting opportunity, and no further action. I asked Robert Watson if
this was burdensome, and he said it was not.
I’m willing to discuss optimising this, and have plans for some
micro-benchmarks.
M
--
Mark R V Murray
PS: Please trim mail when responding - was it necessary
e into
>> over time.
>
> A certain video streaming company will be pushing the envelope to get to
> 100Gbps very soon. Even a few extra instructions on every packet / allocation
> will be a killer. Especially if one is an almost guaranteed cache mi
s that would
> be more difficult to game, especially if the counter was cycled irregularly.
Help requested here, please! If you could point out suitable harvesting points,
I’ll see if the numbers from them look good.
Thanks!
M
--
Mark R V Murray
_
have declared
our distrust in single sources (thanks Snowden!). Thus it is good to mix as
much as possible. Now your requirements may not be as strong as the next
fellow’s so disabling some sources would be a reasonable idea.
I trust this direction will work better for more folks?
M
--
Mark R
rivate API to get a clue about current
> entropy status?
Sort of. By turning on the RANDOM_DEBUG option, Fortuna will periodically
print out the “message lengths” of all 32 accumulation pools. These are
very vaguely indicative of the accumulated entropy. Pool[0] is used for
reseeding; the rest are
ay be a useful way
of enabling/disabling (say) UMA gathering on the fly.
> 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.
M
--
> On 24 Jul 2015, at 16:25, Ian Lepore 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
s is the professional mistrust
of crypto, not an assertion of incompetence or malice. ;-) They do,
however, fulfil a need, but I don’t like the idea of trusting a single
source unless that source has been properly vetted.
M
--
Mark R V Murray
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
r at least to turn
off all harvesting after a certain time and never turn it on again?
If so, we are pretty far apart philosophically.
DJB’s position is interesting, but I am far from persuaded by it.
M
--
Mark R V Murray
___
svn-src-all@freebsd.org
> On 25 Jul 2015, at 17:05, Scott Long 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
--
earch this more carefully. Ask Ian Lepore about the
paucity of entropy on his boxes.
M
--
Mark R V Murray
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
> On 25 Jul 2015, at 18:46, John-Mark Gurney 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 wrote:
>>>
>>> Once you have enough useful bits in /dev/random, you can NEVER
be patient for a few more days.
Thanks!
M
--
Mark R V Murray
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
I strip out the module bits in order to get my arc4random(9)
commit completed?
M
--
Mark R V Murray
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
==
> --- head/sys/dev/random/random_harvestq.c Sun Apr 16 09:00:10 2017
> (r317014)
> +++ head/sys/dev/random/random_harvestq.c Sun Apr 16 09:11:02 2017
> (r317015)
> @@ -352,10 +352,19 @@ random_harvestq_prime(void *unused __unu
>* Get entropy that may have been pre
h an
> error return.
Error return is out of the question; arc4random() is pretty fundamental.
The alternative is to return no or fake random numbers, which rather
misses the point of what this is for. But it can be done.
M
--
Mark R V Murray
___
n.
>>
>> Error return is out of the question; arc4random() is pretty fundamental.
>> The alternative is to return no or fake random numbers, which rather
>> misses the point of what this is for. But it can be done.
>
> Arc4random works today without chacha, why would ad
s wrong with doing that as a next step? Why does this
change need to be held to ransom?
>> Up until now, arc4random worked with unconditional RC4.
>
> And your wanting to just replace unconditional RC4 for unconditional chacha?
> Or actuall, aleady did?
Correct. Both counts. It was
d to been aware of early and added into that project, but
> overall
> I think we need to work on this communcations too.
True. I promised SO@ that I would get all my CSPRNG stuff reviewed in
Phabricator
before committing it. All the folks who in the past have cared about my work now
are on the
Phabricator
because
it works for me (I get reviews). I was largely ignored on the mailing lists
last time
I had a big commit.
M
--
Mark R V Murray
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
an undue burden.
> Especially balanced by kicking out RC4.
This is the way I'd like to see things go.
> Thanks for doing this work.
You are most welcome!
M
--
Mark R V Murray
___
svn-src-all@freebsd.org mailing list
https://lists.fr
a version that
includes test vectors and runs self-tests when loaded, but I removed
them from the final version as they are about six times larger than
the actual code."
DES - are you kidding me??! 2 hours 9 minutes warning? I already had
a green light; I wan't watching Phabricator,
bus_if.h device_if.h vnode_if.h opt_kstack_pages.h
> +SRCS=bus_if.h device_if.h vnode_if.h opt_kstack_pages.h opt_random.h
>
> SUNW= ${SYSDIR}/cddl/contrib/opensolaris
>
>
--
Mark R V Murray
___
svn-src-all@freebsd.org mailing list
gression test to ensure at this problem
is not elsewhere and doesn’t return.
Where do folks put these? I don’t mind writing one.
M
--
Mark R V Murray
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubsc
91 matches
Mail list logo
