Re: Patch: ifconfig - fix SIGSEGV
On Thu, Jun 05, 2014 at 07:39:01PM +0200, Fabian Raetz wrote:
Hi tech@,
Please ignore this thread!
A reboot after rebuilding userland fixed the problem. Sorry!
when calling ifconfig(8) with a not supported option like below, it
segfaults.
ifconfig [interface] -someParameterNotSupportedWithALeadingMinus
ifconfig re0 -adaw
ifconfig iwn0 -media
Here's a backtrace:
#0 strlcpy (dst=0x84c658 _entbuf+24 , src=0x0, siz=optimized out) at
/usr/src/lib/libc/string/strlcpy.c:37
#1 0x00413a45 in _fillhostent (h=0x200f7f800, r=0x84c620 _hostent,
buf=optimized out, len=4096) at /usr/src/lib/libc/asr/gethostnamadr.c:73
#2 0x00413ceb in _gethostbyname (h_errnop=optimized out,
buflen=optimized out, buf=optimized out, ret=optimized out,
af=optimized out,
name=optimized out) at /usr/src/lib/libc/asr/gethostnamadr.c:125
#3 gethostbyname2 (name=optimized out, af=2) at
/usr/src/lib/libc/asr/gethostnamadr.c:152
#4 0x0040ae78 in in_getaddr (s=0x7f7d6f93 -asdf, which=1) at
/usr/src/sbin/ifconfig/ifconfig.c:4556
#5 0x004019b4 in setifaddr (addr=0x7f7d6f93 -asdf, param=0) at
/usr/src/sbin/ifconfig/ifconfig.c:1112
#6 0x00400b01 in main (argc=1, argv=0x7f7d6d78) at
/usr/src/sbin/ifconfig/ifconfig.c:738
And here a patch that fixes the problem for me. Hope this is the right
place to errx().
Another thing i observed is that when calling ifconfig re0 awdawd
it behaves like calling ifconfig re0 up but i have not looked into
this.
Tested against -current amd64
Regards,
Fabian
Index: ifconfig.c
===
RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v
retrieving revision 1.283
diff -u -p -r1.283 ifconfig.c
--- ifconfig.c12 May 2014 08:47:37 - 1.283
+++ ifconfig.c5 Jun 2014 17:17:17 -
@@ -4552,14 +4552,15 @@ in_getaddr(const char *s, int which)
errx(1, %d: bad prefixlen, bits);
in_getprefix(p, MASK);
memcpy(sin-sin_addr, tsin.sin_addr, sizeof(sin-sin_addr));
- } else if (inet_aton(s, sin-sin_addr) == 0) {
+ } else if (inet_aton(s, sin-sin_addr) == 1) {
if ((hp = gethostbyname(s)))
memcpy(sin-sin_addr, hp-h_addr, hp-h_length);
else if ((np = getnetbyname(s)))
sin-sin_addr = inet_makeaddr(np-n_net, INADDR_ANY);
else
errx(1, %s: bad value, s);
- }
+ } else
+ errx(1, %s: bad value, s);
}
/* ARGSUSED */
Re: new OpenSSL flaws
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I do not believe that they, are specifically ignoring OpenBSD, I believe they are ignoring the BSDS in general. Perhaps someone notified FreeBSD but nobody notified the DragonflBSD team either. On 06/05/2014 09:27 PM, Theo de Raadt wrote: There are two main open-source processes for dealing with discovery of security issues and disclosure of that information to the greater community. - One common process is that generally followed by OpenBSD. In this proocess a bug is found, and a fix is commited as soon as the improvement is known to good. Then if an asssement has been done, and it is determined to be important, disclosure occurs, of course after the commit is already public. Everyone including the vendors had the opportunity to get the information in a fair and equal way. - The other main process used by some open source groups, is to quarantine important repairs. A fix is firsst disclosed all affected parties, or at least the right concerned subset. This creates a delay before information availability, but the coordination is intended to provide a benefit. Everyone generally gets the information in a fair and equal way. Both processses have their place. Each software group has their own limitations and needs which will drive their selection. Is clear that the second process -- intending to also take an ethical path for disclosure -- should not specifically exclude a part of the community. Unfortunately I find myself believing reports that the OpenSSL people intentionally asked others for quarantine, and went out of their way to ensure this information would not come to OpenBSD and LibreSSL. There, I've said it. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTkWpWAAoJEMrvovfl62c8xQMH/R/bLRaZMW3qwRqdLp/ZdXk4 mR48+AzYga+Pz45UZApdVPPOhvsOy0lLXlNJFWGGcAfrucZKN94P8enKuhWztgel EINhbFSlxnW3HbvCeOJt1O9xhciW2RJRE9ii669Wfsx+FmceU9sSBWNcQljDFOTJ d4sHPa+EQ88Xs7DCOwDAB8iMlhk9lJcnbGPkscAoBQlv8vjjiU1GGbJYcgCvQ6Gr sp6ts3mNscEx9NtXOGo/D7gWgIrAZTwW8Ni6NtuE4LnKoBAUY4oA4wXb/1gF/8/G hljNyLMVBJKYBySzt1Q+g+ifBsJg3xGCi00tjASIusjXcQFO55zcRfQ65ZHFAPg= =u19g -END PGP SIGNATURE-
Typo in macro name for ASN
Hi All,
From Quanah Gibson-Mount:
UNKOWN-UNKNOWN
Index: crypto/asn1/asn1_err.c
===
RCS file: /cvs/src/lib/libssl/src/crypto/asn1/asn1_err.c,v
retrieving revision 1.16
diff -u -p -u -p -r1.16 asn1_err.c
--- crypto/asn1/asn1_err.c 19 Apr 2014 10:54:26 - 1.16
+++ crypto/asn1/asn1_err.c 6 Jun 2014 07:35:25 -
@@ -303,7 +303,7 @@ static ERR_STRING_DATA ASN1_str_reasons[
{ERR_REASON(ASN1_R_UNKNOWN_PUBLIC_KEY_TYPE), unknown public key type},
{ERR_REASON(ASN1_R_UNKNOWN_SIGNATURE_ALGORITHM), unknown signature
algorithm},
{ERR_REASON(ASN1_R_UNKNOWN_TAG) , unknown tag},
- {ERR_REASON(ASN1_R_UNKOWN_FORMAT), unknown format},
+ {ERR_REASON(ASN1_R_UNKNOWN_FORMAT), unknown format},
{ERR_REASON(ASN1_R_UNSUPPORTED_ANY_DEFINED_BY_TYPE), unsupported any
defined by type},
{ERR_REASON(ASN1_R_UNSUPPORTED_CIPHER) , unsupported cipher},
{ERR_REASON(ASN1_R_UNSUPPORTED_ENCRYPTION_ALGORITHM), unsupported
encryption algorithm},
Re: Typo in macro name for ASN
From Quanah Gibson-Mount: UNKOWN-UNKNOWN Index: crypto/asn1/asn1_err.c Please refrain from sending diffs you obviously didn't test. Miod
mfi(4) vs WT and WB
Hi, I have an PERC 6/i Integrated adapter here: mfi0 at pci2 dev 0 function 0 Symbios Logic SAS1078 rev 0x04: apic 1 int 0 mfi0: PERC 6/i Integrated, firmware 6.2.0-0013, 256MB cache Which has an OK battery but still reports itself as being in WT mode: # sysctl hw.sensors.mfi0.indicator0 hw.sensors.mfi0.indicator0=On (bbu ok), OK # bioctl mfi0 mfi0 | head -2 Volume Status Size Device mfi0 0 Online 249376538624 sd0 RAID1 WT Now I cam across this in the relase notes of firmware 6.3.3-0002: 12. All RAID volumes will be presented as write through (WT) to the operating system (Windows and linux) independent of the actual write cache policy of the virtual disk. The controller manages the data in cache independently of the OS and any applications. Please use OpenManage or the BIOS Configuration Utility to view and manage virtual disk cache settings. So what's the status of this WT/WB flag? Can't it be trusted for PERC 6/i and maybe other adapters? If so, a man page blurp would be needed imo. -Otto
Re: mfi(4) vs WT and WB
On 2014-06-06, Otto Moerbeek o...@drijf.net wrote: So what's the status of this WT/WB flag? Can't it be trusted for PERC 6/i and maybe other adapters? On the old hub.ports (which had a PERC 5/i), the WT/WB flag could be trusted. Disk performance was noticeably worse in WT mode. -- Christian naddy Weisgerber na...@mips.inka.de
Re: mfi(4) vs WT and WB
Which has an OK battery but still reports itself as being in WT mode: So what's the status of this WT/WB flag? Can't it be trusted for PERC 6/i and maybe other adapters? If so, a man page blurp would be needed imo. Difficult experiences have taught me to mistrust all the sensors coming from certain generations of controllers. It feels like they have a mode where they determine themselves obsolete and start punishing the ower.
Re: Wifi TL W723N
On Sat, May 31, 2014 at 06:22:42PM +, Sébastien Morand wrote: Hi, I finally bought a TL W723N and try. usbdevs gives: port 2 addr 3: high speed, power 500 mA, config 1, 802.11n NIC(0x8179), Realtek(0x0bda), rev 0.00, iSerialNumber 00E04C0001 0x8179 is not present in kernel source (usbdevs.h) (for realteak there is 0x8178 and 0x817a and around but not this one). This seems to be an 8188EUS. FreeBSD added support to urtwn(4) in this commit: r264912 | kevlo | 2014-04-25 10:01:22 +0200 (Fri, 25 Apr 2014) | 4 lines Changed paths: M /head/share/man/man4/urtwn.4 M /head/share/man/man4/urtwnfw.4 M /head/sys/conf/files A /head/sys/contrib/dev/urtwn/urtwn-rtl8188eufw.fw.uu M /head/sys/dev/usb/usbdevs M /head/sys/dev/usb/wlan/if_urtwn.c M /head/sys/dev/usb/wlan/if_urtwnreg.h M /head/sys/modules/usb/urtwnfw/Makefile A /head/sys/modules/usb/urtwnfw/urtwnrtl8188eu A /head/sys/modules/usb/urtwnfw/urtwnrtl8188eu/Makefile Add preliminary support for the Realtek RTL8188EUS and RTL8188ETV chipsets. Committed over the TP-LINK TL-WN725N v2 (RTL8188EUS) on amd64 with WPA. any idea how to get it works (if possible of course)? Porting FreeBSD's changes to OpenBSD.
Re: Patch: ifconfig - fix SIGSEGV
Em 06-06-2014 03:49, Fabian Raetz escreveu:
On Thu, Jun 05, 2014 at 07:39:01PM +0200, Fabian Raetz wrote:
Hi tech@,
Please ignore this thread!
A reboot after rebuilding userland fixed the problem. Sorry!
when calling ifconfig(8) with a not supported option like below, it
segfaults.
ifconfig [interface] -someParameterNotSupportedWithALeadingMinus
ifconfig re0 -adaw
ifconfig iwn0 -media
Here's a backtrace:
#0 strlcpy (dst=0x84c658 _entbuf+24 , src=0x0, siz=optimized out) at
/usr/src/lib/libc/string/strlcpy.c:37
#1 0x00413a45 in _fillhostent (h=0x200f7f800, r=0x84c620
_hostent, buf=optimized out, len=4096) at
/usr/src/lib/libc/asr/gethostnamadr.c:73
#2 0x00413ceb in _gethostbyname (h_errnop=optimized out,
buflen=optimized out, buf=optimized out, ret=optimized out,
af=optimized out,
name=optimized out) at /usr/src/lib/libc/asr/gethostnamadr.c:125
#3 gethostbyname2 (name=optimized out, af=2) at
/usr/src/lib/libc/asr/gethostnamadr.c:152
#4 0x0040ae78 in in_getaddr (s=0x7f7d6f93 -asdf, which=1) at
/usr/src/sbin/ifconfig/ifconfig.c:4556
#5 0x004019b4 in setifaddr (addr=0x7f7d6f93 -asdf, param=0)
at /usr/src/sbin/ifconfig/ifconfig.c:1112
#6 0x00400b01 in main (argc=1, argv=0x7f7d6d78) at
/usr/src/sbin/ifconfig/ifconfig.c:738
And here a patch that fixes the problem for me. Hope this is the right
place to errx().
Another thing i observed is that when calling ifconfig re0 awdawd
it behaves like calling ifconfig re0 up but i have not looked into
this.
Tested against -current amd64
Regards,
Fabian
Index: ifconfig.c
===
RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v
retrieving revision 1.283
diff -u -p -r1.283 ifconfig.c
--- ifconfig.c 12 May 2014 08:47:37 - 1.283
+++ ifconfig.c 5 Jun 2014 17:17:17 -
@@ -4552,14 +4552,15 @@ in_getaddr(const char *s, int which)
errx(1, %d: bad prefixlen, bits);
in_getprefix(p, MASK);
memcpy(sin-sin_addr, tsin.sin_addr, sizeof(sin-sin_addr));
-} else if (inet_aton(s, sin-sin_addr) == 0) {
+} else if (inet_aton(s, sin-sin_addr) == 1) {
if ((hp = gethostbyname(s)))
memcpy(sin-sin_addr, hp-h_addr, hp-h_length);
else if ((np = getnetbyname(s)))
sin-sin_addr = inet_makeaddr(np-n_net, INADDR_ANY);
else
errx(1, %s: bad value, s);
-}
+} else
+errx(1, %s: bad value, s);
}
/* ARGSUSED */
Fabian,
Is your machine running under qemu/kvm? If so, you might had came
across the same issue I had:
http://marc.info/?l=openbsd-techm=140026687510910w=2
It's nice to know that the latest snapshot solves this issue. I'll
give it a try.
Cheers,
--
Giancarlo Razzolini
GPG: 4096R/77B981BC
sendmail erratum, June 6, 2014
Please note that we're having an issue with cvsync and some of the
mirrors at this time, so cvs up -rOPENBSD_5_5 may not be a reliable
way to update. Sorry about that. Please use the patches on ftp.
OpenBSD 5.4 is also affected.
untrusted comment: signature from openbsd 5.5 base secret key
RWRGy8gxk9N934pTioJ2iLNiNPkO7oWbSptmBgAwU7cFTb+E8QPTRyYo02PCCJS0RFJcb4TObp6JZ+fCMoCs5KSXEhjmVzVgmwk=
OpenBSD 5.5 errata 7, June 6, 2014: Sendmail was not properly closing file
descriptions before executing programs. This could enable local users to
interfere with an open SMTP connection.
Apply patch using:
signify -Vep /etc/signify/openbsd-55-base.pub -x 007_sendmail.patch.sig \
-m - | (cd /usr/src patch -p0)
And then rebuild and install sendmail:
cd gnu/usr.sbin/sendmail
make obj
make depend
make
make install
Index: gnu/usr.sbin/sendmail/sendmail/conf.c
===
RCS file: /cvs/src/gnu/usr.sbin/sendmail/sendmail/conf.c,v
retrieving revision 1.37
diff -u -p -r1.37 conf.c
--- gnu/usr.sbin/sendmail/sendmail/conf.c 7 Feb 2014 21:25:00 -
1.37
+++ gnu/usr.sbin/sendmail/sendmail/conf.c 5 Jun 2014 10:15:53 -
@@ -5309,8 +5309,8 @@ closefd_walk(lowest, fd)
*/
void
-sm_close_on_exec(highest, lowest)
- int highest, lowest;
+sm_close_on_exec(lowest, highest)
+ int lowest, highest;
{
#if HASFDWALK
(void) fdwalk(closefd_walk, lowest);
openssl errata, June 5
Please note that we're having an issue with cvsync and some of the
mirrors at this time, so cvs up -rOPENBSD_5_5 may not be a reliable
way to update. Sorry about that. Please use the patches on ftp.
There is also a patch available for 5.4.
untrusted comment: signature from openbsd 5.5 base secret key
RWRGy8gxk9N939QYTQR4ilQz+ggyJYBEh6xvD6rJcSISM/QUbENAddngkyz+IjPEgoOTHunuFB0BDIYMvHVfBlUx5xCjibXJ8Ao=
OpenBSD 5.5 errata 8, June 5, 2014:
This patch contains fixes for the following issues:
CVE-2014-0195 - Buffer overflow with crafted DTLS fragments
CVE-2014-0221 - DTLS infinite recursion flaw with Hello Requests
CVE-2014-0224 - SSL/TLS MITM vulnerability (Early ChangeCipherSpec Attack)
CVE-2014-3470 - Anonymous ECDH denial of service (null session certs)
Other issues in https://www.openssl.org/news/secadv_20140605.txt
CVE-2010-5298 - SSL_MODE_RELEASE_BUFFERS session injection or denial of service
This issue was fixed in 004_openssl.patch.sig and subsequently in OpenSSL.
CVE-2014-0198 - SSL_MODE_RELEASE_BUFFERS NULL pointer dereference
This issue was fixed in 005_openssl.patch.sig and subsequently in OpenSSL.
Apply patch using:
signify -Vep /etc/signify/openbsd-55-base.pub -x 008_openssl.patch.sig \
-m - | (cd /usr/src patch -p0)
Then build and install libssl
cd /usr/src/lib/libssl/ssl
make obj
make
make install
Then restart services which depend on SSL.
Index: lib/libssl/src/ssl/d1_both.c
===
RCS file: /cvs/src/lib/libssl/src/ssl/d1_both.c,v
retrieving revision 1.2.4.1
retrieving revision 1.2.4.3
diff -u -p -r1.2.4.1 -r1.2.4.3
--- lib/libssl/src/ssl/d1_both.c8 Apr 2014 00:55:39 - 1.2.4.1
+++ lib/libssl/src/ssl/d1_both.c5 Jun 2014 20:16:56 - 1.2.4.3
@@ -626,8 +626,14 @@ dtls1_reassemble_fragment(SSL *s, struct
frag-msg_header.frag_len = frag-msg_header.msg_len;
frag-msg_header.frag_off = 0;
}
- else
+ else {
frag = (hm_fragment*) item-data;
+ if (frag-msg_header.msg_len != msg_hdr-msg_len) {
+ item = NULL;
+ frag = NULL;
+ goto err;
+ }
+ }
/* If message is already reassembled, this must be a
* retransmit and can be dropped.
@@ -784,6 +790,7 @@ dtls1_get_message_fragment(SSL *s, int s
int i,al;
struct hm_header_st msg_hdr;
+again:
/* see if we have the required fragment already */
if ((frag_len = dtls1_retrieve_buffered_fragment(s,max,ok)) || *ok)
{
@@ -842,8 +849,7 @@ dtls1_get_message_fragment(SSL *s, int s
s-msg_callback_arg);
s-init_num = 0;
- return dtls1_get_message_fragment(s, st1, stn,
- max, ok);
+ goto again;
}
else /* Incorrectly formated Hello request */
{
Index: lib/libssl/src/ssl/s3_clnt.c
===
RCS file: /cvs/src/lib/libssl/src/ssl/s3_clnt.c,v
retrieving revision 1.26
retrieving revision 1.26.8.2
diff -u -p -r1.26 -r1.26.8.2
--- lib/libssl/src/ssl/s3_clnt.c13 Oct 2012 21:25:14 - 1.26
+++ lib/libssl/src/ssl/s3_clnt.c5 Jun 2014 20:09:30 - 1.26.8.2
@@ -559,7 +559,7 @@ int ssl3_connect(SSL *s)
case SSL3_ST_CR_FINISHED_A:
case SSL3_ST_CR_FINISHED_B:
-
+ s-s3-flags |= SSL3_FLAGS_CCS_OK;
ret=ssl3_get_finished(s,SSL3_ST_CR_FINISHED_A,
SSL3_ST_CR_FINISHED_B);
if (ret = 0) goto end;
@@ -917,6 +917,7 @@ int ssl3_get_server_hello(SSL *s)
SSLerr(SSL_F_SSL3_GET_SERVER_HELLO,SSL_R_ATTEMPT_TO_REUSE_SESSION_IN_DIFFERENT_CONTEXT);
goto f_err;
}
+ s-s3-flags |= SSL3_FLAGS_CCS_OK;
s-hit=1;
}
else/* a miss or crap from the other end */
@@ -2508,6 +2509,14 @@ int ssl3_send_client_key_exchange(SSL *s
EC_KEY *tkey;
int ecdh_clnt_cert = 0;
int field_size = 0;
+
+ if (s-session-sess_cert == NULL) {
+ ssl3_send_alert(s, SSL3_AL_FATAL,
+ SSL_AD_UNEXPECTED_MESSAGE);
+ SSLerr(SSL_F_SSL3_SEND_CLIENT_KEY_EXCHANGE,
+ SSL_R_UNEXPECTED_MESSAGE);
+ goto err;
+ }
/* Did we send out the client's
* ECDH share for use in premaster
Index: lib/libssl/src/ssl/s3_pkt.c
ANONCVS MIRROR MAINTAINERS PLEASE READ!
If you or someone you love runs an anoncvs server, they need to see this. We recently added commitid support to our cvs repo. all works fine with cvs and this. However, we ran into a problem with cvsync in ports. Most mirror maintianers use cvsync to fetch the repository from anoncvs.ca - it had a bug where it would not get commits to branches that contained a commitid. anoncvs.ca (the fanout machine) has been fixed. If your cvsync binary is up to date with what has been committed, it should fix itself. So what you need to do is update to the latest -current cvsync port - either build it from sources or install a recently built snapshot port. Once you do that, re-run cvsync and you should be back in business. to check a server do: cvs -d anon...@yourserver.org:/cvs log gnu/usr.sbin/sendmail/sendm\ ail/conf.c | less and see if it has r 1.38 Thanks, and sorry for the disruption, -Bob
Re: ANONCVS MIRROR MAINTAINERS PLEASE READ!
On 2014/06/06 11:17, Bob Beck wrote: If you or someone you love runs an anoncvs server, they need to see this. We recently added commitid support to our cvs repo. all works fine with cvs and this. However, we ran into a problem with cvsync in ports. Most mirror maintianers use cvsync to fetch the repository from anoncvs.ca - it had a bug where it would not get commits to branches that contained a commitid. anoncvs.ca (the fanout machine) has been fixed. If your cvsync binary is up to date with what has been committed, it should fix itself. So what you need to do is update to the latest -current cvsync port - either build it from sources or install a recently built snapshot port. Once you do that, re-run cvsync and you should be back in business. to check a server do: cvs -d anon...@yourserver.org:/cvs log gnu/usr.sbin/sendmail/sendm\ ail/conf.c | less and see if it has r 1.38 Updated information on this, check that r 1.37 has branches: 1.37.4 Thanks, and sorry for the disruption, If you use a scanfile, it should be removed and re-created when updating.
Re: [PATCH 8] aic7xxx: malloc/memset = calloc
bump.
anybody care enought to commit?
On Sat, 31 May 2014 13:06:16 +0200
Benjamin Baier program...@netzbasis.de wrote:
Index: aicasm.c
===
RCS file: /cvs/src/sys/dev/microcode/aic7xxx/aicasm.c,v
retrieving revision 1.15
diff -u -p -r1.15 aicasm.c
--- aicasm.c5 Dec 2012 23:20:19 - 1.15
+++ aicasm.c31 May 2014 11:01:21 -
@@ -500,12 +500,10 @@ emit_patch(scope_t *scope, int patch)
/* No-Op patch */
return;
- new_patch = (patch_t *)malloc(sizeof(*new_patch));
+ new_patch = calloc(1, sizeof(*new_patch));
if (new_patch == NULL)
- stop(Could not malloc patch structure, EX_OSERR);
-
- memset(new_patch, 0, sizeof(*new_patch));
+ stop(Could not calloc patch structure, EX_OSERR);
if (patch == 0) {
new_patch-patch_func = scope-func_num;
@@ -737,10 +735,9 @@ seq_alloc()
{
struct instruction *new_instr;
- new_instr = (struct instruction *)malloc(sizeof(struct instruction));
+ new_instr = calloc(1, sizeof(struct instruction));
if (new_instr == NULL)
- stop(Unable to malloc instruction object, EX_SOFTWARE);
- memset(new_instr, 0, sizeof(*new_instr));
+ stop(Unable to calloc instruction object, EX_SOFTWARE);
TAILQ_INSERT_TAIL(seq_program, new_instr, links);
new_instr-srcline = yylineno;
return new_instr;
@@ -751,10 +748,9 @@ cs_alloc()
{
critical_section_t *new_cs;
- new_cs= (critical_section_t *)malloc(sizeof(critical_section_t));
+ new_cs = calloc(1, sizeof(critical_section_t));
if (new_cs == NULL)
- stop(Unable to malloc critical_section object, EX_SOFTWARE);
- memset(new_cs, 0, sizeof(*new_cs));
+ stop(Unable to calloc critical_section object, EX_SOFTWARE);
TAILQ_INSERT_TAIL(cs_tailq, new_cs, links);
return new_cs;
@@ -765,10 +761,9 @@ scope_alloc()
{
scope_t *new_scope;
- new_scope = (scope_t *)malloc(sizeof(scope_t));
+ new_scope = calloc(1, sizeof(scope_t));
if (new_scope == NULL)
- stop(Unable to malloc scope object, EX_SOFTWARE);
- memset(new_scope, 0, sizeof(*new_scope));
+ stop(Unable to calloc scope object, EX_SOFTWARE);
TAILQ_INIT(new_scope-inner_scope);
if (SLIST_FIRST(scope_stack) != NULL) {
Index: aicasm_symbol.c
===
RCS file: /cvs/src/sys/dev/microcode/aic7xxx/aicasm_symbol.c,v
retrieving revision 1.11
diff -u -p -r1.11 aicasm_symbol.c
--- aicasm_symbol.c 5 Dec 2012 23:20:19 - 1.11
+++ aicasm_symbol.c 31 May 2014 11:01:21 -
@@ -68,12 +68,11 @@ symbol_create(char *name)
{
symbol_t *new_symbol;
- new_symbol = (symbol_t *)malloc(sizeof(symbol_t));
+ new_symbol = calloc(1, sizeof(symbol_t));
if (new_symbol == NULL) {
perror(Unable to create new symbol);
exit(EX_SOFTWARE);
}
- memset(new_symbol, 0, sizeof(*new_symbol));
new_symbol-name = strdup(name);
if (new_symbol-name == NULL)
stop(Unable to strdup symbol name, EX_SOFTWARE);
Re: [PATCH 10] inetd: malloc/memset = calloc
bump.
anybody?
On Sat, 31 May 2014 16:40:35 +0200
Benjamin Baier program...@netzbasis.de wrote:
While here also stop casting {m,c}alloc return value.
Index: inetd.c
===
RCS file: /cvs/src/usr.sbin/inetd/inetd.c,v
retrieving revision 1.137
diff -u -p -r1.137 inetd.c
--- inetd.c 23 Nov 2013 17:24:29 - 1.137
+++ inetd.c 31 May 2014 13:58:00 -
@@ -455,7 +455,7 @@ main(int argc, char *argv[])
if (readablen != allsockn) {
if (fdsrp)
free(fdsrp);
- fdsrp = (fd_set *)calloc(allsockn, 1);
+ fdsrp = calloc(allsockn, 1);
if (fdsrp == NULL) {
syslog(LOG_ERR, Out of memory.);
exit(1);
@@ -1085,7 +1085,7 @@ enter(struct servtab *cp)
struct servtab *sep;
sigset_t omask;
- sep = (struct servtab *)malloc(sizeof (*sep));
+ sep = malloc(sizeof (*sep));
if (sep == NULL) {
syslog(LOG_ERR, Out of memory.);
exit(1);
@@ -1180,13 +1180,11 @@ getconfigent(void)
char *arg, *cp, *hostdelim, *s;
int argc;
- sep = (struct servtab *) malloc(sizeof(struct servtab));
+ sep = calloc(1, sizeof(struct servtab));
if (sep == NULL) {
- syslog(LOG_ERR, malloc: %m);
+ syslog(LOG_ERR, calloc: %m);
exit(1);
}
-
- memset(sep, 0, sizeof *sep);
more:
freeconfig(sep);
@@ -1512,14 +1510,12 @@ dupconfig(struct servtab *sep)
struct servtab *newtab;
int argc;
- newtab = (struct servtab *) malloc(sizeof(struct servtab));
+ newtab = calloc(1, sizeof(struct servtab));
if (newtab == NULL) {
- syslog(LOG_ERR, malloc: %m);
+ syslog(LOG_ERR, calloc: %m);
exit(1);
}
-
- memset(newtab, 0, sizeof(struct servtab));
newtab-se_service = sep-se_service ? newstr(sep-se_service) : NULL;
newtab-se_socktype = sep-se_socktype;
Re: [PATCH 9] installboot: malloc/memset = calloc
bump. anybody? On Sat, 31 May 2014 20:29:42 +0200 Benjamin Baier program...@netzbasis.de wrote: On Sun, 1 Jun 2014 00:57:43 +1000 Joel Sing j...@sing.id.au wrote: In this case I think readability wins. I do not believe that there is a lot to gain from overflow protection given the numbers used in these calculations are very small (and many are already bounds checked in some form or other). Well, I had to ask. Here is option 2. Index: bootstrap.c === RCS file: /cvs/src/usr.sbin/installboot/bootstrap.c,v retrieving revision 1.3 diff -u -p -r1.3 bootstrap.c --- bootstrap.c 28 Dec 2013 12:01:33 - 1.3 +++ bootstrap.c 31 May 2014 18:14:56 - @@ -68,10 +68,9 @@ bootstrap(int devfd, char *dev, char *bo fprintf(stderr, bootstrap is %zu bytes (%zu sectors @ %u bytes = %zu bytes)\n, (ssize_t)sb.st_size, bootsec, dl.d_secsize, bootsize); - boot = malloc(bootsize); + boot = calloc(1, bootsize); if (boot == NULL) - err(1, malloc); - memset(boot, 0, bootsize); + err(1, calloc); if (read(fd, boot, bootsize) != (ssize_t)sb.st_size) err(1, read); close(fd); Index: i386_softraid.c === RCS file: /cvs/src/usr.sbin/installboot/i386_softraid.c,v retrieving revision 1.1 diff -u -p -r1.1 i386_softraid.c --- i386_softraid.c 19 Jan 2014 02:58:50 - 1.1 +++ i386_softraid.c 31 May 2014 18:14:56 - @@ -129,11 +129,10 @@ sr_install_bootldr(int devfd, char *dev) inodeblk = nblocks - 1; bootsize = nblocks * SR_FS_BLOCKSIZE; - p = malloc(bootsize); + p = calloc(1, bootsize); if (p == NULL) err(1, NULL); - memset(p, 0, bootsize); fd = open(stage2, O_RDONLY, 0); if (fd == -1) err(1, NULL); Index: sparc64_installboot.c === RCS file: /cvs/src/usr.sbin/installboot/sparc64_installboot.c,v retrieving revision 1.1 diff -u -p -r1.1 sparc64_installboot.c --- sparc64_installboot.c 19 Jan 2014 02:58:50 - 1.1 +++ sparc64_installboot.c 31 May 2014 18:14:56 - @@ -68,10 +68,9 @@ md_loadboot(void) if (blksize SBSIZE - DEV_BSIZE) errx(1, boot blocks too big (%zu %d), blksize, SBSIZE - DEV_BSIZE); - blkstore = malloc(blksize); + blkstore = calloc(1, blksize); if (blkstore == NULL) - err(1, malloc); - memset(blkstore, 0, blksize); + err(1, calloc); if (read(fd, blkstore, sb.st_size) != (ssize_t)sb.st_size) err(1, read); close(fd);
Re: mfi(4) vs WT and WB
On Fri, Jun 06, 2014 at 11:45:49AM +0200, Otto Moerbeek wrote: Hi, I have an PERC 6/i Integrated adapter here: mfi0 at pci2 dev 0 function 0 Symbios Logic SAS1078 rev 0x04: apic 1 int 0 mfi0: PERC 6/i Integrated, firmware 6.2.0-0013, 256MB cache Which has an OK battery but still reports itself as being in WT mode: # sysctl hw.sensors.mfi0.indicator0 hw.sensors.mfi0.indicator0=On (bbu ok), OK # bioctl mfi0 mfi0 | head -2 Volume Status Size Device mfi0 0 Online 249376538624 sd0 RAID1 WT Was this RAID volume previously in WB mode? Is it possible that you've simply configured it for WT? Now I cam across this in the relase notes of firmware 6.3.3-0002: 12. All RAID volumes will be presented as write through (WT) to the operating system (Windows and linux) independent of the actual write cache policy of the virtual disk. The controller manages the data in cache independently of the OS and any applications. Please use OpenManage or the BIOS Configuration Utility to view and manage virtual disk cache settings. I believe this is referring to the caching mode page of the virtual disk as seen by the SCSI subsystem. Specifically the WCE bit would be set to 0. It doesn't sound like a change to the underlying actual write policy. Are you willing to try the 6.3.3-0002 firmware? This release has some changes to address how the remaining capacity of the battery was calculated and handled, both when determining whether there was sufficient remaining capacity for keeping the drives in WB and how the controller handles its internal battery learning cycle (which, BTW, can trigger a period of time where the drives go WT because the process intentionally drains the battern down and recharges). So what's the status of this WT/WB flag? Can't it be trusted for PERC 6/i and maybe other adapters? If so, a man page blurp would be needed imo. -Otto
Re: mfi(4) vs WT and WB
On Fri, Jun 06, 2014 at 02:46:35PM -0400, Jim wrote: On Fri, Jun 06, 2014 at 11:45:49AM +0200, Otto Moerbeek wrote: Hi, I have an PERC 6/i Integrated adapter here: mfi0 at pci2 dev 0 function 0 Symbios Logic SAS1078 rev 0x04: apic 1 int 0 mfi0: PERC 6/i Integrated, firmware 6.2.0-0013, 256MB cache Which has an OK battery but still reports itself as being in WT mode: # sysctl hw.sensors.mfi0.indicator0 hw.sensors.mfi0.indicator0=On (bbu ok), OK # bioctl mfi0 mfi0 | head -2 Volume Status Size Device mfi0 0 Online 249376538624 sd0 RAID1 WT Was this RAID volume previously in WB mode? Is it possible that you've simply configured it for WT? I'm pretty sure I didn't put the volumes in WT mode when I created them. I recently installed 5.5 on this machine, and noticed the flag. Before 5.5 the flag was not avaliable. Now I cam across this in the relase notes of firmware 6.3.3-0002: 12. All RAID volumes will be presented as write through (WT) to the operating system (Windows and linux) independent of the actual write cache policy of the virtual disk. The controller manages the data in cache independently of the OS and any applications. Please use OpenManage or the BIOS Configuration Utility to view and manage virtual disk cache settings. I believe this is referring to the caching mode page of the virtual disk as seen by the SCSI subsystem. Specifically the WCE bit would be set to 0. It doesn't sound like a change to the underlying actual write policy. Are you willing to try the 6.3.3-0002 firmware? This release has some changes to address how the remaining capacity of the battery was calculated and handled, both when determining whether there was sufficient remaining capacity for keeping the drives in WB and how the controller handles its internal battery learning cycle (which, BTW, can trigger a period of time where the drives go WT because the process intentionally drains the battern down and recharges). So what's the status of this WT/WB flag? Can't it be trusted for PERC 6/i and maybe other adapters? If so, a man page blurp would be needed imo. This volumes feel pretty fast, so I suspect caching mode is OK. Still it is confusing to have a flag that doesn't reflect reality. I'm planning to upgrade the firmware next week. We'll see if that changes anything. BTW, al battery indicaters are healthy, no learning cycle going on or something like that. -Otto
Re: mfi(4) vs WT and WB
On 2014/06/06 20:54, Otto Moerbeek wrote: This volumes feel pretty fast, so I suspect caching mode is OK. From experience, you definitely wouldn't be saying pretty fast if it was in WT. :)
fix modf() on sparc
If correct, this fixes a 22 year old bug that exists since 4.4BSD alpha :) In modf, when we go down the Lbig jump, f0:f1 is never set and just contains gibberish. Usually NAN or 0.0. What we really want is just copy the input out and be done. This completely corrupts python when hashing floats for a dictionary. Since the resulting hash is not stable, it makes python crash all over the place: http://bugs.python.org/issue7424 Sparc64 is not affected afaict, it's register passing convention seems to put floats in f0..., making the copied code work just fine ;) Index: arch/sparc/gen/modf.S === RCS file: /home/vcs/cvs/openbsd/src/lib/libc/arch/sparc/gen/modf.S,v retrieving revision 1.8 diff -u -p -r1.8 modf.S --- arch/sparc/gen/modf.S 22 Aug 2012 17:19:35 - 1.8 +++ arch/sparc/gen/modf.S 6 Jun 2014 21:16:40 - @@ -175,11 +175,11 @@ Lbig: */ #ifdef __PIC__ PICCY_SET(L0, %l0, %o7) - std %f0, [%i2] ! *ival = val; + std %i0, [%i2] ! *ival = val; ldd [%l0], %f0 ! return 0.0; #else sethi %hi(L0), %l0 - std %f0, [%i2] ! *ival = val; + std %i0, [%i2] ! *ival = val; ldd [%l0 + %lo(L0)], %f0! return 0.0; #endif ret
Re: fix modf() on sparc
And here's a quick and dirty regression test.
Index: Makefile
===
RCS file: /home/vcs/cvs/openbsd/src/regress/lib/libc/Makefile,v
retrieving revision 1.38
diff -u -p -r1.38 Makefile
--- Makefile29 Dec 2013 01:39:44 - 1.38
+++ Makefile6 Jun 2014 21:05:00 -
@@ -2,7 +2,7 @@
SUBDIR+= _setjmp alloca atexit basename cephes cxa-atexit db dirname env
SUBDIR+= fmemopen fnmatch fpclassify getcap getopt_long glob
-SUBDIR+= hsearch longjmp locale malloc mkstemp netdb open_memstream
+SUBDIR+= hsearch longjmp locale malloc mkstemp modf netdb open_memstream
SUBDIR+= orientation popen printf
SUBDIR+= regex setjmp setjmp-signal sigreturn sigsetjmp sprintf
SUBDIR+= stdio_threading stpncpy strerror strtod strtol strtonum
Index: modf/Makefile
===
RCS file: modf/Makefile
diff -N modf/Makefile
--- /dev/null 1 Jan 1970 00:00:00 -
+++ modf/Makefile 6 Jun 2014 21:05:00 -
@@ -0,0 +1,3 @@
+PROG=modf_test
+
+.include bsd.regress.mk
Index: modf/modf_test.c
===
RCS file: modf/modf_test.c
diff -N modf/modf_test.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ modf/modf_test.c6 Jun 2014 21:05:00 -
@@ -0,0 +1,35 @@
+/* Public domain, 2014, Tobias Ulmer tobi...@tmux.org */
+
+/* Test for bug introduced in 4.4BSD modf() on sparc */
+
+#include math.h
+
+#define BIGFLOAT (5e15) /* Number large enough to trigger the big case */
+
+int
+main(void)
+{
+ double f, i;
+
+ f = modf(BIGFLOAT, i);
+ if (i != BIGFLOAT)
+ return 1;
+ if (f != 0.0)
+ return 1;
+
+ /* Repeat, maybe we were lucky */
+ f = modf(BIGFLOAT, i);
+ if (i != BIGFLOAT)
+ return 1;
+ if (f != 0.0)
+ return 1;
+
+ /* With negative number, for good measure */
+ f = modf(-BIGFLOAT, i);
+ if (i != -BIGFLOAT)
+ return 1;
+ if (f != 0.0)
+ return 1;
+
+ return 0;
+}
Re: ANONCVS MIRROR MAINTAINERS PLEASE READ!
On 06/06/14 19:29, Stuart Henderson wrote: On 2014/06/06 11:17, Bob Beck wrote: If you or someone you love runs an anoncvs server, they need to see this. We recently added commitid support to our cvs repo. all works fine with cvs and this. However, we ran into a problem with cvsync in ports. Most mirror maintianers use cvsync to fetch the repository from anoncvs.ca - it had a bug where it would not get commits to branches that contained a commitid. anoncvs.ca (the fanout machine) has been fixed. If your cvsync binary is up to date with what has been committed, it should fix itself. So what you need to do is update to the latest -current cvsync port - either build it from sources or install a recently built snapshot port. Care to mention the fixed package version, so one knows when it's available at the favourite mirror? cvsync-0.24.19p3, yes? /Alexander Once you do that, re-run cvsync and you should be back in business. to check a server do: cvs -d anon...@yourserver.org:/cvs log gnu/usr.sbin/sendmail/sendm\ ail/conf.c | less and see if it has r 1.38 Updated information on this, check that r 1.37 has branches: 1.37.4 Thanks, and sorry for the disruption, If you use a scanfile, it should be removed and re-created when updating.
Re: ANONCVS MIRROR MAINTAINERS PLEASE READ!
On 2014/06/07 00:04, Alexander Hall wrote: Care to mention the fixed package version, so one knows when it's available at the favourite mirror? cvsync-0.24.19p3, yes? That is correct. There is a -current snapshot package for i386 at http://ftp.openbsd.org/pub/OpenBSD/snapshots/packages/i386/cvsync-0.24.19p3.tgz and probably some mirrors; amd64 should follow shortly. For 5.4/i386 there is a package at http://ftp.obsd.si/pub/OpenBSD-unofficial/5.4-stable/i386/cvsync-0.24.19p3.tgz For 5.5/amd64, http://spacehopper.org/mirrors/cvsync-0.24.19p3.tgz There is a tar of the port directory at http://spacehopper.org/mirrors/cvsync-port.tgz which should be able to replace an existing port directory on a 5.4 or 5.5 system.
clean/portable crypto code...
Hello, I've been doing some work recently on crypto code, and noticed that there aren't many/any good clean implementations of performant crypto code out there (or maybe I just don't know of them). Both OpenSSL's and NSS's code has issues w/ portability and/or cleanliness. But, I prefer to reuse code so that hopefully, when one bug is found, derivatives can be fixed. Is there any interest in collaberation? My current interest is in AES-GCM and AES-XTS. I'm looking at taking a version of the AES-GCM code from NSS (heavily modified as it is unportable) for import into FreeBSD. Thanks. -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not.
Re: ANONCVS MIRROR MAINTAINERS PLEASE READ!
On 06/06/14 19:29, Stuart Henderson wrote: On 2014/06/06 11:17, Bob Beck wrote: If you or someone you love runs an anoncvs server, they need to see this. We recently added commitid support to our cvs repo. all works fine with cvs and this. However, we ran into a problem with cvsync in ports. Most mirror maintianers use cvsync to fetch the repository from anoncvs.ca - it had a bug where it would not get commits to branches that contained a commitid. anoncvs.ca (the fanout machine) has been fixed. If your cvsync binary is up to date with what has been committed, it should fix itself. So what you need to do is update to the latest -current cvsync port - either build it from sources or install a recently built snapshot port. Once you do that, re-run cvsync and you should be back in business. to check a server do: cvs -d anon...@yourserver.org:/cvs log gnu/usr.sbin/sendmail/sendm\ ail/conf.c | less and see if it has r 1.38 Updated information on this, check that r 1.37 has branches: 1.37.4 Thanks, and sorry for the disruption, If you use a scanfile, it should be removed and re-created when updating. If I update my package before my upstream does, do I have to keep removing the scanfile (or disable it) until the upstream mirror has been fully fixed too? /Alexander
Re: new OpenSSL flaws
To clarify and for the record: Being on the distros list is not mandatory to receive advance notification of security issues. The list is just a tool. People reporting security issues to the distros list are encouraged to also notify upstream projects/developers of the affected software, other affected distro vendors, and/or affected Open Source projects. OpenBSD having declined to use the tool shouldn't be interpreted e.g. by OpenSSL as a reason not to notify LibreSSL directly. I don't know if such reasons exist or not, but OpenBSD not being on distros is not it. I do think OpenBSD would benefit from using the tool, increasing the percentage of issues you do receive advance notification for, if you'd like that. However, tools and ethics are separate things. Alexander
Re: ANONCVS MIRROR MAINTAINERS PLEASE READ!
On 06/06/14 18:20, Stuart Henderson wrote: On 2014/06/07 00:04, Alexander Hall wrote: Care to mention the fixed package version, so one knows when it's available at the favourite mirror? cvsync-0.24.19p3, yes? That is correct. There is a -current snapshot package for i386 at http://ftp.openbsd.org/pub/OpenBSD/snapshots/packages/i386/cvsync-0.24.19p3.tgz and probably some mirrors; amd64 should follow shortly. For 5.4/i386 there is a package at http://ftp.obsd.si/pub/OpenBSD-unofficial/5.4-stable/i386/cvsync-0.24.19p3.tgz For 5.5/amd64, http://spacehopper.org/mirrors/cvsync-0.24.19p3.tgz There is a tar of the port directory at http://spacehopper.org/mirrors/cvsync-port.tgz which should be able to replace an existing port directory on a 5.4 or 5.5 system. openbsd.cs.toronto.edu should be fixed (using Stuart's packages) Let me know if there are any issues seen there. Nick.
