Re: First release of LibreSSL portable is available.
On Fri, Jul 11, 2014 at 11:07:10PM +, Miod Vallat wrote: it. As expected, OPENSSL does the opposite and makes life harder for everyone. Hasn't this been the OpenSSL roadmap since the very beginning? Jury is still out as whether they did it on purpose, or whether it was just a side-effect of the lack of funding, or whether they did it on purpose to later complain about the lack of funding.
Re: [PATCH] libressl: add dummy egd functions
I didn't know what egd was up until today, but reading what it is I completely understand that consideration. However, this breaks a number of packages (wget, python, ruby). There's probably a simple solution: Just add dummy functions that always return -1 (which according to the docs means egd not available). This is also what openssl did on archs that had no egd. This is not the right way to fix this. The right way is to talk to your package maintainers and ask them to configure these software without egd support.
battleship puffy
Thanks to the ever attentive eyes of mlarkin, who spotted some unused code to print a battleship in battleship. Diff below enables printing the battleship, changes the name to the S.S. Puffy, and adds my attempt at a tiny ascii blowfish to the side. OK? Index: bs.c === RCS file: /cvs/src/games/bs/bs.c,v retrieving revision 1.24 diff -u -p -r1.24 bs.c --- bs.c29 Aug 2013 20:22:11 - 1.24 +++ bs.c12 Jul 2014 07:36:47 - @@ -260,7 +260,6 @@ static void intro(void) errx(1, screen must be at least %dx%d., PROMPTLINE + 3, COLWIDTH); } -#ifdef PENGUIN #definePR (void)addstr (void)clear(); (void)mvaddstr(4,29,Welcome to Battleship!); @@ -269,16 +268,15 @@ static void intro(void) PR( \\ \\ \\\n); PR( \\ \\ \\ \\ \\_\n); PR( \\ \\ \\_ \\ \\/ |\n); -PR( \\ \\/ \\ \\/ |\n); -PR( \\/ \\_/ |__\n); -PR( / |\n); -PR( \\ S.S. Penguin |\n); -PR(\\ /\n); +PR( \\ \\/ \\__/\\ \\/ |\n); +PR( \\/ \\/ \\/\\_/ |__\n); +PR( //\\/ ..\\/ |\n); +PR( \\ S.S. Puffy\\/\\___o/ |\n); +PR(\\ / /\\ \\ /\n); PR( \\___/\n); (void) mvaddstr(22,27,Hit any key to continue...); (void)refresh(); (void) getch(); -#endif /* PENGUIN */ #ifdef A_COLOR start_color();
open up random mmap
As seen in FreeBSD ASLR, we can open things up on 64-bit platforms. effects: alpha: limit to 1GB (maxdsiz/brksiz) amd64 and sparc64: limit to 4gb (8gb maxdsiz) Index: uvm_map.c === RCS file: /cvs/src/sys/uvm/uvm_map.c,v retrieving revision 1.170 diff -u -p -r1.170 uvm_map.c --- uvm_map.c 11 Jul 2014 16:35:40 - 1.170 +++ uvm_map.c 12 Jul 2014 07:56:15 - @@ -3541,7 +3541,11 @@ uvm_map_hint(struct vmspace *vm, vm_prot } #endif +#ifdef __LP64__ + spacing = (MIN((4UL * 1024 * 1024 * 1024), BRKSIZ) - 1); +#else spacing = (MIN((256 * 1024 * 1024), BRKSIZ) - 1); +#endif addr = (vaddr_t)vm-vm_daddr; /*
Re: First release of LibreSSL portable is available.
On Fri, Jul 11, 2014 at 9:52 PM, tekk t...@parlementum.net wrote: Thanks Bob and all the other LibreSSL hackers. Thanks - While I seem to have been quasi defaulted into the public face for this thing (probably due to size and volume) I hope you can emphasize the all the other hackers. Yes, I've done a lot of work on it, but frankly a lot of openbsd committers have worked on it, and continue to do so. miod@, tedu@, jsing@ and a host of others have done a ton of stuff, and our new developer bcook@ (Brent Cook, AKA busterb) is really behind making portable possible at this stage. Point is this is a team effort. -Bob
[PATCH] main symbol in libcrypto causes trouble
Hi, I had a number of compilation problems with packages when linking to libressl that I could trace back to the appearance of a main symbol in libcrypto.so. I'm far from an expert in dynamic linking and so-files, but afaik libraries shouldn't have a main function symbol. It came from getentropy_linux.c and wasn't really a function, just a stub of it. Removing it did the trick for me. Is this the right approach? (see patch attached) cu, -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 --- libressl-2.0.0/crypto/compat/getentropy_linux.c 2014-07-11 19:41:25.0 +0200 +++ libressl-2.0.0-1/crypto/compat/getentropy_linux.c 2014-07-12 10:09:08.630076633 +0200 @@ -66,7 +66,6 @@ int getentropy(void *buf, size_t len); -extern int main(int, char *argv[]); static int gotdata(char *buf, size_t len); static int getentropy_urandom(void *buf, size_t len); #ifdef CTL_MAXNAME @@ -339,7 +338,6 @@ HX(sigprocmask(SIG_BLOCK, NULL, sigset) == -1, sigset); - HD(main); /* an addr in program */ HD(getentropy); /* an addr in this library */ HD(printf); /* an addr in libc */ p = (char *)p; signature.asc Description: PGP signature
Re: [PATCH] main symbol in libcrypto causes trouble
On Sat, Jul 12, 2014 at 10:20 AM, Hanno Böck ha...@hboeck.de wrote: I had a number of compilation problems with packages when linking to libressl that I could trace back to the appearance of a main symbol in libcrypto.so. Hmm, can you please provide a detailed example of one of these? I'm far from an expert in dynamic linking and so-files, but afaik libraries shouldn't have a main function symbol. It came from getentropy_linux.c and wasn't really a function, just a stub of it. The goal is for it to be a reference to the executable's main(). It should be an undefined symbol in the library that the linker resolves to the executable's. So, before just ripping it out (it's there for a reason), let's get enough info to understand why it's causing compilation problems (that's a pretty generic description...) Philip Guenther
Re: sk(4): jumbo mbufs and rxring accounting
how about this?
Index: if_sk.c
===
RCS file: /cvs/src/sys/dev/pci/if_sk.c,v
retrieving revision 1.168
diff -u -p -r1.168 if_sk.c
--- if_sk.c 19 Apr 2014 18:29:39 - 1.168
+++ if_sk.c 12 Jul 2014 08:29:20 -
@@ -157,12 +157,10 @@ void sk_watchdog(struct ifnet *);
int sk_ifmedia_upd(struct ifnet *);
void sk_ifmedia_sts(struct ifnet *, struct ifmediareq *);
void skc_reset(struct sk_softc *);
-int sk_newbuf(struct sk_if_softc *, int, struct mbuf *, bus_dmamap_t);
-int sk_alloc_jumbo_mem(struct sk_if_softc *);
-void *sk_jalloc(struct sk_if_softc *);
-void sk_jfree(caddr_t, u_int, void *);
+int sk_newbuf(struct sk_if_softc *);
int sk_reset(struct sk_if_softc *);
int sk_init_rx_ring(struct sk_if_softc *);
+void sk_fill_rx_ring(struct sk_if_softc *);
int sk_init_tx_ring(struct sk_if_softc *);
int sk_xmac_miibus_readreg(struct device *, int, int);
@@ -551,21 +549,29 @@ sk_init_rx_ring(struct sk_if_softc *sc_i
rd-sk_rx_ring[i].sk_next = htole32(SK_RX_RING_ADDR(sc_if,
nexti));
}
- for (i = 0; i SK_RX_RING_CNT; i++) {
- if (sk_newbuf(sc_if, i, NULL,
- sc_if-sk_cdata.sk_rx_jumbo_map) == ENOBUFS) {
- printf(%s: failed alloc of %dth mbuf\n,
- sc_if-sk_dev.dv_xname, i);
- return (ENOBUFS);
- }
- }
-
sc_if-sk_cdata.sk_rx_prod = 0;
sc_if-sk_cdata.sk_rx_cons = 0;
+ if_rxr_init(sc_if-sk_cdata.sk_rx_ring, 2, SK_RX_RING_CNT);
+
+ sk_fill_rx_ring(sc_if);
+
return (0);
}
+void
+sk_fill_rx_ring(struct sk_if_softc *sc_if)
+{
+ struct if_rxring *rxr = sc_if-sk_cdata.sk_rx_ring;
+ u_int slots;
+
+ for (slots = if_rxr_get(rxr, SK_RX_RING_CNT); slots 0; slots--) {
+ if (sk_newbuf(sc_if) == ENOBUFS)
+ break;
+ }
+ if_rxr_put(rxr, slots);
+}
+
int
sk_init_tx_ring(struct sk_if_softc *sc_if)
{
@@ -613,199 +619,44 @@ sk_init_tx_ring(struct sk_if_softc *sc_i
}
int
-sk_newbuf(struct sk_if_softc *sc_if, int i, struct mbuf *m,
- bus_dmamap_t dmamap)
+sk_newbuf(struct sk_if_softc *sc_if)
{
- struct mbuf *m_new = NULL;
+ struct mbuf *m;
struct sk_chain *c;
struct sk_rx_desc *r;
+ bus_dmamap_tdmamap;
+ int error;
- if (m == NULL) {
- caddr_t buf = NULL;
-
- MGETHDR(m_new, M_DONTWAIT, MT_DATA);
- if (m_new == NULL)
- return (ENOBUFS);
-
- /* Allocate the jumbo buffer */
- buf = sk_jalloc(sc_if);
- if (buf == NULL) {
- m_freem(m_new);
- DPRINTFN(1, (%s jumbo allocation failed -- packet
- dropped!\n, sc_if-arpcom.ac_if.if_xname));
- return (ENOBUFS);
- }
-
- /* Attach the buffer to the mbuf */
- m_new-m_len = m_new-m_pkthdr.len = SK_JLEN;
- MEXTADD(m_new, buf, SK_JLEN, 0, sk_jfree, sc_if);
- } else {
- /*
-* We're re-using a previously allocated mbuf;
-* be sure to re-init pointers and lengths to
-* default values.
-*/
- m_new = m;
- m_new-m_len = m_new-m_pkthdr.len = SK_JLEN;
- m_new-m_data = m_new-m_ext.ext_buf;
- }
- m_adj(m_new, ETHER_ALIGN);
-
- c = sc_if-sk_cdata.sk_rx_chain[i];
- r = c-sk_desc;
- c-sk_mbuf = m_new;
- r-sk_data_lo = htole32(dmamap-dm_segs[0].ds_addr +
- (((vaddr_t)m_new-m_data
- - (vaddr_t)sc_if-sk_cdata.sk_jumbo_buf)));
- r-sk_ctl = htole32(SK_JLEN | SK_RXSTAT);
- SK_CDRXSYNC(sc_if, i, BUS_DMASYNC_PREWRITE|BUS_DMASYNC_PREREAD);
+ m = MCLGETI(NULL, M_DONTWAIT, NULL, SK_JLEN);
+ if (m == NULL)
+ return (ENOBUFS);
- return (0);
-}
+ m_adj(m, ETHER_ALIGN);
-/*
- * Memory management for jumbo frames.
- */
+ dmamap = sc_if-sk_cdata.sk_rx_map[sc_if-sk_cdata.sk_rx_prod];
-int
-sk_alloc_jumbo_mem(struct sk_if_softc *sc_if)
-{
- struct sk_softc *sc = sc_if-sk_softc;
- caddr_t ptr, kva;
- bus_dma_segment_t seg;
- int i, rseg, state, error;
- struct sk_jpool_entry *entry;
-
- state = error = 0;
-
- /* Grab a big chunk o' storage. */
- if (bus_dmamem_alloc(sc-sc_dmatag, SK_JMEM, PAGE_SIZE, 0,
-seg, 1, rseg, BUS_DMA_NOWAIT)) {
- printf(: can't alloc rx buffers);
+ error = bus_dmamap_load_mbuf(sc_if-sk_softc-sc_dmatag, dmamap, m,
+ BUS_DMA_READ|BUS_DMA_NOWAIT);
+ if (error) {
+ m_freem(m);
Re: [PATCH] main symbol in libcrypto causes trouble
On Sat, 12 Jul 2014 10:29:31 +0200 Philip Guenther guent...@gmail.com wrote: On Sat, Jul 12, 2014 at 10:20 AM, Hanno Böck ha...@hboeck.de wrote: I had a number of compilation problems with packages when linking to libressl that I could trace back to the appearance of a main symbol in libcrypto.so. Hmm, can you please provide a detailed example of one of these? xorg-server: libtool: link: x86_64-pc-linux-gnu-gcc -std=gnu99 -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith -Wmissing-declarations -Wformat=2 -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Wbad-function-cast -Wold-style-definition -Wdeclaration-after-statement -Wunused -Wuninitialized -Wshadow -Wmissing-noreturn -Wmissing-format-attribute -Wredundant-decls -Wlogical-op -Werror=implicit -Werror=nonnull -Werror=init-self -Werror=main -Werror=missing-braces -Werror=sequence-point -Werror=return-type -Werror=trigraphs -Werror=array-bounds -Werror=write-strings -Werror=address -Werror=int-to-pointer-cast -Werror=pointer-to-int-cast -fno-strict-aliasing -fno-strict-aliasing -D_DEFAULT_SOURCE -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -I/usr/include/X11/dri -I/usr/include/libdrm -I/usr/include/pixman-1 -I/var/tmp/portage/x11-base/xorg-server-1.15.99.903/work/xorg-server-1.15.99.903/include -I../../include -I/var/tmp/portage/x11-base/xorg-server-1.15.99.903/work/xorg-server-1.15.99.903/Xext -I/var/tmp/portage/x11-base/xorg-server-1.15.99.903/work/xorg-server-1.15.99.903/composite -I/var/tmp/portage/x11-base/xorg-server-1.15.99.903/work/xorg-server-1.15.99.903/damageext -I/var/tmp/portage/x11-base/xorg-server-1.15.99.903/work/xorg-server-1.15.99.903/xfixes -I/var/tmp/portage/x11-base/xorg-server-1.15.99.903/work/xorg-server-1.15.99.903/Xi -I/var/tmp/portage/x11-base/xorg-server-1.15.99.903/work/xorg-server-1.15.99.903/mi -I/var/tmp/portage/x11-base/xorg-server-1.15.99.903/work/xorg-server-1.15.99.903/miext/sync -I/var/tmp/portage/x11-base/xorg-server-1.15.99.903/work/xorg-server-1.15.99.903/miext/shadow -I/var/tmp/portage/x11-base/xorg-server-1.15.99.903/work/xorg-server-1.15.99.903/miext/damage -I/var/tmp/portage/x11-base/xorg-server-1.15.99.903/work/xorg-server-1.15.99.903/render -I/var/tmp/portage/x11-base/xorg-server-1.15.99.903/work/xorg-server-1.15.99.903/randr -I/var/tmp/portage/x11-base/xorg-server-1.15.99.903/work/xorg-server-1.15.99.903/fb -I/var/tmp/portage/x11-base/xorg-server-1.15.99.903/work/xorg-server-1.15.99.903/dbe -I/var/tmp/portage/x11-base/xorg-server-1.15.99.903/work/xorg-server-1.15.99.903/present -fvisibility=hidden -DHAVE_XORG_CONFIG_H -fvisibility=hidden -I/usr/include/libdrm -O2 -march=core2 -pipe -Wl,-O1 -Wl,-z -Wl,lazy -o Xorg sdksyms.o -Wl,--export-dynamic -Wl,--as-needed ../../dix/.libs/libmain.a ../../dix/.libs/libdix.a loader/.libs/libloader.a common/.libs/libcommon.a -ludev os-support/.libs/libxorgos.a parser/.libs/libxf86config_internal.a dixmods/.libs/libdixmods.a modes/.libs/libxf86modes.a ramdac/.libs/libramdac.a ddc/.libs/libddc.a i2c/.libs/libi2c.a ../../composite/.libs/libcomposite.a ../../xfixes/.libs/libxfixes.a ../../Xext/.libs/libXext.a ../../dbe/.libs/libdbe.a ../../record/.libs/librecord.a ../../randr/.libs/librandr.a ../../render/.libs/librender.a ../../damageext/.libs/libdamageext.a ../../present/.libs/libpresent.a ../../miext/damage/.libs/libdamage.a ../../Xi/.libs/libXi.a ../../xkb/.libs/libxkb.a dixmods/.libs/libxorgxkb.a dri/.libs/libdri.a dri2/.libs/libdri2.a ../../dri3/.libs/libdri3.a ../../miext/sync/.libs/libsync.a ../../mi/.libs/libmi.a ../../os/.libs/libos.a /usr/lib64/libcrypto.so -ldl -lpciaccess -ldrm -lpixman-1 -lXfont -lXau -lxshmfence -lXdmcp -lm /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../x86_64-pc-linux-gnu/bin/ld: Xorg: hidden symbol `main' in ../../dix/.libs/libmain.a(stubmain.o) is referenced by DSO /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../x86_64-pc-linux-gnu/bin/ld: final link failed: Bad value hexchat: libtool: link: x86_64-pc-linux-gnu-gcc -O2 -march=core2 -pipe -Wall -Wno-pointer-sign -funsigned-char -Wno-unused-result -Wl,-O1 -Wl,--as-needed -o hexchat ascii.o banlist.o chanlist.o chanview.o custom-list.o dccgui.o editlist.o fe-gtk.o fkeys.o gtkutil.o ignoregui.o joind.o menu.o maingui.o notifygui.o palette.o pixmaps.o plugin-tray.o plugingui.o rawlog.o resources.o servlistgui.o setup.o sexy-spell-entry.o textgui.o urlgrab.o userlistgui.o xtext.o -Wl,--version-script -Wl,./../version-script -Wl,--export-dynamic -pthread ../common/libhexchatcommon.a -lgtk-x11-2.0 -lgdk-x11-2.0 -lpangocairo-1.0 -latk-1.0 -lcairo -lgdk_pixbuf-2.0 -lpangoft2-1.0 -lpango-1.0 -lfontconfig -lfreetype -lgio-2.0 -lgobject-2.0 -lgmodule-2.0 /usr/lib64/libssl.so /usr/lib64/libcrypto.so -ldl -lglib-2.0 -pthread /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../x86_64-pc-linux-gnu/bin/ld: hexchat: local symbol `main' in ../common/libhexchatcommon.a(libhexchatcommon_a-hexchat.o) is referenced by DSO
Re: [PATCH] main symbol in libcrypto causes trouble
On Sat, Jul 12, 2014 at 10:43, Hanno Böck wrote: On Sat, 12 Jul 2014 10:29:31 +0200 Philip Guenther guent...@gmail.com wrote: On Sat, Jul 12, 2014 at 10:20 AM, Hanno Böck ha...@hboeck.de wrote: I had a number of compilation problems with packages when linking to libressl that I could trace back to the appearance of a main symbol in libcrypto.so. Hmm, can you please provide a detailed example of one of these? xorg-server: /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/../../../../x86_64-pc-linux-gnu/bin/ld: Xorg: hidden symbol `main' in ../../dix/.libs/libmain.a(stubmain.o) is referenced by DSO hexchat: hexchat: local symbol `main' in ../common/libhexchatcommon.a(libhexchatcommon_a-hexchat.o) is referenced by DSO These two look like the opposite problem. They put a main symbol in their library, which the libcrypto reference is picking up. subversion: /bin/sed: symbol lookup error: /usr/lib64/libcrypto.so.29: undefined symbol: main libtool: install: warning: `../../subversion/libsvn_client/libsvn_client-1.la' has not been installed in `/usr/lib64' /bin/sed: symbol lookup error: /usr/lib64/libcrypto.so.29: undefined symbol: main libtool: This looks like a sanity test that you don't install a library with undefined references, although in this case that's exactly what we want.
Re: lynx: disable old protocols
On 2014-07-11 Fri 03:03 AM |, Theo de Raadt wrote: If lynx was removed from base, and only available in ports... how many of you would even know of it's existance and use it? Several times a week I use lynx for http or local html docs. If it wasn't in base, I'd install it/some similar package via siteXX.tgz
Re: lynx: disable old protocols
On Fri, 2014-07-11 at 03:03 -0600, Theo de Raadt wrote: If lynx was removed from base, and only available in ports... how many of you would even know of it's existance and use it? Not only would I know of its existence and go install it to use, I would wonder out loud why the hell it's not in base. Furthermore, if it had been intentionally crippled to exclude rare but definitely used protocols like gopher that are part of stock Lynx as released by the current maintainers, I would wonder what kind of whacked out hallucinogenics someone had to have been on to do such a thing. (It's something I'd expect from Firefox developers, but definitely not from OpenBSD maintaners.) If there's a security hole related to gopher or bibp, let's fix it, let's not up and drop support for those protocols because of it. People do use these protocols even in 2014. If it's code bloat, I'd like to know just how much code we're talking about. Unless we're going to try to put Lynx on install media (and I am definitely not suggesting that we do), 1.7 megabytes really isn't all that big (it's actually smaller than ftp). If you have gamesXX.tgz installed and never play them you have no business complaining about bloat on a binary of that size. Looking back over this patch, I see no reason to break telnet support since we still ship a telnet client. (In case anyone brings this up, I see no reason to remove telnet from base either.) Also, there's no good reason I can think of to break rlogin and tn3270 support for the people who have those installed and need to use it. I retract any support I may have indicated. Now, should the upstream remove this support for whatever reason, that's an entirely different can of worms. But if it ain't broke, don't fix it. And from here it looks like it ain't broke. -- Shawn K. Quinn skqu...@rushpost.com
Re: lynx: disable old protocols
If there's a security hole related to gopher or bibp, let's fix it, let's not up and drop support for those protocols because of it. People do use these protocols even in 2014. let's is a contraction for let us. Basically the community must audit lynx, if they want it to remain in base. Those of us who have glanced judged it to be of poor quality. If it's code bloat, I'd like to know just how much code we're talking about. This is open source. You know you can find the source yourself and read it? Or .. perhaps you can't, and just wish to preach to us?
Re: CVS: cvs.openbsd.org: src
Hello tech@, I just saw the commit message below. Currently I use the source functionality to determine whether I'm in my home network or not and use it to customize sndiod_flags to redirect sound to my main server. Is there an alternative to dynamically change the rc.conf flags based on my network? At the moment my rc.conf.local looks as follow for sndiod: if nc -z 192.168.153.4 11025 2 /dev/null; then sndiod_flags=-f snd@192.168.153.4/0 fi Sincerely, Martijn van Duren On 07/12/14 12:14, Robert Nagy wrote: CVSROOT:/cvs Module name:src Changes by: rob...@cvs.openbsd.org 2014/07/12 04:14:03 Modified files: etc: netstart rc rc.conf etc/rc.d : rc.subr Log message: Make rc.conf a parsed configuration file and stop sourcing it as a shell script. From now on rc.conf has a fixed syntax (key=val) and it is not allowed to add anything to it besides the supported syntax, it all going to be ignored. discussed with and help from deraadt@ and halex@
Re: CVS: cvs.openbsd.org: src
On 2014/07/12 14:04, Martijn van Duren wrote: Hello tech@, I just saw the commit message below. Currently I use the source functionality to determine whether I'm in my home network or not and use it to customize sndiod_flags to redirect sound to my main server. Is there an alternative to dynamically change the rc.conf flags based on my network? Maybe sndiod_flags=NO and start sndiod from /etc/rc.local instead.
Re: First release of LibreSSL portable is available.
CCLD openssl ../crypto/.libs/libcrypto.so: undefined reference to `clock_gettime' collect2: ld returned 1 exit status make[1]: *** [openssl] Error 1 Setting LDFLAGS to -lrt fixes the issue. Rather than LDFLAGS, it should be in LDADD/LIBADD. --8-- Subject: build: resolve link-time failure libtool: link: gcc -O2 -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -Wall -Werror -std=c99 -g -Wno-pointer-sign -D_BSD_SOURCE -D_POSIX_SOURCE -D_GNU_SOURCE -o .libs/openssl [ *.o ... ] ../crypto/.libs/libcrypto.so ../ssl/.libs/libssl.so -Wl,-rpath -Wl,/usr/lib64 ../crypto/.libs/libcrypto.so: undefined reference to `clock_gettime' collect2: error: ld returned 1 exit status --- crypto/Makefile.am |3 +++ 1 file changed, 3 insertions(+) Index: libressl-2.0.0/crypto/Makefile.am === --- libressl-2.0.0.orig/crypto/Makefile.am +++ libressl-2.0.0/crypto/Makefile.am @@ -19,6 +19,7 @@ libcompatnoopt_la_SOURCES = compat/expli # other compatibility functions libcompat_la_CFLAGS = $(CFLAGS) $(USER_CFLAGS) libcompat_la_SOURCES = +libcompat_la_LIBADD = if NO_STRLCAT libcompat_la_SOURCES += compat/strlcat.c @@ -46,12 +47,14 @@ libcompat_la_SOURCES += compat/arc4rando if NO_GETENTROPY if TARGET_LINUX libcompat_la_SOURCES += compat/getentropy_linux.c +libcompat_la_LIBADD += -lrt endif if TARGET_DARWIN libcompat_la_SOURCES += compat/getentropy_osx.c endif if TARGET_SOLARIS libcompat_la_SOURCES += compat/getentropy_solaris.c +libcompat_la_LIBADD += -lrt endif endif
Re: lynx: disable old protocols
On Sat, Jul 12, 2014 at 06:11:16AM -0500, Shawn K. Quinn wrote: On Fri, 2014-07-11 at 03:03 -0600, Theo de Raadt wrote: If lynx was removed from base, and only available in ports... how many of you would even know of it's existance and use it? Not only would I know of its existence and go install it to use, I would wonder out loud why the hell it's not in base. Furthermore, if it had been intentionally crippled to exclude rare but definitely used protocols like gopher that are part of stock Lynx as released by the current maintainers, I would wonder what kind of whacked out hallucinogenics someone had to have been on to do such a thing. (It's something I'd expect from Firefox developers, but definitely not from OpenBSD maintaners.) Beware with such statements, some have both hats. Landry
Re: CVS: cvs.openbsd.org: src
I am however curious about the rational behind this change. Does it solve any particular problem/risk? I seldomly use this style in my own scripts when I need to be able to dynamically determine variables at runtime. So it might be wise to know what hidden daemons I might be facing. The rc configuration file is becoming a well-managed clean file so that a mix of tools and admins can manage it. Not quite at the level of master.passwd, which is strictly controlled. Still admin editable, but well formed so that the future automatic tools won't screw up scripting in the file.
crash, stopped at uao_reference+0x88: movq %rcx,0x8(%rax)
trace - stopped at uao_reference+0x88: movq %rcx,0x8(%rax) uao_reference at ..+0x88 uao_set_swslot at ..+0x55 uvmpd_scan_inactive at ..+0x681 uvmpd_scan at ..+0x23c uvm_pageout at ..+0x5b active process is pagedaemon screenshots at https://drive.google.com/folderview?id=0B8t-sinTZPnucERodGdCcTc2Mmcusp=drive_web machine was untarring files at the time (reading from softdep on softraid, writing to a tmpfs /tmp, which since this i have now replaced with mfs). OpenBSD 5.5-current (GENERIC.MP) #256: Thu Jul 10 16:19:23 MDT 2014 t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4182347776 (3988MB) avail mem = 4062236672 (3874MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xec400 (89 entries) bios0: vendor Dell Inc. version A03 date 11/25/2013 bios0: Dell Inc. PowerEdge T20 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT SLIC LPIT SSDT SSDT SSDT HPET SSDT MCFG SSDT ASF! acpi0: wakeup devices PS2K(S3) PS2M(S3) UAR1(S3) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) PXSX(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Pentium(R) CPU G3220 @ 3.00GHz, 2993.52 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,XSAVE,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,ERMS,INVPCID cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, 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.2.0, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Pentium(R) CPU G3220 @ 3.00GHz, 2993.07 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,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,XSAVE,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,ERMS,INVPCID cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins acpihpet0 at acpi0: 14318179 Hz acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (RP01) acpiprt2 at acpi0: bus 2 (RP02) acpiprt3 at acpi0: bus -1 (PEG0) acpiprt4 at acpi0: bus -1 (PEG1) acpiprt5 at acpi0: bus -1 (PEG2) acpiec0 at acpi0: not present acpicpu0 at acpi0: C1, PSS acpicpu1 at acpi0: C1, PSS acpitz0 at acpi0: critical temperature is 105 degC acpitz1 at acpi0: critical temperature is 105 degC acpibat0 at acpi0: BAT0 not present acpibat1 at acpi0: BAT1 not present acpibat2 at acpi0: BAT2 not present acpibtn0 at acpi0: PWRB acpibtn1 at acpi0: LID0 acpivideo0 at acpi0: GFX0 acpivout0 at acpivideo0: DD1F cpu0: Enhanced SpeedStep 2993 MHz: speeds: 3000, 2900, 2700, 2600, 2400, 2300, 2100, 2000, 1800, 1700, 1500, 1400, 1200, 1100, 900, 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 Intel Core 4G Host rev 0x06 vga1 at pci0 dev 2 function 0 Intel HD Graphics rev 0x06 intagp at vga1 not configured inteldrm0 at vga1 drm0 at inteldrm0 drm: Memory usable by graphics device = 2048M error: [drm:pid0:i915_write32] *ERROR* Unknown unclaimed register before writing to 10 inteldrm0: 1024x768 wsdisplay0 at vga1 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) Intel 8 Series xHCI rev 0x04 at pci0 dev 20 function 0 not configured Intel 8 Series MEI rev 0x04 at pci0 dev 22 function 0 not configured em0 at pci0 dev 25 function 0 Intel I217-LM rev 0x04: msi, address f8:b1:56:b0:df:e7 ehci0 at pci0 dev 26 function 0 Intel 8 Series USB rev 0x04: apic 8 int 16 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 azalia0 at pci0 dev 27 function 0 Intel 8 Series HD Audio rev 0x04: msi azalia0: codecs: Realtek/0x0280 audio0 at azalia0 ppb0 at pci0 dev 28 function 0 Intel 8 Series PCIE rev 0xd4 pci1 at ppb0 bus 1 ppb1 at pci0 dev 28 function 1 Intel 8 Series PCIE rev 0xd4: msi pci2 at ppb1 bus 2 ppb2 at pci2 dev 0 function 0 TI XIO2001 PCIE-PCI rev 0x00 pci3 at ppb2 bus 3 ehci1 at pci0 dev 29 function 0 Intel 8 Series USB rev 0x04: apic 8 int 23 usb1 at ehci1: USB revision 2.0 uhub1 at usb1 Intel EHCI root hub rev 2.00/1.00 addr 1 pcib0 at pci0 dev 31 function 0 Intel C226 LPC rev 0x04 ahci0 at pci0 dev 31 function 2 Intel 8 Series AHCI rev 0x04: msi, AHCI 1.3 scsibus1 at ahci0: 32 targets sd0 at scsibus1 targ 0 lun 0: ATA, Hitachi HDS72202, JKAO SCSI3 0/direct fixed naa.5000cca222f32c62 sd0: 1907729MB, 512 bytes/sector, 3907029168 sectors sd1 at scsibus1 targ 1 lun 0: ATA, Hitachi
Re: faster malloc in threads
On Fri, Jul 11, 2014 at 08:11, Ted Unangst wrote:
I also think there's one simple case that can be added: the MMAP call
at the bottom of map().
On further inspection, I think this needed a slight reordering to be
safe.
I have also been seeing random munmap errors running jruby:
java(3451) in free(): error: munmap 0x41cb4307000
Abort trap
I don't see where the race is, but I am now running with this slightly
more conservative patch. The only enabled unlock sections are for
mmap() on the way to return when internal state won't change. (On the
bright side, I guess this means the malloc lock really does work
normally. :))
Index: malloc.c
===
RCS file: /cvs/src/lib/libc/stdlib/malloc.c,v
retrieving revision 1.170
diff -u -p -r1.170 malloc.c
--- malloc.c9 Jul 2014 19:11:00 - 1.170
+++ malloc.c12 Jul 2014 16:52:17 -
@@ -93,6 +93,15 @@
#define MQUERY(a, sz) mquery((a), (size_t)(sz), PROT_READ | PROT_WRITE, \
MAP_ANON | MAP_PRIVATE | MAP_FIXED, -1, (off_t)0)
+#define KERNENTER() if (__isthreaded) do { \
+ malloc_active--; \
+ _MALLOC_UNLOCK(); \
+} while (0)
+#define KERNEXIT() if (__isthreaded) do { \
+ _MALLOC_LOCK(); \
+ malloc_active++; \
+} while (0)
+
struct region_info {
void *p;/* page; low bits used to mark chunks */
uintptr_t size; /* size for pages, or chunk_info pointer */
@@ -312,7 +321,10 @@ unmap(struct dir_info *d, void *p, size_
}
if (psz mopts.malloc_cache) {
- if (munmap(p, sz))
+ /* KERNENTER(); */
+ i = munmap(p, sz);
+ /* KERNEXIT(); */
+ if (i)
wrterror(munmap, p);
STATS_SUB(d-malloc_used, sz);
return;
@@ -396,7 +408,9 @@ map(struct dir_info *d, size_t sz, int z
return MAP_FAILED;
}
if (psz d-free_regions_size) {
+ KERNENTER();
p = MMAP(sz);
+ KERNEXIT();
if (p != MAP_FAILED)
STATS_ADD(d-malloc_used, sz);
/* zero fill not needed */
@@ -408,18 +422,20 @@ map(struct dir_info *d, size_t sz, int z
if (r-p != NULL) {
if (r-size == psz) {
p = r-p;
+ r-p = NULL;
+ r-size = 0;
+ d-free_regions_size -= psz;
+ /* KERNENTER(); */
if (mopts.malloc_freeunmap)
mprotect(p, sz, PROT_READ | PROT_WRITE);
if (mopts.malloc_hint)
madvise(p, sz, MADV_NORMAL);
- r-p = NULL;
- r-size = 0;
- d-free_regions_size -= psz;
if (zero_fill)
memset(p, 0, sz);
else if (mopts.malloc_junk == 2
mopts.malloc_freeunmap)
memset(p, SOME_FREEJUNK, sz);
+ /* KERNEXIT(); */
return p;
} else if (r-size psz)
big = r;
@@ -440,11 +456,13 @@ map(struct dir_info *d, size_t sz, int z
memset(p, SOME_FREEJUNK, sz);
return p;
}
+ if (d-free_regions_size mopts.malloc_cache)
+ wrterror(malloc cache, NULL);
+ KERNENTER();
p = MMAP(sz);
+ KERNEXIT();
if (p != MAP_FAILED)
STATS_ADD(d-malloc_used, sz);
- if (d-free_regions_size mopts.malloc_cache)
- wrterror(malloc cache, NULL);
/* zero fill not needed */
return p;
}
Re: sk(4): jumbo mbufs and rxring accounting
On 12/07/14 4:32 AM, David Gwynne wrote: how about this? Now it attaches without error but tcpdump shows no traffic coming in at all and there is regular traffic on the segment from spanning tree, CARP, RA, etc. $ vmstat -iz interrupt total rate schizo0:pci_a 00 schizo0:ue 00 schizo0:ce 00 schizo0:safari 00 pcfiic0 00 power0 00 com0 530 com100 autri0 00 ohci0 00 ohci1 00 pciide0 13184 ohci2 00 ohci3 00 ehci0 00 skc050 schizo1:pci_b 00 schizo1:ue 00 schizo1:ce 00 schizo1:safari 00 bge0 9693 clock 30714 99 Total 33059 107 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: lynx: disable old protocols
On Sat, 2014-07-12 at 06:11 -0500, Shawn K. Quinn wrote: If it's code bloat, I'd like to know just how much code we're talking about. Unless we're going to try to put Lynx on install media (and I am definitely not suggesting that we do), 1.7 megabytes really isn't all that big (it's actually smaller than ftp). If you have gamesXX.tgz installed and never play them you have no business complaining about bloat on a binary of that size. The recent patch which removes bibp support and breaks telnet URLs removes a whopping 8k or so (at least on amd64 here, versus -current from a couple days before). If hard drives still topped out at a gigabyte or less that might be an impressive reduction, but those days are long gone. Taking out dired, gopher, news, and finger only makes a total reduction of some 121k. Again, it might make a difference if your whole hard disk is under a gigabyte. Today, a terabyte or significant fraction thereof is more likely. So, not impressive given what we're losing by saving that small amount of disk space. And this comment: leave gopher, news, and dired in place for now. but we will soon catch up to the security level of internet explorer 7 by removing these too. This is complete bullshit, to the point where I would think it came straight from Microsoft's PR department. There is no way in hell that Lynx was ever as insecure as Internet Explorer 7, much less is today. Lynx, by its very nature, is one of the most secure browsers out there, as it lacks almost all of the attack vectors (Javascript, CSS, etc) that, say, Firefox or Chrome has. The most recent advisory for Lynx I found was from 2005, then one from 2003, then one from 2000. That's three over a six-year span, then bupkis for the next nine. I think a more appropriate way of wording this comment in full is: despite several messages on tech@, start gutting lynx under the guise of security. specifically, ignore the people who said bibp is in use and get rid of it. break telnet, rlogin, and tn3270 for the hell of it. leave gopher, news, and dired in place for now. but we will soon catch up to Microsoft's level of saying 'fuck the users' by removing these too, because we feel like it. ok's for the version of this diff that removes even more protocols from deraadt@, tedu@. general support from other devs. again, fuck the people actually using our software, fuck gopher, fuck bibp, fuck nntp and Usenet. OpenBSD: where do you want to go today? Seriously, if you are worried about getting hacked from using Lynx (and I mean real Lynx as distributed, with support for gopher, finger, bibp, telnet, and the kitchen sink included), maybe the Internet is just not for you. As for me, I feel safe running Lynx as root. I'd be surprised to find that many people who were not. Finally, I'm horrified that bibp support was removed, and telnet support was broken, *after* others said they were still using it. I expect this kind of ham-fisted fuck the users move from companies like Microsoft and Apple. I honestly never thought I'd see the day that it would happen in OpenBSD. For now, I'm going to make sure my Lynx still has full functionality if I have to manually unfuck the Makefile myself everytime after I update my sources. In the future? Maybe I (and the other users who actually give a shit about having non-crippled software) should have switched to BitRig (or NetBSD, or maybe even something else) already. It's a shame because I was looking to buy a CD set for 5.6, too. But I won't if Lynx isn't all there in 5.6-release, and I'll be donating the money to another project (most likely BitRig) instead. Feel free to follow my lead should you desire. -- Shawn K. Quinn skqu...@rushpost.com
Re: lynx: disable old protocols
Maybe I (and the other users who actually give a shit about having non-crippled software) should have switched to BitRig (or NetBSD, or maybe even something else) already. Good luck, I won't miss you!
Re: sk(4): jumbo mbufs and rxring accounting
i think i'll try to find the sk at work and wire it up. its just annoying cos im pretty sure its sr optics with sc connectors. thanks for testing. On 13 Jul 2014, at 4:45 am, Brad Smith b...@comstyle.com wrote: On 12/07/14 4:32 AM, David Gwynne wrote: how about this? Now it attaches without error but tcpdump shows no traffic coming in at all and there is regular traffic on the segment from spanning tree, CARP, RA, etc. $ vmstat -iz interrupt total rate schizo0:pci_a 00 schizo0:ue 00 schizo0:ce 00 schizo0:safari 00 pcfiic0 00 power0 00 com0 530 com100 autri0 00 ohci0 00 ohci1 00 pciide0 13184 ohci2 00 ohci3 00 ehci0 00 skc050 schizo1:pci_b 00 schizo1:ue 00 schizo1:ce 00 schizo1:safari 00 bge0 9693 clock 30714 99 Total 33059 107 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
divert(4) icmp length fix
divert_output() has a basic sanity check to ensure that the m_pkthdr.len
for reinjected packets is not shorter than the minimum length based on
the protocol:
if (p_hdrlen m-m_pkthdr.len off + p_hdrlen)
goto fail;
off is the length of the IP header, and p_hdrlen is the expected length
of the protocol header, e.g. sizeof(struct tcphdr) for TCP.
However, this check is currently wrong for ICMP in certain cases,
because sizeof(struct icmp) is 28 but an ICMP header can be as small as
8 bytes, e.g. an ICMP echo request packet with no payload. So this
causes divert(4) to incorrectly discard ICMP packets with a payload
length of 0-19 bytes.
To fix this, I would like to change the check for ICMP from
sizeof(struct icmp) to ICMP_MINLEN, which according to netinet/ip_icmp.h
is the absolute minimum length of an ICMP packet (8 bytes).
I would also like to rename the p_hdrlen variable to min_hdrlen to
better reflect its purpose.
Although ICMPv6 is not affected, this diff renames p_hdrlen in
divert6_output() to min_hdrlen as well to be consistent with
divert_output().
ok?
Index: netinet/ip_divert.c
===
RCS file: /cvs/src/sys/netinet/ip_divert.c,v
retrieving revision 1.26
diff -u -p -r1.26 ip_divert.c
--- netinet/ip_divert.c 12 Jul 2014 19:05:45 - 1.26
+++ netinet/ip_divert.c 13 Jul 2014 03:46:20 -
@@ -85,7 +85,7 @@ divert_output(struct inpcb *inp, struct
struct sockaddr_in *sin;
struct socket *so;
struct ifaddr *ifa;
- int s, error = 0, p_hdrlen = 0, dir;
+ int s, error = 0, min_hdrlen = 0, dir;
struct ip *ip;
u_int16_t off;
@@ -119,22 +119,22 @@ divert_output(struct inpcb *inp, struct
switch (ip-ip_p) {
case IPPROTO_TCP:
- p_hdrlen = sizeof(struct tcphdr);
+ min_hdrlen = sizeof(struct tcphdr);
m-m_pkthdr.csum_flags |= M_TCP_CSUM_OUT;
break;
case IPPROTO_UDP:
- p_hdrlen = sizeof(struct udphdr);
+ min_hdrlen = sizeof(struct udphdr);
m-m_pkthdr.csum_flags |= M_UDP_CSUM_OUT;
break;
case IPPROTO_ICMP:
- p_hdrlen = sizeof(struct icmp);
+ min_hdrlen = ICMP_MINLEN;
m-m_pkthdr.csum_flags |= M_ICMP_CSUM_OUT;
break;
default:
/* nothing */
break;
}
- if (p_hdrlen m-m_pkthdr.len off + p_hdrlen)
+ if (min_hdrlen m-m_pkthdr.len off + min_hdrlen)
goto fail;
m-m_pkthdr.pf.flags |= PF_TAG_DIVERTED_PACKET;
Index: netinet6/ip6_divert.c
===
RCS file: /cvs/src/sys/netinet6/ip6_divert.c,v
retrieving revision 1.27
diff -u -p -r1.27 ip6_divert.c
--- netinet6/ip6_divert.c 12 Jul 2014 19:05:45 - 1.27
+++ netinet6/ip6_divert.c 13 Jul 2014 03:46:20 -
@@ -89,7 +89,7 @@ divert6_output(struct inpcb *inp, struct
struct sockaddr_in6 *sin6;
struct socket *so;
struct ifaddr *ifa;
- int s, error = 0, p_hdrlen = 0, nxt = 0, off, dir;
+ int s, error = 0, min_hdrlen = 0, nxt = 0, off, dir;
struct ip6_hdr *ip6;
m-m_pkthdr.rcvif = NULL;
@@ -128,22 +128,22 @@ divert6_output(struct inpcb *inp, struct
switch (nxt) {
case IPPROTO_TCP:
- p_hdrlen = sizeof(struct tcphdr);
+ min_hdrlen = sizeof(struct tcphdr);
m-m_pkthdr.csum_flags |= M_TCP_CSUM_OUT;
break;
case IPPROTO_UDP:
- p_hdrlen = sizeof(struct udphdr);
+ min_hdrlen = sizeof(struct udphdr);
m-m_pkthdr.csum_flags |= M_UDP_CSUM_OUT;
break;
case IPPROTO_ICMPV6:
- p_hdrlen = sizeof(struct icmp6_hdr);
+ min_hdrlen = sizeof(struct icmp6_hdr);
m-m_pkthdr.csum_flags |= M_ICMP_CSUM_OUT;
break;
default:
/* nothing */
break;
}
- if (p_hdrlen m-m_pkthdr.len off + p_hdrlen)
+ if (min_hdrlen m-m_pkthdr.len off + min_hdrlen)
goto fail;
m-m_pkthdr.pf.flags |= PF_TAG_DIVERTED_PACKET;
