> 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
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,
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-head@freebsd.org mailing list
https://lists.fre
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-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
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
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 up
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
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
___
svn
==
> --- 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
I strip out the module bits in order to get my arc4random(9)
commit completed?
M
--
Mark R V Murray
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
: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
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-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubsc
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-head@freebsd.org mailing
be patient for a few more days.
Thanks!
M
--
Mark R V Murray
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-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
earch this more carefully. Ask Ian Lepore about the
paucity of entropy on his boxes.
M
--
Mark R V Murray
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "s
> 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
--
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-head@freebsd.org
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-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
> 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
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
--
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
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 V
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
__
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
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
> 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
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 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
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-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
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
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-
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 ans
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-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
> 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
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
>> Address review.
>
> This commit message sucks...
>
>> Differential Revision: https://reviews.freebsd.org/D2924
>>
>
> --
> Andriy Gapon
>
--
Mark R V Murray
___
svn-src-head@freebsd.org mailing list
htt
> 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
&
> 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
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: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
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
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-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn
;> 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
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
RqTNAt9T8F
> 7f5bGvcMHfkIOQIUanxlganUW2ZgVaDPYQADjrEsfqD2pTwwK7glN0jXKJ9YStGW
> kzbjAQil9X/fliVSzPubbO0XTqAtjnPwONBbjw06vlrwZlkHbLOTz0VVZ3cAJcei
> 4CkCiEQtuFWbD9QVCUe6snztRRTI542dIlWSDPhSxYV3+hrkCgCeJ3fMvTutf7YZ
> ejIPZ/NOkhddVmvjMHKw
> =XrYs
> -END PGP SIGNATURE-
>
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-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
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
> 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
> 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 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 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
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 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
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
immediately before kick_init.
>
> Approved by: so (self)
Not discussed with: markm(author)
M
--
Mark R V Murray
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, sen
feed_dev_random "${entropy_dir}"/*
> fi
> ;;
> esac
>
> - case ${entropy_file} in
> + case ${entropy_file:=/entropy} in
> [Nn][Oo] | '')
> ;;
> *)
> - if [
eed progress
options RANDOM_FORTUNA # Use the Fortuna CSPRNG
--
Mark R V Murray
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
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
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. :-(
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-
> 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
his
slightly! (It won’t be for a week or two).
M
--
Mark R V Murray
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
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:
>
>
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-head@freebsd.org mailing list
h
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
k cycle?
Definitely not! The value is in the low bits; wrap is of little consequence.
M
--
Mark R V Murray
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
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:
>>>
>>>>
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
>>
s the problem; too many #ifdefs.
M
--
Mark R V Murray
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
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
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-head@freebsd.org mail
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
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
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 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
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 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
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
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
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
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
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
--
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
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
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
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
;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 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
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
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
91 matches
Mail list logo
