Re: TLS with static non-PIE binaries

On Mon, 6 Nov 2017, Charles Collicutt wrote: > On Sun, Nov 05, 2017 at 01:02:36PM -0800, Philip Guenther wrote: > > The problem with static non-PIE executables is that we don't pass an AUX > > vector to such processes, so the startup code can't find the TLS segment > > and doesn't leave any

Re: TLS with static non-PIE binaries

On Sun, Nov 05, 2017 at 01:02:36PM -0800, Philip Guenther wrote: > The problem with static non-PIE executables is that we don't pass an AUX > vector to such processes, so the startup code can't find the TLS segment > and doesn't leave any space for it. Ah, thank you. > The diff below fixes

Re: TLS with static non-PIE binaries

On Sun, 5 Nov 2017, Stuart Henderson wrote: > On 2017/11/05 21:08, Charles Collicutt wrote: > > Hello, > > > > I have a program that uses Thread-Local Storage (TLS) with the 'Local Exec' > > access model [1] on AMD64. This looks like it should work on OpenBSD and, > > indeed, it mostly does. > >

Re: panic when invalid randomness source is provided

On Sun, Nov 05, 2017 at 06:05:29PM +, Jasper Lievisse Adriaanse wrote: > Hi, > > Currently we appear to silently drop randomness if it comes from an invalid > source. Should we not panic in this case? > While here, update the comment for enqueue_randomness() after -r1.188. > > OK? Please

Re: TLS with static non-PIE binaries

The only "tls" support we have that's currently working is emulated tls, as exemplified by both clang and the gcc 4.9 port. See /usr/src/lib/libcompiler_rt/emutls.c for how it works. It's not incredibly fast, but it does the job... Fortunately, the gcc and clang people managed to make some

Re: TLS with static non-PIE binaries

On Mon, Nov 06, 2017 at 12:58:18AM +0200, Paul Irofti wrote: > We are missing dlopen-time TLS, dynamic TLS relocations and > thread storage-specifier support. Thanks. None of those things are needed for the Local Exec access model though, so that should be OK. Do you have any idea what might

Re: TLS with static non-PIE binaries

On Sun, Nov 05, 2017 at 10:51:41PM +, Charles Collicutt wrote: > On Sun, Nov 05, 2017 at 10:15:57PM +, Stuart Henderson wrote: > > On 2017/11/05 21:08, Charles Collicutt wrote: > > > I have a program that uses Thread-Local Storage (TLS) with the 'Local > > > Exec' > > > access model [1]

Re: TLS with static non-PIE binaries

On Sun, Nov 05, 2017 at 10:15:57PM +, Stuart Henderson wrote: > On 2017/11/05 21:08, Charles Collicutt wrote: > > I have a program that uses Thread-Local Storage (TLS) with the 'Local Exec' > > access model [1] on AMD64. This looks like it should work on OpenBSD and, > > indeed, it mostly

ifconfig tunnel: replace deletetunnel with -tunnel

most options use -something to undo something, do that for tunnel as well. makes the manpage nicer too. keep the deletetunnel option for two releases. If commited i will mention this in current.html. I dont think it will cause problems on boot because i dont expect the "deletetunnel" to be used

xhci: dequeue isoc trbs events on under/overrun

Hi, This is a first step towards hopefully getting uvideo(4) to work with xhci(4). On my x260 I get buffer overrun and my machine freezes when running video(1) with xhci and uvideo debug messages enabled. Following fixes that. The proposed diff handles event under/overruns by dequeueing the

Re: TLS with static non-PIE binaries

On 2017/11/05 21:08, Charles Collicutt wrote: > Hello, > > I have a program that uses Thread-Local Storage (TLS) with the 'Local Exec' > access model [1] on AMD64. This looks like it should work on OpenBSD and, > indeed, it mostly does. OpenBSD doesn't have real thread-local storage yet.

iked: load explicit flows for ipip/ipcomp

Hi, for IPcomp we need to load explicit ESP-flows for the IPIP or IPCOMP tunneled packets, otherwise every packet between the gateways will be sent into the tunnel (e.g. ICMP, too). ok? Patrick diff --git a/sbin/iked/ikev2.c b/sbin/iked/ikev2.c index 706f9ebbe1d..cacfe690008 100644 ---

Re: vmd: add minimal DHCP support

On Thu, Nov 02, 2017 at 10:26:55PM +0100, Reyk Floeter wrote: > Hi, > > the problem got reported a few times and a similar diff was floating > around: vmd's "local interface" implements a simple auto-magic BOOTP > server, but udhcpc doesn't support BOOTP, which is the predecessor and > a valid

