Re: ARP mbuf queues
On 19/03/15(Thu) 14:11, Martin Pieuchot wrote:
When a host want to send packets to a destination whose Ethernet address
that has not been resolved yet, it puts such packet on a mbuf queue.
Right now this queue, linked to the corresponding ARP data structure, is
hand rolled. I wrote the diff below during s2k15 to make use of the
mq_enqueue(9) API instead.
I verified that the queue is correctly dropped when an infinite recursion
in in_arpinput() is triggered.
Comments, Ok?
Oops, kspillner@ pointed that I forgot a chunk, here's the full
diff:
Index: netinet/if_ether.c
===
RCS file: /cvs/src/sys/netinet/if_ether.c,v
retrieving revision 1.148
diff -u -p -r1.148 if_ether.c
--- netinet/if_ether.c 14 Mar 2015 17:13:44 - 1.148
+++ netinet/if_ether.c 19 Mar 2015 13:04:28 -
@@ -69,7 +69,6 @@
#endif
#define SDL(s) ((struct sockaddr_dl *)s)
-#define SRP(s) ((struct sockaddr_inarp *)s)
/*
* ARP trailer negotiation. Trailer protocol is not IP specific,
@@ -77,6 +76,15 @@
*/
#define ETHERTYPE_IPTRAILERS ETHERTYPE_TRAIL
+struct llinfo_arp {
+ LIST_ENTRY(llinfo_arp) la_list;
+ struct rtentry *la_rt; /* backpointer to rtentry */
+ long la_asked; /* last time we QUERIED */
+ struct mbuf_queuela_mq; /* packet hold queue */
+};
+#define LA_HOLD_QUEUE 10
+#define LA_HOLD_TOTAL 100
+
/* timer values */
intarpt_prune = (5*60*1); /* walk list every 5 minutes */
intarpt_keep = (20*60);/* once resolved, good for 20 more minutes */
@@ -220,6 +228,7 @@ arp_rtrequest(int req, struct rtentry *r
* add with a LL address.
*/
la = pool_get(arp_pool, PR_NOWAIT | PR_ZERO);
+ mq_init(la-la_mq, LA_HOLD_QUEUE, IPL_NONE);
rt-rt_llinfo = (caddr_t)la;
if (la == NULL) {
log(LOG_DEBUG, %s: malloc failed\n, __func__);
@@ -282,8 +291,7 @@ arp_rtrequest(int req, struct rtentry *r
LIST_REMOVE(la, la_list);
rt-rt_llinfo = 0;
rt-rt_flags = ~RTF_LLINFO;
- while ((m = la-la_hold_head) != NULL) {
- la-la_hold_head = la-la_hold_head-m_nextpkt;
+ while ((m = mq_dequeue(la-la_mq)) != NULL) {
la_hold_total--;
m_freem(m);
}
@@ -425,32 +433,14 @@ arpresolve(struct arpcom *ac, struct rte
* response yet. Insert mbuf in hold queue if below limit
* if above the limit free the queue without queuing the new packet.
*/
- if (la_hold_total MAX_HOLD_TOTAL la_hold_total nmbclust / 64) {
- if (la-la_hold_count = MAX_HOLD_QUEUE) {
- mh = la-la_hold_head;
- la-la_hold_head = la-la_hold_head-m_nextpkt;
- if (mh == la-la_hold_tail)
- la-la_hold_tail = NULL;
- la-la_hold_count--;
- la_hold_total--;
- m_freem(mh);
- }
- if (la-la_hold_tail == NULL)
- la-la_hold_head = m;
- else
- la-la_hold_tail-m_nextpkt = m;
- la-la_hold_tail = m;
- la-la_hold_count++;
- la_hold_total++;
+ if (la_hold_total LA_HOLD_TOTAL la_hold_total nmbclust / 64) {
+ if (mq_enqueue(la-la_mq, m) == 0)
+ la_hold_total++;
} else {
- while ((mh = la-la_hold_head) != NULL) {
- la-la_hold_head =
- la-la_hold_head-m_nextpkt;
+ while ((mh = mq_dequeue(la-la_mq)) != NULL) {
la_hold_total--;
m_freem(mh);
}
- la-la_hold_tail = NULL;
- la-la_hold_count = 0;
m_freem(m);
}
@@ -483,14 +473,10 @@ arpresolve(struct arpcom *ac, struct rte
rt-rt_flags |= RTF_REJECT;
rt-rt_expire += arpt_down;
la-la_asked = 0;
- while ((mh = la-la_hold_head) != NULL) {
- la-la_hold_head =
- la-la_hold_head-m_nextpkt;
+ while ((mh = mq_dequeue(la-la_mq)) != NULL) {
la_hold_total--;
m_freem(mh);
}
- la-la_hold_tail = NULL;
- la-la_hold_count = 0;
}
}
}
@@ -570,13 +556,14 @@ in_arpinput(struct mbuf *m)
struct sockaddr_dl *sdl;
Re: Rewording mbstowcs(3), wcrtomb(3) and wcstombs(3)
On Wed, Mar 18, 2015 at 03:32:40PM -0400, Andre Smagin wrote: Hello. mbstowcs(3), wcrtomb(3) and wcstombs(3) use a bit awkward wording - the first at most, and repeat array pointed to by blah from the previous sentence. Perhaps something similar to this diff would make them easier to read? fixed, thanks. jmc Index: mbstowcs.3 === RCS file: /cvs/src/lib/libc/locale/mbstowcs.3,v retrieving revision 1.5 diff -u -p -u -r1.5 mbstowcs.3 --- mbstowcs.35 Jun 2013 03:39:22 - 1.5 +++ mbstowcs.318 Mar 2015 19:05:39 - @@ -46,9 +46,9 @@ converts a null-terminated multibyte cha to the corresponding wide-character string and stores it in the array pointed to by .Fa pwcs . -This function may modify the first at most +Up to .Fa n -elements of the array pointed to by +elements are stored in .Fa pwcs . Each character will be converted as if .Xr mbtowc 3 Index: wcrtomb.3 === RCS file: /cvs/src/lib/libc/locale/wcrtomb.3,v retrieving revision 1.7 diff -u -p -u -r1.7 wcrtomb.3 --- wcrtomb.3 28 Aug 2013 16:24:07 - 1.7 +++ wcrtomb.3 18 Mar 2015 19:05:39 - @@ -48,9 +48,9 @@ pointed to by unless .Fa s is a null pointer. -This function will modify the first at most +Up to .Dv MB_CUR_MAX -bytes of the array pointed by +bytes are stored in .Fa s . .Pp The behaviour of Index: wcstombs.3 === RCS file: /cvs/src/lib/libc/locale/wcstombs.3,v retrieving revision 1.5 diff -u -p -u -r1.5 wcstombs.3 --- wcstombs.35 Jun 2013 03:39:22 - 1.5 +++ wcstombs.318 Mar 2015 19:05:39 - @@ -45,9 +45,9 @@ converts the null-terminated wide-charac to the corresponding multibyte character string, and stores it in the array pointed to by .Fa s . -This function may modify the first at most +Up to .Fa n -bytes of the array pointed to by +bytes are stored in .Fa s . Each character will be converted as if .Xr wctomb 3
Re: typo in 019_libxfont.patch.sig
Timo Trinks wrote: Hi! At the time of writing (Thu Mar 19 11:00:12 UTC 2015) the recently published patch for libXfont (19_libxfont.patch.sig) for OpenBSD 5.6 includes a typo [1]: --- /tmp/019_libxfont.patch.sig Thu Mar 19 12:03:47 2015 +++ /tmp/019_libxfont.patch.sig_fixed Thu Mar 19 12:04:52 2015 @@ -17,7 +17,7 @@ Then build and install a new libXfont: -cd /usr/xenocara/lib/libXont +cd /usr/xenocara/lib/libXfont make -f Makefile.bsd-wrapper obj make -f Makefile.bsd-wrapper build The same typo applies to 023_libxfont.patch.sig for OpenBSD 5.5. Yes. Thanks. I think it's pretty obvious what's meant, since we've gotten about a dozen corrections now. We can correct it, but as you may have heard, there are other pending errata that require slightly more attention right now. Everyone, yes, we appreciate the notice, but I think we've gotten enough now.
Re: Rewording mbstowcs(3), wcrtomb(3) and wcstombs(3)
On Thu, Mar 19, 2015 at 03:58:16PM +0100, Stefan Sperling wrote: Perhaps the following diff would make everyone happy again? Thanks Stefan, it looks good for me. Index: mbstowcs.3 === RCS file: /cvs/src/lib/libc/locale/mbstowcs.3,v retrieving revision 1.6 diff -u -p -r1.6 mbstowcs.3 --- mbstowcs.319 Mar 2015 12:41:51 - 1.6 +++ mbstowcs.319 Mar 2015 14:54:15 - @@ -39,16 +39,12 @@ .Fn mbstowcs wchar_t * restrict pwcs const char * restrict s size_t n .\ -- .Sh DESCRIPTION -The .Fn mbstowcs converts a null-terminated multibyte character string pointed to by .Fa s -to the corresponding wide-character string and stores it in the array -pointed to by -.Fa pwcs . -Up to +to the corresponding wide-character string and stores up to .Fa n -elements are stored in +wide characters in the array pointed to by .Fa pwcs . Each character will be converted as if .Xr mbtowc 3 Index: wcrtomb.3 === RCS file: /cvs/src/lib/libc/locale/wcrtomb.3,v retrieving revision 1.8 diff -u -p -r1.8 wcrtomb.3 --- wcrtomb.3 19 Mar 2015 12:41:51 - 1.8 +++ wcrtomb.3 19 Mar 2015 14:51:10 - @@ -42,16 +42,13 @@ .Fn wcrtomb converts the wide character given by .Fa wc -to the corresponding multibyte character, and stores it in the array -pointed to by +to the corresponding multibyte character, and stores up to +.Dv MB_CUR_MAX +bytes in the array pointed to by .Fa s -unless +if .Fa s -is a null pointer. -Up to -.Dv MB_CUR_MAX -bytes are stored in -.Fa s . +is not a null pointer. .Pp The behaviour of .Fn wcrtomb Index: wcstombs.3 === RCS file: /cvs/src/lib/libc/locale/wcstombs.3,v retrieving revision 1.6 diff -u -p -r1.6 wcstombs.3 --- wcstombs.319 Mar 2015 12:41:51 - 1.6 +++ wcstombs.319 Mar 2015 14:53:30 - @@ -43,11 +43,9 @@ converts the null-terminated wide-character string pointed to by .Fa pwcs to the corresponding multibyte character string, -and stores it in the array pointed to by -.Fa s . -Up to +and stores up to .Fa n -bytes are stored in +bytes in the array pointed to by .Fa s . Each character will be converted as if .Xr wctomb 3
Re: Rewording mbstowcs(3), wcrtomb(3) and wcstombs(3)
On Thu, 19 Mar 2015 13:36:45 +0001 Jason McIntyre j...@kerhand.co.uk wrote: On Thu, Mar 19, 2015 at 03:32:52PM +0200, Kaspars Bankovskis wrote: Is that really accurate to say that elements are stored in a pointer? no idea. it's why i asked stsp to look it over. jmc I looked up the Linux and FreeBSD versions of the man pages and they had wording such as Linux: At most n wide characters are written to dest. At most n bytes are written to dest. FreeBSD: No more than nwchars wide characters are stored. Up to nbytes bytes are stored in mbstring. , so I proposed a similar change. Other OpenBSD man pages use similar form: The strncpy() function copies not more than len characters from the string src to the buffer dst. strlcpy() copies up to dstsize - 1 characters from the string src to dst, KR also say for memcpy copy n characters from ct to s POSIX says for mbstowcs: No more than n elements shall be modified in the array pointed to by pwcs. but I personally find the shall be modified form somewhat ambiguous. -- Andre Smagin
Re: Rewording mbstowcs(3), wcrtomb(3) and wcstombs(3)
Is that really accurate to say that elements are stored in a pointer? On Thu, Mar 19, 2015 at 12:41:48PM +0001, Jason McIntyre wrote: On Wed, Mar 18, 2015 at 03:32:40PM -0400, Andre Smagin wrote: Hello. mbstowcs(3), wcrtomb(3) and wcstombs(3) use a bit awkward wording - the first at most, and repeat array pointed to by blah from the previous sentence. Perhaps something similar to this diff would make them easier to read? fixed, thanks. jmc Index: mbstowcs.3 === RCS file: /cvs/src/lib/libc/locale/mbstowcs.3,v retrieving revision 1.5 diff -u -p -u -r1.5 mbstowcs.3 --- mbstowcs.3 5 Jun 2013 03:39:22 - 1.5 +++ mbstowcs.3 18 Mar 2015 19:05:39 - @@ -46,9 +46,9 @@ converts a null-terminated multibyte cha to the corresponding wide-character string and stores it in the array pointed to by .Fa pwcs . -This function may modify the first at most +Up to .Fa n -elements of the array pointed to by +elements are stored in .Fa pwcs . Each character will be converted as if .Xr mbtowc 3 Index: wcrtomb.3 === RCS file: /cvs/src/lib/libc/locale/wcrtomb.3,v retrieving revision 1.7 diff -u -p -u -r1.7 wcrtomb.3 --- wcrtomb.3 28 Aug 2013 16:24:07 - 1.7 +++ wcrtomb.3 18 Mar 2015 19:05:39 - @@ -48,9 +48,9 @@ pointed to by unless .Fa s is a null pointer. -This function will modify the first at most +Up to .Dv MB_CUR_MAX -bytes of the array pointed by +bytes are stored in .Fa s . .Pp The behaviour of Index: wcstombs.3 === RCS file: /cvs/src/lib/libc/locale/wcstombs.3,v retrieving revision 1.5 diff -u -p -u -r1.5 wcstombs.3 --- wcstombs.3 5 Jun 2013 03:39:22 - 1.5 +++ wcstombs.3 18 Mar 2015 19:05:39 - @@ -45,9 +45,9 @@ converts the null-terminated wide-charac to the corresponding multibyte character string, and stores it in the array pointed to by .Fa s . -This function may modify the first at most +Up to .Fa n -bytes of the array pointed to by +bytes are stored in .Fa s . Each character will be converted as if .Xr wctomb 3
Re: Rewording mbstowcs(3), wcrtomb(3) and wcstombs(3)
On Thu, Mar 19, 2015 at 01:36:45PM +0001, Jason McIntyre wrote: On Thu, Mar 19, 2015 at 03:32:52PM +0200, Kaspars Bankovskis wrote: Is that really accurate to say that elements are stored in a pointer? no idea. it's why i asked stsp to look it over. jmc It's just that the previous sentence in those manuals is still about ..array pointed to by pwcs. And now the next sentence says that something is stored *in* pwcs, which imho doesn't sound quite consistenly. Index: mbstowcs.3 === RCS file: /cvs/src/lib/libc/locale/mbstowcs.3,v retrieving revision 1.5 diff -u -p -u -r1.5 mbstowcs.3 --- mbstowcs.3 5 Jun 2013 03:39:22 - 1.5 +++ mbstowcs.3 18 Mar 2015 19:05:39 - @@ -46,9 +46,9 @@ converts a null-terminated multibyte cha to the corresponding wide-character string and stores it in the array pointed to by .Fa pwcs . -This function may modify the first at most +Up to .Fa n -elements of the array pointed to by +elements are stored in .Fa pwcs . Each character will be converted as if .Xr mbtowc 3
ARP mbuf queues
When a host want to send packets to a destination whose Ethernet address
that has not been resolved yet, it puts such packet on a mbuf queue.
Right now this queue, linked to the corresponding ARP data structure, is
hand rolled. I wrote the diff below during s2k15 to make use of the
mq_enqueue(9) API instead.
I verified that the queue is correctly dropped when an infinite recursion
in in_arpinput() is triggered.
Comments, Ok?
Index: netinet/if_ether.c
===
RCS file: /cvs/src/sys/netinet/if_ether.c,v
retrieving revision 1.148
diff -u -p -r1.148 if_ether.c
--- netinet/if_ether.c 14 Mar 2015 17:13:44 - 1.148
+++ netinet/if_ether.c 19 Mar 2015 13:04:28 -
@@ -69,7 +69,6 @@
#endif
#define SDL(s) ((struct sockaddr_dl *)s)
-#define SRP(s) ((struct sockaddr_inarp *)s)
/*
* ARP trailer negotiation. Trailer protocol is not IP specific,
@@ -77,6 +76,15 @@
*/
#define ETHERTYPE_IPTRAILERS ETHERTYPE_TRAIL
+struct llinfo_arp {
+ LIST_ENTRY(llinfo_arp) la_list;
+ struct rtentry *la_rt; /* backpointer to rtentry */
+ long la_asked; /* last time we QUERIED */
+ struct mbuf_queuela_mq; /* packet hold queue */
+};
+#define LA_HOLD_QUEUE 10
+#define LA_HOLD_TOTAL 100
+
/* timer values */
intarpt_prune = (5*60*1); /* walk list every 5 minutes */
intarpt_keep = (20*60);/* once resolved, good for 20 more minutes */
@@ -220,6 +228,7 @@ arp_rtrequest(int req, struct rtentry *r
* add with a LL address.
*/
la = pool_get(arp_pool, PR_NOWAIT | PR_ZERO);
+ mq_init(la-la_mq, LA_HOLD_QUEUE, IPL_NONE);
rt-rt_llinfo = (caddr_t)la;
if (la == NULL) {
log(LOG_DEBUG, %s: malloc failed\n, __func__);
@@ -282,8 +291,7 @@ arp_rtrequest(int req, struct rtentry *r
LIST_REMOVE(la, la_list);
rt-rt_llinfo = 0;
rt-rt_flags = ~RTF_LLINFO;
- while ((m = la-la_hold_head) != NULL) {
- la-la_hold_head = la-la_hold_head-m_nextpkt;
+ while ((m = mq_dequeue(la-la_mq)) != NULL) {
la_hold_total--;
m_freem(m);
}
@@ -425,32 +433,14 @@ arpresolve(struct arpcom *ac, struct rte
* response yet. Insert mbuf in hold queue if below limit
* if above the limit free the queue without queuing the new packet.
*/
- if (la_hold_total MAX_HOLD_TOTAL la_hold_total nmbclust / 64) {
- if (la-la_hold_count = MAX_HOLD_QUEUE) {
- mh = la-la_hold_head;
- la-la_hold_head = la-la_hold_head-m_nextpkt;
- if (mh == la-la_hold_tail)
- la-la_hold_tail = NULL;
- la-la_hold_count--;
- la_hold_total--;
- m_freem(mh);
- }
- if (la-la_hold_tail == NULL)
- la-la_hold_head = m;
- else
- la-la_hold_tail-m_nextpkt = m;
- la-la_hold_tail = m;
- la-la_hold_count++;
- la_hold_total++;
+ if (la_hold_total LA_HOLD_TOTAL la_hold_total nmbclust / 64) {
+ if (mq_enqueue(la-la_mq, m) == 0)
+ la_hold_total++;
} else {
- while ((mh = la-la_hold_head) != NULL) {
- la-la_hold_head =
- la-la_hold_head-m_nextpkt;
+ while ((mh = mq_dequeue(la-la_mq)) != NULL) {
la_hold_total--;
m_freem(mh);
}
- la-la_hold_tail = NULL;
- la-la_hold_count = 0;
m_freem(m);
}
@@ -483,14 +473,10 @@ arpresolve(struct arpcom *ac, struct rte
rt-rt_flags |= RTF_REJECT;
rt-rt_expire += arpt_down;
la-la_asked = 0;
- while ((mh = la-la_hold_head) != NULL) {
- la-la_hold_head =
- la-la_hold_head-m_nextpkt;
+ while ((mh = mq_dequeue(la-la_mq)) != NULL) {
la_hold_total--;
m_freem(mh);
}
- la-la_hold_tail = NULL;
- la-la_hold_count = 0;
}
}
}
@@ -570,13 +556,14 @@ in_arpinput(struct mbuf *m)
struct sockaddr_dl *sdl;
struct sockaddr sa;
struct in_addr isaddr, itaddr, myaddr;
- struct mbuf *mh, *mt;
+ struct mbuf *mh;
Re: Rewording mbstowcs(3), wcrtomb(3) and wcstombs(3)
On Thu, Mar 19, 2015 at 03:32:52PM +0200, Kaspars Bankovskis wrote: Is that really accurate to say that elements are stored in a pointer? no idea. it's why i asked stsp to look it over. jmc On Thu, Mar 19, 2015 at 12:41:48PM +0001, Jason McIntyre wrote: On Wed, Mar 18, 2015 at 03:32:40PM -0400, Andre Smagin wrote: Hello. mbstowcs(3), wcrtomb(3) and wcstombs(3) use a bit awkward wording - the first at most, and repeat array pointed to by blah from the previous sentence. Perhaps something similar to this diff would make them easier to read? fixed, thanks. jmc Index: mbstowcs.3 === RCS file: /cvs/src/lib/libc/locale/mbstowcs.3,v retrieving revision 1.5 diff -u -p -u -r1.5 mbstowcs.3 --- mbstowcs.35 Jun 2013 03:39:22 - 1.5 +++ mbstowcs.318 Mar 2015 19:05:39 - @@ -46,9 +46,9 @@ converts a null-terminated multibyte cha to the corresponding wide-character string and stores it in the array pointed to by .Fa pwcs . -This function may modify the first at most +Up to .Fa n -elements of the array pointed to by +elements are stored in .Fa pwcs . Each character will be converted as if .Xr mbtowc 3 Index: wcrtomb.3 === RCS file: /cvs/src/lib/libc/locale/wcrtomb.3,v retrieving revision 1.7 diff -u -p -u -r1.7 wcrtomb.3 --- wcrtomb.3 28 Aug 2013 16:24:07 - 1.7 +++ wcrtomb.3 18 Mar 2015 19:05:39 - @@ -48,9 +48,9 @@ pointed to by unless .Fa s is a null pointer. -This function will modify the first at most +Up to .Dv MB_CUR_MAX -bytes of the array pointed by +bytes are stored in .Fa s . .Pp The behaviour of Index: wcstombs.3 === RCS file: /cvs/src/lib/libc/locale/wcstombs.3,v retrieving revision 1.5 diff -u -p -u -r1.5 wcstombs.3 --- wcstombs.35 Jun 2013 03:39:22 - 1.5 +++ wcstombs.318 Mar 2015 19:05:39 - @@ -45,9 +45,9 @@ converts the null-terminated wide-charac to the corresponding multibyte character string, and stores it in the array pointed to by .Fa s . -This function may modify the first at most +Up to .Fa n -bytes of the array pointed to by +bytes are stored in .Fa s . Each character will be converted as if .Xr wctomb 3
Re: libre/openssl patches available
Ted Unangst wrote: Patches are now available to fix a variety of issues in libcrypto and libssl. 5.5 patch: http://ftp.openbsd.org/pub/OpenBSD/patches/5.5/common/024_openssl.patch.sig And I boned the instructions again. cd /usr/src/lib/libcrypto/crypto should be cd /usr/src/lib/libssl/crypto instead.
Re: Rewording mbstowcs(3), wcrtomb(3) and wcstombs(3)
On Thu, Mar 19, 2015 at 03:59:44PM +0200, Kaspars Bankovskis wrote: On Thu, Mar 19, 2015 at 01:36:45PM +0001, Jason McIntyre wrote: On Thu, Mar 19, 2015 at 03:32:52PM +0200, Kaspars Bankovskis wrote: Is that really accurate to say that elements are stored in a pointer? no idea. it's why i asked stsp to look it over. jmc It's not technically accurate. Regardless, anyone who can read C function declarations will grok the intended meaning. Some man pages use the 'pointed to by' wording for pointer variables, e.g. read(2), write(2), fseek(3). Some do not, e.g. string functions like memset(3) and strlcpy(3). Shrug. I don't think arguing about this is worth anyone's time. It's just that the previous sentence in those manuals is still about ..array pointed to by pwcs. And now the next sentence says that something is stored *in* pwcs, which imho doesn't sound quite consistenly. I agree here. That wasn't apparent from the context of the diff. I didn't read the entire page. Perhaps the following diff would make everyone happy again? Index: mbstowcs.3 === RCS file: /cvs/src/lib/libc/locale/mbstowcs.3,v retrieving revision 1.6 diff -u -p -r1.6 mbstowcs.3 --- mbstowcs.3 19 Mar 2015 12:41:51 - 1.6 +++ mbstowcs.3 19 Mar 2015 14:54:15 - @@ -39,16 +39,12 @@ .Fn mbstowcs wchar_t * restrict pwcs const char * restrict s size_t n .\ -- .Sh DESCRIPTION -The .Fn mbstowcs converts a null-terminated multibyte character string pointed to by .Fa s -to the corresponding wide-character string and stores it in the array -pointed to by -.Fa pwcs . -Up to +to the corresponding wide-character string and stores up to .Fa n -elements are stored in +wide characters in the array pointed to by .Fa pwcs . Each character will be converted as if .Xr mbtowc 3 Index: wcrtomb.3 === RCS file: /cvs/src/lib/libc/locale/wcrtomb.3,v retrieving revision 1.8 diff -u -p -r1.8 wcrtomb.3 --- wcrtomb.3 19 Mar 2015 12:41:51 - 1.8 +++ wcrtomb.3 19 Mar 2015 14:51:10 - @@ -42,16 +42,13 @@ .Fn wcrtomb converts the wide character given by .Fa wc -to the corresponding multibyte character, and stores it in the array -pointed to by +to the corresponding multibyte character, and stores up to +.Dv MB_CUR_MAX +bytes in the array pointed to by .Fa s -unless +if .Fa s -is a null pointer. -Up to -.Dv MB_CUR_MAX -bytes are stored in -.Fa s . +is not a null pointer. .Pp The behaviour of .Fn wcrtomb Index: wcstombs.3 === RCS file: /cvs/src/lib/libc/locale/wcstombs.3,v retrieving revision 1.6 diff -u -p -r1.6 wcstombs.3 --- wcstombs.3 19 Mar 2015 12:41:51 - 1.6 +++ wcstombs.3 19 Mar 2015 14:53:30 - @@ -43,11 +43,9 @@ converts the null-terminated wide-character string pointed to by .Fa pwcs to the corresponding multibyte character string, -and stores it in the array pointed to by -.Fa s . -Up to +and stores up to .Fa n -bytes are stored in +bytes in the array pointed to by .Fa s . Each character will be converted as if .Xr wctomb 3
libre/openssl patches available
Patches are now available to fix a variety of issues in libcrypto and libssl.
For 5.6 and the forthcoming 5.7 release:
CVE-2015-0209 - Use After Free following d2i_ECPrivatekey error
CVE-2015-0286 - Segmentation fault in ASN1_TYPE_cmp
CVE-2015-0287 - ASN.1 structure reuse memory corruption
CVE-2015-0288 - X509_to_X509_REQ NULL pointer deref
CVE-2015-0289 - PKCS7 NULL pointer dereferences
For 5.5:
CVE-2015-0286 - Apply fix from OpenSSL for ASN1_TYPE_cmp.
CVE-2015-0292 - Backport existing fix for Base64 decoding.
Several other issues did not apply or were already fixed.
Refer to https://www.openssl.org/news/secadv_20150319.txt
Thanks to the OpenSSL team for providing patches.
5.5 patch:
http://ftp.openbsd.org/pub/OpenBSD/patches/5.5/common/024_openssl.patch.sig
5.6 patch:
http://ftp.openbsd.org/pub/OpenBSD/patches/5.6/common/020_openssl.patch.sig
untrusted comment: signature from openbsd 5.6 base private key
RWR0EANmo9nqhs3L3uaeagbDgYSaBJ3w1MivqvATSTrquGgKHm0sNWVTudl/oumq7hVfVD+KX0LtxlkCQpA5JaPYwTO0OYHyPwE=
OpenBSD 5.6 errata 20, March 19, 2015
Fix several crash causing defects from OpenSSL.
These include:
CVE-2015-0209 - Use After Free following d2i_ECPrivatekey error
CVE-2015-0286 - Segmentation fault in ASN1_TYPE_cmp
CVE-2015-0287 - ASN.1 structure reuse memory corruption
CVE-2015-0288 - X509_to_X509_REQ NULL pointer deref
CVE-2015-0289 - PKCS7 NULL pointer dereferences
Several other issues did not apply or were already fixed.
Refer to https://www.openssl.org/news/secadv_20150319.txt
Apply patch using:
signify -Vep /etc/signify/openbsd-56-base.pub -x 020_openssl.patch.sig \
-m - | (cd /usr/src patch -p0)
Then build and install libcrypto and libssl
cd /usr/src/lib/libcrypto/crypto
make obj
make
make install
cd /usr/src/lib/libssl/ssl
make obj
make
make install
Index: lib/libssl/src/crypto/asn1/a_int.c
===
RCS file: /cvs/src/lib/libssl/src/crypto/asn1/a_int.c,v
retrieving revision 1.24
diff -u -p -r1.24 a_int.c
--- lib/libssl/src/crypto/asn1/a_int.c 11 Jul 2014 08:44:47 - 1.24
+++ lib/libssl/src/crypto/asn1/a_int.c 18 Mar 2015 06:01:34 -
@@ -268,7 +268,7 @@ c2i_ASN1_INTEGER(ASN1_INTEGER **a, const
err:
ASN1err(ASN1_F_C2I_ASN1_INTEGER, i);
- if ((ret != NULL) ((a == NULL) || (*a != ret)))
+ if (a == NULL || *a != ret)
M_ASN1_INTEGER_free(ret);
return (NULL);
}
@@ -335,7 +335,7 @@ d2i_ASN1_UINTEGER(ASN1_INTEGER **a, cons
err:
ASN1err(ASN1_F_D2I_ASN1_UINTEGER, i);
- if ((ret != NULL) ((a == NULL) || (*a != ret)))
+ if (a == NULL || *a != ret)
M_ASN1_INTEGER_free(ret);
return (NULL);
}
Index: lib/libssl/src/crypto/asn1/a_set.c
===
RCS file: /cvs/src/lib/libssl/src/crypto/asn1/a_set.c,v
retrieving revision 1.16
diff -u -p -r1.16 a_set.c
--- lib/libssl/src/crypto/asn1/a_set.c 11 Jul 2014 08:44:47 - 1.16
+++ lib/libssl/src/crypto/asn1/a_set.c 18 Mar 2015 06:01:34 -
@@ -225,7 +225,7 @@ d2i_ASN1_SET(STACK_OF(OPENSSL_BLOCK) **a
return ret;
err:
- if (ret != NULL (a == NULL || *a != ret)) {
+ if (a == NULL || *a != ret) {
if (free_func != NULL)
sk_OPENSSL_BLOCK_pop_free(ret, free_func);
else
Index: lib/libssl/src/crypto/asn1/a_type.c
===
RCS file: /cvs/src/lib/libssl/src/crypto/asn1/a_type.c,v
retrieving revision 1.14
diff -u -p -r1.14 a_type.c
--- lib/libssl/src/crypto/asn1/a_type.c 11 Jul 2014 08:44:47 - 1.14
+++ lib/libssl/src/crypto/asn1/a_type.c 18 Mar 2015 06:01:34 -
@@ -122,7 +122,9 @@ ASN1_TYPE_cmp(ASN1_TYPE *a, ASN1_TYPE *b
case V_ASN1_OBJECT:
result = OBJ_cmp(a-value.object, b-value.object);
break;
-
+ case V_ASN1_BOOLEAN:
+ result = a-value.boolean - b-value.boolean;
+ break;
case V_ASN1_NULL:
result = 0; /* They do not have content. */
break;
Index: lib/libssl/src/crypto/asn1/d2i_pr.c
===
RCS file: /cvs/src/lib/libssl/src/crypto/asn1/d2i_pr.c,v
retrieving revision 1.12
diff -u -p -r1.12 d2i_pr.c
--- lib/libssl/src/crypto/asn1/d2i_pr.c 11 Jul 2014 08:44:47 - 1.12
+++ lib/libssl/src/crypto/asn1/d2i_pr.c 18 Mar 2015 06:01:34 -
@@ -117,7 +117,7 @@ d2i_PrivateKey(int type, EVP_PKEY **a, c
return (ret);
err:
- if ((ret != NULL) ((a == NULL) || (*a != ret)))
+ if (a == NULL || *a != ret)
EVP_PKEY_free(ret);
return (NULL);
}
Index: lib/libssl/src/crypto/asn1/d2i_pu.c
===
RCS file: /cvs/src/lib/libssl/src/crypto/asn1/d2i_pu.c,v
retrieving revision
Re: Rewording mbstowcs(3), wcrtomb(3) and wcstombs(3)
Reads ok to me (for what that's worth). jmc Original Message From: Stefan Sperling Sent: Thursday, 19 March 2015 14:59 To: Kaspars Bankovskis Cc: tech@openbsd.org Subject: Re: Rewording mbstowcs(3), wcrtomb(3) and wcstombs(3) On Thu, Mar 19, 2015 at 03:59:44PM +0200, Kaspars Bankovskis wrote: On Thu, Mar 19, 2015 at 01:36:45PM +0001, Jason McIntyre wrote: On Thu, Mar 19, 2015 at 03:32:52PM +0200, Kaspars Bankovskis wrote: Is that really accurate to say that elements are stored in a pointer? no idea. it's why i asked stsp to look it over. jmc It's not technically accurate. Regardless, anyone who can read C function declarations will grok the intended meaning. Some man pages use the 'pointed to by' wording for pointer variables, e.g. read(2), write(2), fseek(3). Some do not, e.g. string functions like memset(3) and strlcpy(3). Shrug. I don't think arguing about this is worth anyone's time. It's just that the previous sentence in those manuals is still about ..array pointed to by pwcs. And now the next sentence says that something is stored *in* pwcs, which imho doesn't sound quite consistenly. I agree here. That wasn't apparent from the context of the diff. I didn't read the entire page. Perhaps the following diff would make everyone happy again? Index: mbstowcs.3 === RCS file: /cvs/src/lib/libc/locale/mbstowcs.3,v retrieving revision 1.6 diff -u -p -r1.6 mbstowcs.3 --- mbstowcs.3 19 Mar 2015 12:41:51 - 1.6 +++ mbstowcs.3 19 Mar 2015 14:54:15 - @@ -39,16 +39,12 @@ .Fn mbstowcs wchar_t * restrict pwcs const char * restrict s size_t n .\ -- .Sh DESCRIPTION -The .Fn mbstowcs converts a null-terminated multibyte character string pointed to by .Fa s -to the corresponding wide-character string and stores it in the array -pointed to by -.Fa pwcs . -Up to +to the corresponding wide-character string and stores up to .Fa n -elements are stored in +wide characters in the array pointed to by .Fa pwcs . Each character will be converted as if .Xr mbtowc 3 Index: wcrtomb.3 === RCS file: /cvs/src/lib/libc/locale/wcrtomb.3,v retrieving revision 1.8 diff -u -p -r1.8 wcrtomb.3 --- wcrtomb.3 19 Mar 2015 12:41:51 - 1.8 +++ wcrtomb.3 19 Mar 2015 14:51:10 - @@ -42,16 +42,13 @@ .Fn wcrtomb converts the wide character given by .Fa wc -to the corresponding multibyte character, and stores it in the array -pointed to by +to the corresponding multibyte character, and stores up to +.Dv MB_CUR_MAX +bytes in the array pointed to by .Fa s -unless +if .Fa s -is a null pointer. -Up to -.Dv MB_CUR_MAX -bytes are stored in -.Fa s . +is not a null pointer. .Pp The behaviour of .Fn wcrtomb Index: wcstombs.3 === RCS file: /cvs/src/lib/libc/locale/wcstombs.3,v retrieving revision 1.6 diff -u -p -r1.6 wcstombs.3 --- wcstombs.3 19 Mar 2015 12:41:51 - 1.6 +++ wcstombs.3 19 Mar 2015 14:53:30 - @@ -43,11 +43,9 @@ converts the null-terminated wide-character string pointed to by .Fa pwcs to the corresponding multibyte character string, -and stores it in the array pointed to by -.Fa s . -Up to +and stores up to .Fa n -bytes are stored in +bytes in the array pointed to by .Fa s . Each character will be converted as if .Xr wctomb 3
Re: ed: use strtonum
On Wed, 18 Mar 2015 15:35:55 -0600, Todd C. Miller wrote: Trivial conversion to strtonum(). Apparently too trivial. STRTOI advances the pointer passed to it which is broken by this diff. - todd
LibreSSL 2.1.6 released
We have released LibreSSL 2.1.6, which will be arriving in the LibreSSL directory of your local OpenBSD mirror soon. This release primarily addresses a number of security issues in coordination with the OpenSSL project. Fixes for the following issues are integrated into LibreSSL 2.1.6: * CVE-2015-0286 - Segmentation fault in ASN1_TYPE_cmp * CVE-2015-0287 - ASN.1 structure reuse memory corruption * CVE-2015-0289 - PKCS7 NULL pointer dereferences * CVE-2015-0209 - Use After Free following d2i_ECPrivatekey error * CVE-2015-0288 - X509_to_X509_REQ NULL pointer deref The patch for this issue is integrated in LibreSSL 2.1.6: * CVE-2015-0207 - Segmentation fault in DTLSv1_listen LibreSSL is not vulnerable, but the fix was safe to merge. The following issues were addressed in earlier LibreSSL releases: * CVE-2015-0204 - RSA silently downgrades to EXPORT_RSA Fixed in LibreSSL 2.1.2 - reclassifed from low to high, * CVE-2015-0292 - Fault processing Base64 decode Fixed in LibreSSL 2.0.0 * CVE-2015-1787 - Empty CKE with client auth and DHE Fixed in LibreSSL 2.0.1 The following issues did not apply to LibreSSL 2.1.6: * CVE-2015-0291 - OpenSSL 1.0.2 ClientHello sigalgs DoS Affected code is not present. * CVE-2015-0290 - Multiblock corrupted pointer Affected code is not present. * CVE-2015-0208 - Segmentation fault for invalid PSS parameters Affected code is not present. * CVE-2015-0293 - DoS via reachable assert in SSLv2 servers Affected code is not present. * CVE-2015-0285 - Handshake with unseeded PRNG Cannot happen by the design of the LibreSSL PRNG. This release also enables the building of libtls by default, as the API and ABI are declared stable within the LibreSSL 2.1.x series. Further changes to libtls will resume with LibreSSL 2.2.x. The LibreSSL project continues improvement of the codebase to reflect modern, safe programming practices. We welcome feedback and improvements from the broader community. Thanks to all of the contributors who helped make this release possible.
Re: libre/openssl patches available
On Thu, 19 Mar 2015, John Merriam wrote: On Thu, 19 Mar 2015, Ted Unangst wrote: Ted Unangst wrote: Patches are now available to fix a variety of issues in libcrypto and libssl. 5.5 patch: http://ftp.openbsd.org/pub/OpenBSD/patches/5.5/common/024_openssl.patch.sig And I boned the instructions again. cd /usr/src/lib/libcrypto/crypto should be cd /usr/src/lib/libssl/crypto instead. Hmmm: # cd /usr/src/lib/libssl/crypto ksh: cd: /usr/src/lib/libssl/crypto - No such file or directory On 5.6-release amd64. I'll look back to see if I can find it but is there a different process to build all of libssl to be sure it's all patched? Nevermind. I see my failure. That change is for the 5.5 patch only I'm thinking. Sorry for the noise again. -- John Merriam
typo in pcidevs ... ?
Hi all, I think that in /usr/src/sys/dev/pci/pcidevs these 3 records product INTEL E5V2_ERR_20x0be3 E5 v2 Error product INTEL E5V2_ERR_30x0be6 E5 v2 Error product INTEL E5V2_ERR_40x0be7 E5 v2 Error should be product INTEL E5V2_ERR_20x0eb3 E5 v2 Error product INTEL E5V2_ERR_30x0eb6 E5 v2 Error product INTEL E5V2_ERR_40x0eb7 E5 v2 Error other eb's in pcidevs are ... product INTEL E5V2_THERMAL_10x0eb0 E5 v2 Thermal product INTEL E5V2_THERMAL_20x0eb1 E5 v2 Thermal product INTEL E5V2_ERR_10x0eb2 E5 v2 Error product INTEL E5V2_THERMAL_30x0eb4 E5 v2 Thermal product INTEL E5V2_THERMAL_40x0eb5 E5 v2 Thermal product INTEL E5V2_UNICAST_12 0x0eeb E5 v2 Unicast # dmesg | grep unknown ... from Dell R620 (E5-2643 v2) vendor Intel, unknown product 0x0eb3 (class system subclass miscellaneous, rev 0x04) at pci15 dev 16 function 3 not configured vendor Intel, unknown product 0x0eb7 (class system subclass miscellaneous, rev 0x04) at pci15 dev 16 function 7 not configured vendor Intel, unknown product 0x0e1d (class system subclass miscellaneous, rev 0x04) at pci15 dev 19 function 0 not configured this 0x0e1d based on linux lspci on Dell R420 (E5-2430 v2) is System peripheral [0880]: Intel Corporation Xeon E7 v2/Xeon E5 v2/Core i7 R2PCIe [8086:0e1d] (rev 04) dmesg and pcidump -v from R620: OpenBSD 5.7 (GENERIC.MP) #881: Sun Mar 8 11:04:17 MDT 2015 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 17115840512 (16322MB) avail mem = 16656302080 (15884MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xcf42c000 (99 entries) bios0: vendor Dell Inc. version 2.4.3 date 07/09/2014 bios0: Dell Inc. PowerEdge R620 acpi0 at bios0: rev 2 acpi0: sleep states S0 S4 S5 acpi0: tables DSDT FACP APIC SPCR HPET DM__ MCFG WD__ SLIC ERST HEST BERT EINJ TCPA PC__ SRAT SSDT acpi0: wakeup devices PCI0(S5) PCI1(S5) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 4 (boot processor) cpu0: Intel(R) Xeon(R) CPU E5-2643 v2 @ 3.50GHz, 3600.45 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 2, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.0, IBE cpu1 at mainbus0: apid 6 (application processor) cpu1: Intel(R) Xeon(R) CPU E5-2643 v2 @ 3.50GHz, 3599.99 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 3, package 0 cpu2 at mainbus0: apid 8 (application processor) cpu2: Intel(R) Xeon(R) CPU E5-2643 v2 @ 3.50GHz, 3599.99 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 4, package 0 cpu3 at mainbus0: apid 16 (application processor) cpu3: Intel(R) Xeon(R) CPU E5-2643 v2 @ 3.50GHz, 3599.99 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 8, package 0 cpu4 at mainbus0: apid 18 (application processor) cpu4: Intel(R) Xeon(R) CPU E5-2643 v2 @ 3.50GHz, 3600.00 MHz cpu4: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu4: 256KB 64b/line 8-way L2 cache cpu4: smt 0, core 9, package 0 cpu5 at mainbus0: apid 20 (application processor) cpu5: Intel(R) Xeon(R) CPU E5-2643 v2 @ 3.50GHz, 3600.00 MHz cpu5:
