LibreSSL: GOST ciphers implementation
Hello, It took a while longer than I expected, but I think that the GOST ciphers implementation is complete now at https://github.com/libressl-portable/openbsd/pull/6 I still expect issues when Windows GOST CSP vendors will work on TLS 1.2 implementation (up to now they only provide TLS 1.0). However that will have to be fixed in future (when there will be at least one GOST + TLS 1.2 implementation). Could you please provide review, comments/ -- With best wishes Dmitry
Re: armv7: banana pi, Allwinner A20 board
On Thu, October 16, 2014 11:40 pm, Patrick Wildt wrote:
I do believe that this is a pmap issue.
I just got hands on an Allwinner A20 and suffered the same issues:
pool_setlowat crashing randomly, same for ahci and so on.
I believe we are not syncing the PTEs correctly.
Here?s the snippet from PTE_SYNC(), but PTE_SYNC_RANGE() has
the same issue:
#define PTE_SYNC(pte)
\
do { \
if (PMAP_NEEDS_PTE_SYNC) { \
paddr_t pa; \
cpu_drain_writebuf(); \
cpu_dcache_wb_range((vaddr_t)(pte), sizeof(pt_entry_t));\
if (cpu_sdcache_enabled()) {\
(void)pmap_extract(pmap_kernel(), (vaddr_t)(pte), pa); \
cpu_sdcache_wb_range((vaddr_t)(pte), (paddr_t)(pa), \
sizeof(pt_entry_t));\
}; \
cpu_drain_writebuf(); \
} \
} while (/*CONSTCOND*/0)
I believe that when we change things in the pagetables, we need to make
sure the tables are synced before we?re going to use them. In our case
we believe that we are using uncached pagetables, which means that
every write will directly hit the tables.
But that does not have an affect on the write buffer. The write buffer is
still
there and has to be cleared manually. If it isn?t, and something accesses
an area which was just mapped, then we?re fucked.
Therefore I firmly believe that the cpu_drain_writebuf() call has to be made
regardless of PMAP_NEEDS_PTE_SYNC and that it has to be called before
that if-clause.
Doing that fixes my issues.
\Patrick
I think this is correct. With the diff below, my A20 board doesn't panic
anymore.
I still get a lot of messages like the following though:
pmap_fault_fixup: va 8000 ftype 1 u pte 7f24f02e
Index: sys/arch/arm/include/pmap.h
===
RCS file: /cvs/src/sys/arch/arm/include/pmap.h,v
retrieving revision 1.27
diff -u -p -u -p -r1.27 pmap.h
--- sys/arch/arm/include/pmap.h 7 Oct 2014 10:10:58 - 1.27
+++ sys/arch/arm/include/pmap.h 20 Oct 2014 09:33:14 -
@@ -328,9 +328,9 @@ extern int pmap_needs_pte_sync;
#definePTE_SYNC(pte)
\
do { \
+ cpu_drain_writebuf(); \
if (PMAP_NEEDS_PTE_SYNC) { \
paddr_t pa; \
- cpu_drain_writebuf(); \
cpu_dcache_wb_range((vaddr_t)(pte), sizeof(pt_entry_t));\
if (cpu_sdcache_enabled()) {\
(void)pmap_extract(pmap_kernel(), (vaddr_t)(pte), pa); \
@@ -343,9 +343,9 @@ do {
\
#definePTE_SYNC_RANGE(pte, cnt)
\
do { \
+ cpu_drain_writebuf(); \
if (PMAP_NEEDS_PTE_SYNC) { \
paddr_t pa; \
- cpu_drain_writebuf(); \
cpu_dcache_wb_range((vaddr_t)(pte), \
(cnt) 2); /* * sizeof(pt_entry_t) */ \
if (cpu_sdcache_enabled()) {\
have softraid crypto call crypto_dispatch appropriately instead of
i had a test install i could sacrifice, so i gave it a shot. this install had
-current base installed. i booted the patched kernel, and installed comp56.tgz.
everything seemed to work fine. rebooted into my non-test install, mounted the
test crypto partition, and sha1'd every hundredth file and compared against
originals, nothing seems amiss. is that a sufficient test?
On Mon, 20 Oct 2014 11:28:34 +1000 David Gwynne da...@gwynne.id.au wrote:
the distinct impression i get is crypto_invoke is an internal
abstraction to src/sys/crypto/crypto.c. it isnt documented in
crypto(9), and is only used outside crypto by softraid. softraid
should be calling crypto_dispatch with CRYPTO_F_NOQUEUE set if it
wants/needs those semantics.
can a softraid crypto user test this for me?
Index: softraid_crypto.c
===
RCS file: /cvs/src/sys/dev/softraid_crypto.c,v
retrieving revision 1.112
diff -u -p -r1.112 softraid_crypto.c
--- softraid_crypto.c 14 Sep 2014 14:17:24 - 1.112
+++ softraid_crypto.c 20 Oct 2014 01:25:12 -
@@ -1118,7 +1118,8 @@ sr_crypto_rw(struct sr_workunit *wu)
if (wu-swu_xs-flags SCSI_DATA_OUT) {
crwu = sr_crypto_prepare(wu, 1);
crwu-cr_crp-crp_callback = sr_crypto_write;
- rv = crypto_invoke(crwu-cr_crp);
+ crwu-cr_crp-crp_flags = CRYPTO_F_NOQUEUE;
+ rv = crypto_dispatch(crwu-cr_crp);
if (rv == 0)
rv = crwu-cr_crp-crp_etype;
} else
@@ -1195,9 +1196,10 @@ sr_crypto_done(struct sr_workunit *wu)
if (ISSET(xs-flags, SCSI_DATA_IN) xs-error == XS_NOERROR) {
crwu = sr_crypto_prepare(wu, 0);
crwu-cr_crp-crp_callback = sr_crypto_read;
- DNPRINTF(SR_D_INTR, %s: sr_crypto_done: crypto_invoke %p\n,
+ crwu-cr_crp-crp_flags = CRYPTO_F_NOQUEUE;
+ DNPRINTF(SR_D_INTR, %s: sr_crypto_done: crypto_dispatch %p\n,
DEVNAME(wu-swu_dis-sd_sc), crwu-cr_crp);
- crypto_invoke(crwu-cr_crp);
+ crypto_dispatch(crwu-cr_crp);
return;
}
Re: have softraid crypto call crypto_dispatch appropriately instead of
On 20 Oct 2014, at 9:15 pm, thev...@openmailbox.org wrote:
i had a test install i could sacrifice, so i gave it a shot. this install had
-current base installed. i booted the patched kernel, and installed
comp56.tgz.
everything seemed to work fine. rebooted into my non-test install, mounted the
test crypto partition, and sha1'd every hundredth file and compared against
originals, nothing seems amiss. is that a sufficient test?
yep, perfect.
thank you.
dlg
On Mon, 20 Oct 2014 11:28:34 +1000 David Gwynne da...@gwynne.id.au wrote:
the distinct impression i get is crypto_invoke is an internal
abstraction to src/sys/crypto/crypto.c. it isnt documented in
crypto(9), and is only used outside crypto by softraid. softraid
should be calling crypto_dispatch with CRYPTO_F_NOQUEUE set if it
wants/needs those semantics.
can a softraid crypto user test this for me?
Index: softraid_crypto.c
===
RCS file: /cvs/src/sys/dev/softraid_crypto.c,v
retrieving revision 1.112
diff -u -p -r1.112 softraid_crypto.c
--- softraid_crypto.c14 Sep 2014 14:17:24 - 1.112
+++ softraid_crypto.c20 Oct 2014 01:25:12 -
@@ -1118,7 +1118,8 @@ sr_crypto_rw(struct sr_workunit *wu)
if (wu-swu_xs-flags SCSI_DATA_OUT) {
crwu = sr_crypto_prepare(wu, 1);
crwu-cr_crp-crp_callback = sr_crypto_write;
-rv = crypto_invoke(crwu-cr_crp);
+crwu-cr_crp-crp_flags = CRYPTO_F_NOQUEUE;
+rv = crypto_dispatch(crwu-cr_crp);
if (rv == 0)
rv = crwu-cr_crp-crp_etype;
} else
@@ -1195,9 +1196,10 @@ sr_crypto_done(struct sr_workunit *wu)
if (ISSET(xs-flags, SCSI_DATA_IN) xs-error == XS_NOERROR) {
crwu = sr_crypto_prepare(wu, 0);
crwu-cr_crp-crp_callback = sr_crypto_read;
-DNPRINTF(SR_D_INTR, %s: sr_crypto_done: crypto_invoke %p\n,
+crwu-cr_crp-crp_flags = CRYPTO_F_NOQUEUE;
+DNPRINTF(SR_D_INTR, %s: sr_crypto_done: crypto_dispatch %p\n,
DEVNAME(wu-swu_dis-sd_sc), crwu-cr_crp);
-crypto_invoke(crwu-cr_crp);
+crypto_dispatch(crwu-cr_crp);
return;
}
let crypto.c pools protect themselves
tested this with your other patch. i applied both patches to the kernel at the
same time, so test results the same as with the other patch (good for softraid
at least).
On Mon, 20 Oct 2014 10:49:35 +1000 David Gwynne da...@gwynne.id.au wrote:
pools lock themselves, we just gotta tell them how hard.
can someone test this with ipsec or softraid crypto? or ok it?
Index: crypto.c
===
RCS file: /cvs/src/sys/crypto/crypto.c,v
retrieving revision 1.68
diff -u -p -r1.68 crypto.c
--- crypto.c 20 Oct 2014 00:40:33 - 1.68
+++ crypto.c 20 Oct 2014 00:46:44 -
@@ -453,20 +453,16 @@ void
crypto_freereq(struct cryptop *crp)
{
struct cryptodesc *crd;
- int s;
if (crp == NULL)
return;
- s = splvm();
-
while ((crd = crp-crp_desc) != NULL) {
crp-crp_desc = crd-crd_next;
pool_put(cryptodesc_pool, crd);
}
pool_put(cryptop_pool, crp);
- splx(s);
}
/*
@@ -477,20 +473,14 @@ crypto_getreq(int num)
{
struct cryptodesc *crd;
struct cryptop *crp;
- int s;
- s = splvm();
-
crp = pool_get(cryptop_pool, PR_NOWAIT | PR_ZERO);
- if (crp == NULL) {
- splx(s);
+ if (crp == NULL)
return NULL;
- }
while (num--) {
crd = pool_get(cryptodesc_pool, PR_NOWAIT | PR_ZERO);
if (crd == NULL) {
- splx(s);
crypto_freereq(crp);
return NULL;
}
@@ -499,7 +489,6 @@ crypto_getreq(int num)
crp-crp_desc = crd;
}
- splx(s);
return crp;
}
@@ -510,8 +499,10 @@ crypto_init(void)
pool_init(cryptop_pool, sizeof(struct cryptop), 0, 0,
0, cryptop, NULL);
+ pool_setipl(cryptop_pool, IPL_VM);
pool_init(cryptodesc_pool, sizeof(struct cryptodesc), 0, 0,
0, cryptodesc, NULL);
+ pool_setipl(cryptodesc_pool, IPL_VM);
}
/*
Re: LibreSSL: GOST ciphers implementation
On Mon, Oct 20, 2014 at 01:57:44PM +0400, Dmitry Eremin-Solenikov wrote: Hello, It took a while longer than I expected, but I think that the GOST ciphers implementation is complete now at https://github.com/libressl-portable/openbsd/pull/6 I still expect issues when Windows GOST CSP vendors will work on TLS 1.2 implementation (up to now they only provide TLS 1.0). However that will have to be fixed in future (when there will be at least one GOST + TLS 1.2 implementation). Could you please provide review, comments/ How do you manage so many? Alsa (and linux kernel overall), debian packages maintain, wikipedia editing, cryptography (gnupg and now GHOST for libressl) etc, etc, etc.. Are you God? )
Re: pppoe(4), add example for ipv6
Any comments on the diff in this? On 2014/10/08 13:31, Stuart Henderson wrote: On 2014/10/08 11:10, Stefan Sperling wrote: On Tue, Oct 07, 2014 at 11:42:10PM -0400, Brad Smith wrote: On 07/10/14 10:03 PM, Stuart Henderson wrote: Since it's non-obvious how to setup pppoe for v6 now that link-local addresses are no longer configured by default, I think we should have something in the manual. Any comments/objections/suggestions for a better way to do this? This doesn't make any sense. IPv6CP configures the link local address. IPv6CP prevents *collisions* of link-local addresses on the same p2p link. If an existing link-local address doesn't collide with the remote peer's address we keep using the existing address. The link-local address will be changed by IPv6CP only if there is a collision (which won't ever happen under normal conditions). pppoe(4) doesn't send an IPV6CP request unless it already has a link-local address. With a pre-existing link-local : We request They ack They request We ack Done, echoes start Without : They request We ack They request We ack They request We ack They request We ack They reques.etc etc until they give up waiting for us to send a req. A route to fe80:: needs to be configured statically in any case until autoconf works with ip6 forwarding enabled. !/sbin/route add default -ifp pppoe0 fe80:: I suppose we can't run this command from hostname.pppoe0 if there is no IPv6 address yet, so it makes sense to configure one first. With the current behaviour it's more that it's a requirement rather than just makes sense. But then... you expect that a pppoe(4) interface *does* pick up addresses automatically when it's configured/brought up, so perhaps the argument that triggered the change to NOINET6 by default shouldn't apply in this case - should pppoe(4) interfaces actually get an IPv6 link-local address by default like they used to? Index: if_pppoe.c === RCS file: /cvs/src/sys/net/if_pppoe.c,v retrieving revision 1.41 diff -u -p -w -r1.41 if_pppoe.c --- if_pppoe.c13 Aug 2014 12:03:40 - 1.41 +++ if_pppoe.c8 Oct 2014 12:24:07 - @@ -245,6 +245,9 @@ pppoe_clone_create(struct if_clone *ifc, timeout_set(sc-sc_timeout, pppoe_timeout, sc); if_attach(sc-sc_sppp.pp_if); +#ifdef INET6 + sc-sc_sppp.pp_if.if_xflags = ~IFXF_NOINET6; +#endif if_alloc_sadl(sc-sc_sppp.pp_if); sppp_attach(sc-sc_sppp.pp_if); #if NBPFILTER 0
Re: pppoe(4), add example for ipv6
On Mon, Oct 20, 2014 at 01:22:05PM +0100, Stuart Henderson wrote: Any comments on the diff in this? Not sure why you're singling out pppoe(4). Don't other interfaces that use sppp's IPv6CP have the same problem? Are there no others? Generally, I think it would be better to keep IPv6 disabled by default and apply the documentation change you proposed when starting this discussion. Index: if_pppoe.c === RCS file: /cvs/src/sys/net/if_pppoe.c,v retrieving revision 1.41 diff -u -p -w -r1.41 if_pppoe.c --- if_pppoe.c 13 Aug 2014 12:03:40 - 1.41 +++ if_pppoe.c 8 Oct 2014 12:24:07 - @@ -245,6 +245,9 @@ pppoe_clone_create(struct if_clone *ifc, timeout_set(sc-sc_timeout, pppoe_timeout, sc); if_attach(sc-sc_sppp.pp_if); +#ifdef INET6 + sc-sc_sppp.pp_if.if_xflags = ~IFXF_NOINET6; +#endif if_alloc_sadl(sc-sc_sppp.pp_if); sppp_attach(sc-sc_sppp.pp_if); #if NBPFILTER 0
select(2) to poll(2) conversion for mountd(8)
Hi everyone,
I've tested this on my home setup and it seems to work.
Let me know if anything else needs working.
Cheers,
Dimitris
===
RCS file: /cvs/src/sbin/mountd/mountd.c,v
retrieving revision 1.76
diff -u -p -r1.76 mountd.c
--- mountd.c24 Aug 2014 14:45:00 - 1.76
+++ mountd.c20 Oct 2014 14:50:27 -
@@ -54,6 +54,7 @@
#include grp.h
#include netdb.h
#include netgroup.h
+#include poll.h
#include pwd.h
#include signal.h
#include stdio.h
@@ -289,10 +290,9 @@ main(int argc, char *argv[])
void
mountd_svc_run(void)
{
- fd_set *fds = NULL;
- int fds_size = 0;
- extern fd_set *__svc_fdset;
- extern int __svc_fdsetsize;
+ struct pollfd *pfd = NULL, *newp;
+ nfds_t saved_max_pollfd = 0;
+ int nready;
for (;;) {
if (gothup) {
@@ -305,33 +305,30 @@ mountd_svc_run(void)
(caddr_t)0, umntall_each);
exit(0);
}
- if (__svc_fdset) {
- int bytes = howmany(__svc_fdsetsize, NFDBITS) *
- sizeof(fd_mask);
- if (fds_size != __svc_fdsetsize) {
- if (fds)
- free(fds);
- fds = (fd_set *)malloc(bytes); /* XXX */
- fds_size = __svc_fdsetsize;
+ if (svc_max_pollfd saved_max_pollfd) {
+ newp = reallocarray(pfd, svc_max_pollfd, sizeof(*pfd));
+ if (!newp) {
+ free(pfd);
+ perror(mountd_svc_run: - realloc failed);
+ return;
}
- memcpy(fds, __svc_fdset, bytes);
- } else {
- if (fds)
- free(fds);
- fds = NULL;
+ pfd = newp;
+ saved_max_pollfd = svc_max_pollfd;
}
- switch (select(svc_maxfd+1, fds, 0, 0, (struct timeval *)0)) {
+ memcpy(pfd, svc_pollfd, svc_max_pollfd * sizeof(*pfd));
+
+ nready = poll(pfd, svc_max_pollfd, INFTIM);
+ switch (nready) {
case -1:
if (errno == EINTR)
break;
- perror(mountd_svc_run: - select failed);
- if (fds)
- free(fds);
+ perror(mountd_svc_run: - poll failed);
+ free(pfd);
return;
case 0:
break;
default:
- svc_getreqset2(fds, svc_maxfd+1);
+ svc_getreq_poll(pfd, nready);
break;
}
}
Re: pppoe(4), add example for ipv6
On 2014/10/20 14:49, Stefan Sperling wrote: On Mon, Oct 20, 2014 at 01:22:05PM +0100, Stuart Henderson wrote: Any comments on the diff in this? Not sure why you're singling out pppoe(4). Don't other interfaces that use sppp's IPv6CP have the same problem? Are there no others? ah, good point, the others are lmc(4) and san(4). Generally, I think it would be better to keep IPv6 disabled by default and apply the documentation change you proposed when starting this discussion. already done for pppoe(4). san(4) and lmc(4) don't say much about the ppp layer, and sppp(4) doesn't talk about v6 at all.
Re: select(2) to poll(2) conversion for mountd(8)
This looks correct and matches what svc_run() does. - todd
Re: Shadow TCP stacks
On Mon, Oct 20, 2014 at 8:10 PM, Theo de Raadt dera...@cvs.openbsd.org wrote: You are off-topic for this mailing list. Please go discuss it elsewhere. Theo, Does this include my questions on tech? I still want to do this, even of a hundred little pricks don't understand what it is. I think I can make a very tidy self-contained module to do it. I have given up on the idea of using the existing state tables. Pre-loading states will make for a messy patch. I am looking at doing it with a seperate table of pre-shared ISNs Ian
Re: Shadow TCP stacks
Please take it elsewhere until you have something more than words. And when you have more than words, please put it on a a web site and do nothing more than tell people once. Ian, you are abusing these forums, and you know it. Show some damn respect for the number of people on the receiving end of this list. On Mon, Oct 20, 2014 at 8:10 PM, Theo de Raadt dera...@cvs.openbsd.org wrote: You are off-topic for this mailing list. Please go discuss it elsewhere. Theo, Does this include my questions on tech? I still want to do this, even of a hundred little pricks don't understand what it is. I think I can make a very tidy self-contained module to do it. I have given up on the idea of using the existing state tables. Pre-loading states will make for a messy patch. I am looking at doing it with a seperate table of pre-shared ISNs Ian