ifconfig giftunnel was deprecated in 2001

ok? Index: ifconfig.c === RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v retrieving revision 1.349 diff -u -p -r1.349 ifconfig.c --- ifconfig.c 30 Oct 2017 10:04:07 - 1.349 +++ ifconfig.c 5 Nov 2017 20:06:57 - @@

panic when invalid randomness source is provided

Hi, Currently we appear to silently drop randomness if it comes from an invalid source. Should we not panic in this case? While here, update the comment for enqueue_randomness() after -r1.188. OK? Index: rnd.c === RCS file:

Re: forbid config reloads in ospf6d

On Sun, Nov 05, 2017 at 06:19:12PM +0100, Jeremie Courreges-Anglas wrote: > On Sun, Nov 05 2017, Jeremie Courreges-Anglas wrote: > > ospf6d consistently fails when I ask it to reload its config, even > > though I have a very basic test setup: > > > > area 0.0.0.0 { > >

Re: forbid config reloads in ospf6d

On Sun, Nov 05 2017, Jeremie Courreges-Anglas wrote: > ospf6d consistently fails when I ask it to reload its config, even > though I have a very basic test setup: > > area 0.0.0.0 { > interface em0 { passive } > interface vether0 > } > > Fixing ospf6d doesn't seem

Re: ieee80211: disable wpa/wep when changing nwid

On Sun, Nov 05, 2017 at 05:57:25PM +0100, Peter Hessler wrote: > Changing nwid on a wifi network means it is a new network. By definition > the WPA crypto keys use the nwid as part of the crypto hash. And it is > super unlikely that a differently named network will have the same WEP > key. In

Re: Wrong rule number in pflog with anchors

"trondd" wrote: > If you have an anchor in your pf ruleset, a packet that matches a rule > with a log directive will reflect the rule number of the last anchor > definition instead of the rule that caused the logging. > > My first rule in pf.conf is 'block log (all)

Re: ieee80211: disable wpa/wep when changing nwid

On Sun, Nov 05, 2017 at 05:57:25PM +0100, Peter Hessler wrote: > Changing nwid on a wifi network means it is a new network. By definition > the WPA crypto keys use the nwid as part of the crypto hash. And it is > super unlikely that a differently named network will have the same WEP > key. In

ieee80211: disable wpa/wep when changing nwid

Changing nwid on a wifi network means it is a new network. By definition the WPA crypto keys use the nwid as part of the crypto hash. And it is super unlikely that a differently named network will have the same WEP key. In that case, you can enter it again. With this, when you change wifi

Re: forbid config reloads in ospf6d

yep, ok Jeremie Courreges-Anglas(j...@wxcvbn.org) on 2017.11.05 15:50:42 +0100: > > ospf6d consistently fails when I ask it to reload its config, even > though I have a very basic test setup: > > area 0.0.0.0 { > interface em0 { passive } > interface vether0 > } > > Fixing

Re: forbid config reloads in ospf6d

Ok (for what it's worth). On Sun, Nov 05, 2017 at 03:50:42PM +0100, Jeremie Courreges-Anglas wrote: > > ospf6d consistently fails when I ask it to reload its config, even > though I have a very basic test setup: > > area 0.0.0.0 { > interface em0 { passive } > interface vether0

Re: forbid config reloads in ospf6d

OK On 2017 Nov 05 (Sun) at 15:50:42 +0100 (+0100), Jeremie Courreges-Anglas wrote: : :ospf6d consistently fails when I ask it to reload its config, even :though I have a very basic test setup: : :area 0.0.0.0 { :interface em0 { passive } :interface vether0 :} : :Fixing ospf6d

forbid config reloads in ospf6d

ospf6d consistently fails when I ask it to reload its config, even though I have a very basic test setup: area 0.0.0.0 { interface em0 { passive } interface vether0 } Fixing ospf6d doesn't seem trivial. Having it fail and exit doesn't seem to be a sufficient incentive, so I

Re: convert frag6 to mutex

please ignore this one, mpi points out that visa has a more comprehensive diff for this that I missed. -- I'm not entirely sure you are real.

[PATCH] amd64/bsd.rd: add growfs(8)

Goodmorning everyone, While quite some resizing scenarios can be done from within single user mode, resizing the root partition requires you to bring your own growfs(8) binary into the ramdisk environment. The below patch adds growfs(8) to the amd64 ramdisk to simplify such operations. I tested