Re: clang ld.so regress failures

[Ted Unangst]

Mark Kettenis wrote:
> FAIL libexec/ld.so/dlclose/test1/prog3/prog3
> 
>   This fails because clang doesn't respect ELF interposition:
> 
> http://lists.llvm.org/pipermail/llvm-dev/2016-November/107625.html
> 
>   We generally frown upon interposition so I can have some sympathy
>   for their position here.  Probably not a huge issue in practice.
>   But we still want to test the ld.so functionality.

would this affect, for example, a program's ability to override
malloc/free/etc? i'm trying to understand what's not working (or what will not
work). it sounds like i can override malloc in my program, but clang/llvm will
generate "tight" (not sure of the word) bindings to libc malloc within libc?
although this would probably only manifest within translation units with
inlining?

Re: armv7 void x_intr() vs int x_intr()

[Artturi Alm]

On Tue, Aug 01, 2017 at 08:09:01PM -0600, Theo de Raadt wrote:
> > (i'm not pointing out the obvious hz*2 'issue' here i think we have on 
> > armv7;).
> 
> You are missing another detail.
> 

hmmph, and that is?
puzzled.
-Artturi

Re: armv7 void x_intr() vs int x_intr()

[Theo de Raadt]

> (i'm not pointing out the obvious hz*2 'issue' here i think we have on 
> armv7;).

You are missing another detail.

pf.c Pflow TOS zeroed out

[Sam Taufa]

Hi,

We've been maintaining this small patch since 5.8 and it seems to work 
as expected but could be wrong.


Unpatched Behaviour:

* netflow always shows TOS values as 0

Patched behaviour:

* netflow now shows a TOS value when either set by the PF rule, or if 
packet originally had the


Index: pf.c
===
RCS file: /cvs/src/sys/net/pf.c,v
retrieving revision 1.1037
diff -u -p -r1.1037 pf.c
--- pf.c4 Jul 2017 14:10:15 -1.1037
+++ pf.c2 Aug 2017 00:51:34 -
@@ -2756,7 +2756,7 @@ pf_build_tcp(const struct pf_rule *r, sa
 h->ip_len = htons(tlen);
 h->ip_v = 4;
 h->ip_hl = sizeof(*h) >> 2;
-h->ip_tos = IPTOS_LOWDELAY;
+h->ip_tos = r->tos;
 h->ip_len = htons(len);
 h->ip_off = htons(ip_mtudisc ? IP_DF : 0);
 h->ip_ttl = ttl ? ttl : ip_defttl;

Index: pf.c
===
RCS file: /cvs/src/sys/net/pf.c,v
retrieving revision 1.1037
diff -u -p -r1.1037 pf.c
--- pf.c4 Jul 2017 14:10:15 -   1.1037
+++ pf.c2 Aug 2017 00:51:34 -
@@ -2756,7 +2756,7 @@ pf_build_tcp(const struct pf_rule *r, sa
h->ip_len = htons(tlen);
h->ip_v = 4;
h->ip_hl = sizeof(*h) >> 2;
-   h->ip_tos = IPTOS_LOWDELAY;
+   h->ip_tos = r->tos;
h->ip_len = htons(len);
h->ip_off = htons(ip_mtudisc ? IP_DF : 0);
h->ip_ttl = ttl ? ttl : ip_defttl;

dhcpd: remove unused structs

[Rob Pierce]

I can confirm that the following structs have not been used since at least
OpenBSD 4.9. From Edgar Pettijohn.

Ok?

Index: dhcpd.h
===
RCS file: /cvs/src/usr.sbin/dhcpd/dhcpd.h,v
retrieving revision 1.65
diff -u -p -r1.65 dhcpd.h
--- dhcpd.h 31 Jul 2017 19:00:40 -  1.65
+++ dhcpd.h 1 Aug 2017 22:41:34 -
@@ -73,25 +73,6 @@ struct option_data {
u_int8_t *data;
 };
 
-struct string_list {
-   struct string_list *next;
-   char *string;
-};
-
-/* A name server, from /etc/resolv.conf. */
-struct name_server {
-   struct name_server *next;
-   struct sockaddr_in addr;
-   time_t rcdate;
-};
-
-/* A domain search list element. */
-struct domain_search_list {
-   struct domain_search_list *next;
-   char *domain;
-   time_t rcdate;
-};
-
 /* A dhcp packet and the pointers to its option values. */
 struct packet {
struct dhcp_packet *raw;
@@ -294,12 +275,6 @@ struct interface_info {
int is_udpsock;
ssize_t (*send_packet)(struct interface_info *, struct dhcp_packet *,
size_t, struct in_addr, struct sockaddr_in *, struct hardware *);
-};
-
-struct hardware_link {
-   struct hardware_link *next;
-   char name[IFNAMSIZ];
-   struct hardware address;
 };
 
 struct dhcpd_timeout {

Re: armv7 void x_intr() vs int x_intr()

[Mark Kettenis]

> Date: Mon, 31 Jul 2017 16:30:07 +0300
> From: Artturi Alm 
> 
> Hi,
> 
> i've been annoyed by this inconsistency for years, and was wondering
> if someone would have the time to explain why it is the way it is, or
> give me any advice towards the correct fixes.
> 
> i'll just copypaste some lines of code that should show what i mean:
> 
> #define ARM_IRQ_HANDLER arm_intr
> 
> ASENTRY_NP(irq_entry)
> ...
>   bl  ARM_IRQ_HANDLER
> ... no r0 usage ...
> 
> void (*arm_intr_dispatch)(void *) = arm_dflt_intr;
> 
> void
> arm_intr(void *frame)
> {
>   /* XXX - change this to have irq_dispatch use function pointer */
>   (*arm_intr_dispatch)(frame);
> }
> 
> int
> agtimer_intr(void *frame)
> {
> ... conditionally set the useless rc ...
>   return (rc);
> }
> 
> go void?

Interrupt handlers return int such that they can be counted.  You're
missing the actual interrupt control implementtation in your analysis.

Is this overengineered?  Yes.  Is this worth fixing?  No.

Re: ifstated diff: handling interface depature/arrival

[Rob Pierce]

On Mon, Jul 31, 2017 at 05:59:46PM -0400, Rob Pierce wrote:
> Good evening all,
> 
> Currently, ifstated does not detect the removal of an IFT_CARP pseudo device.
> As such, you can delete a carp interface and have ifstated happily remain in
> the current state without detecting any interface change.
> 
> The reasons are two fold:
> 
> 1. The routing socket is only monitored for RTM_IFINFO messages and therefore
>misses interface departure and arrival events. On an interface departure,
>for example, there is only one RTM_IFINFO message, and that particular
>message identifies the departed (carp) interface as up and master.
> 
> 2. As I have recently discovered, LINK_STATE_UNKNOWN is equivalent to
>LINK_STATE_UP, so even if a removal was detected, the state change would go
>unnoticed (i.e. there would be no state change). I ran into this while
>trying to address (1).
> 
> The following diff resolves this problem by adding RTM_IFANNOUNCE to the
> routing socket filter, and the route message handler now handles interface
> departures and arrivals. Upon departure, a rescan is performed with a (forced)
> state of LINK_STATE_DOWN, and upon the arrival of a previously configured
> pseudo device the interface is re-indexed and a rescan is performed with the
> actual interface state.
> 
> I have also updated the regression test to cover carp interface departure and
> arrival (diff included for testing convenience).
> 
> At this stage I am only looking for general comments on the approach and/or
> some testing if you are an ifstated user.
> 
> For example, maybe it is unnecessary to save and check the interface type,
> assuming that interface departure and arrival will always be on a (supported)
> pseudo device (e.g. IFT_CARP), and actual physical interfaces will not behave
> in this manner. Also, ifi_type is not available via an ioctl under pledge, so
> obtaining this information dynamically through routing messages may be a bit
> of a hack.
> 
> Thanks and regards,
> 
> Rob

I need to rethink this approach. A departing interface must be handled
appropriately, but the arrival of a new interface is problematic as we really
need to confirm that the interface is configured exactly as expected (i.e. as
it was prior to departure).

Pledge currently prevents us from obtaining some of that information upon
arrival for comparison purposes (e.g. SIOCGVH). This will also be an issue on
reload under the current design, as interface parameters are not inherently
addressed - only their state is considered.

Maybe a simpler diff that only handles interface departure would be better,
with the assumption that the interface will not come back, and indeed is not
permitted to return after departure. This would at least ensure that a
fail-over was handled appropriately within a pair of CARPed firewealls on
interface departure. The departing interface would need to be re-configured
and ifstated restarted in order for that host to return to a normal operating
state.

Rob

> 
> Index: src/usr.sbin/ifstated/ifstated.c
> ===
> RCS file: /cvs/src/usr.sbin/ifstated/ifstated.c,v
> retrieving revision 1.56
> diff -u -p -r1.56 ifstated.c
> --- src/usr.sbin/ifstated/ifstated.c  24 Jul 2017 12:33:59 -  1.56
> +++ src/usr.sbin/ifstated/ifstated.c  31 Jul 2017 20:48:42 -
> @@ -28,6 +28,7 @@
>  #include 
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -73,6 +74,8 @@ voiddo_action(struct ifsd_action *);
>  void remove_action(struct ifsd_action *, struct ifsd_state *);
>  void remove_expression(struct ifsd_expression *,
>   struct ifsd_state *);
> +void set_iftype(int, u_char);
> +void reindex_if(int, char *);
>  
>  __dead void
>  usage(void)
> @@ -149,7 +152,7 @@ main(int argc, char *argv[])
>   if ((rt_fd = socket(PF_ROUTE, SOCK_RAW, 0)) < 0)
>   err(1, "no routing socket");
>  
> - rtfilter = ROUTE_FILTER(RTM_IFINFO);
> + rtfilter = ROUTE_FILTER(RTM_IFINFO) | ROUTE_FILTER(RTM_IFANNOUNCE);
>   if (setsockopt(rt_fd, PF_ROUTE, ROUTE_MSGFILTER,
>   , sizeof(rtfilter)) == -1) /* not fatal */
>   log_warn("%s: setsockopt msgfilter", __func__);
> @@ -231,24 +234,79 @@ void
>  rt_msg_handler(int fd, short event, void *arg)
>  {
>   char msg[2048];
> + char ifname[IFNAMSIZ];
>   struct rt_msghdr *rtm = (struct rt_msghdr *)
>   struct if_msghdr ifm;
> + struct if_announcemsghdr ifan;
> + struct ifaddrs *ifap, *ifa;
>   ssize_t len;
>  
>   len = read(fd, msg, sizeof(msg));
>  
>   /* XXX ignore errors? */
> - if (len < sizeof(struct rt_msghdr))
> + if ((size_t)len < sizeof(rtm->rtm_msglen) || len < rtm->rtm_msglen)
>   return;
>  
>   if (rtm->rtm_version != RTM_VERSION)
>   return;
>  
> - if (rtm->rtm_type != RTM_IFINFO)
> - return;
> -
> -

Re: em: workaround for ultra-low-power mode on i219V

[Bryan Steele]

On Tue, Aug 01, 2017 at 05:56:54PM +0200, Stefan Fritsch wrote:
> Hi,
> 
> we have the problem that on some HP laptops with i219V, it sometimes 
> happens that em fails to attach with this error:
> 
> em0: Hardware Initialization Failed
> em0: Unable to initialize the hardware
> 
> It seems there was some previous discussion of this issue here: 
> http://bugs.openbsd.narkive.com/95VRrEJX/hardware-initialization-failed-with-intel-i219-v
> 
> The most reliable way to reproduce it is by booting Windows 10 first and 
> then rebooting into openbsd without switching the laptop off. But 
> sometimes, it also happens without having booted Windows first. Also, we 
> had a case where the broken state persisted even if the laptop was 
> switched off for a short time.  After the laptop had been switched off for 
> several minutes, it worked again.
> 
> We have never seen the problem with i219LM (both on Fujitsu and HP 
> laptops).
> 
> The attached patch seems to fix the problem. It ports the 
> e1000_disable_ulp_lpt_lp() logic from the FreeBSD driver to disable 
> ultra-low-power (ULP) mode.
> 
> The code has been merged in a way to make the diff from FreeBSD minimal.  
> For example, the SWFW register is called H2ME on newer chips, so a new 
> define is introduced. Also, the em_toggle_lanphypc_pch_lpt() function is 
> left as separate function even though only used in one place at the 
> moment.
> 
> 
> For consumer NICs, the patch only does something on I218_LM_3/I218_V_3 or 
> I219* or newer.  I am not quite sure which server chips are matching 
> em_pch_spt. Testers, comments, OKs are welcome.
> 
> Cheers,
> Stefan
> 
> diff --git a/sys/dev/pci/if_em_hw.c b/sys/dev/pci/if_em_hw.c
> index d108555..8b3a0a0 100644
> --- a/sys/dev/pci/if_em_hw.c
> +++ b/sys/dev/pci/if_em_hw.c
> @@ -93,6 +93,8 @@ static int32_t  em_init_lcd_from_nvm(struct em_hw *);
>  static int32_t   em_phy_no_cable_workaround(struct em_hw *);
>  static void  em_init_rx_addrs(struct em_hw *);
>  static void  em_initialize_hardware_bits(struct em_hw *);
> +static void  em_toggle_lanphypc_pch_lpt(struct em_hw *);
> +static int   em_disable_ulp_lpt_lp(struct em_hw *hw, bool force);
>  static boolean_t em_is_onboard_nvm_eeprom(struct em_hw *);
>  static int32_t   em_kumeran_lock_loss_workaround(struct em_hw *);
>  static int32_t   em_mng_enable_host_if(struct em_hw *);
> @@ -1194,6 +1196,192 @@ em_initialize_hardware_bits(struct em_hw *hw)
>   }
>  }
>  
> +/**
> + *  e1000_toggle_lanphypc_pch_lpt - toggle the LANPHYPC pin value
> + *  @hw: pointer to the HW structure
> + *
> + *  Toggling the LANPHYPC pin value fully power-cycles the PHY and is
> + *  used to reset the PHY to a quiescent state when necessary.
> + **/
> +static void
> +em_toggle_lanphypc_pch_lpt(struct em_hw *hw)
> +{
> + uint32_t mac_reg;
> +
> + DEBUGFUNC("e1000_toggle_lanphypc_pch_lpt");
> +
> + /* Set Phy Config Counter to 50msec */
> + mac_reg = E1000_READ_REG(hw, FEXTNVM3);
> + mac_reg &= ~E1000_FEXTNVM3_PHY_CFG_COUNTER_MASK;
> + mac_reg |= E1000_FEXTNVM3_PHY_CFG_COUNTER_50MSEC;
> + E1000_WRITE_REG(hw, FEXTNVM3, mac_reg);
> +
> + /* Toggle LANPHYPC Value bit */
> + mac_reg = E1000_READ_REG(hw, CTRL);
> + mac_reg |= E1000_CTRL_LANPHYPC_OVERRIDE;
> + mac_reg &= ~E1000_CTRL_LANPHYPC_VALUE;
> + E1000_WRITE_REG(hw, CTRL, mac_reg);
> + E1000_WRITE_FLUSH(hw);
> + msec_delay(1);
> + mac_reg &= ~E1000_CTRL_LANPHYPC_OVERRIDE;
> + E1000_WRITE_REG(hw, CTRL, mac_reg);
> + E1000_WRITE_FLUSH(hw);
> +
> + if (hw->mac_type < em_pch_lpt) {
> + msec_delay(50);
> + } else {
> + uint16_t count = 20;
> +
> + do {
> + msec_delay(5);
> + } while (!(E1000_READ_REG(hw, CTRL_EXT) &
> + E1000_CTRL_EXT_LPCD) && count--);
> +
> + msec_delay(30);
> + }
> +}
> +
> +/**
> + *  em_disable_ulp_lpt_lp - unconfigure Ultra Low Power mode for LynxPoint-LP
> + *  @hw: pointer to the HW structure
> + *  @force: boolean indicating whether or not to force disabling ULP
> + *
> + *  Un-configure ULP mode when link is up, the system is transitioned from
> + *  Sx or the driver is unloaded.  If on a Manageability Engine (ME) enabled
> + *  system, poll for an indication from ME that ULP has been un-configured.
> + *  If not on an ME enabled system, un-configure the ULP mode by software.
> + *
> + *  During nominal operation, this function is called when link is acquired
> + *  to disable ULP mode (force=FALSE); otherwise, for example when unloading
> + *  the driver or during Sx->S0 transitions, this is called with force=TRUE
> + *  to forcibly disable ULP.
> + */
> +static int
> +em_disable_ulp_lpt_lp(struct em_hw *hw, bool force)
> +{
> + int ret_val = E1000_SUCCESS;
> + uint32_t mac_reg;
> + uint16_t phy_reg;
> + int i = 0;
> +
> + if ((hw->mac_type < em_pch_lpt) ||
> + (hw->device_id == 

em: workaround for ultra-low-power mode on i219V

[Stefan Fritsch]

Hi,

we have the problem that on some HP laptops with i219V, it sometimes 
happens that em fails to attach with this error:

em0: Hardware Initialization Failed
em0: Unable to initialize the hardware

It seems there was some previous discussion of this issue here: 
http://bugs.openbsd.narkive.com/95VRrEJX/hardware-initialization-failed-with-intel-i219-v

The most reliable way to reproduce it is by booting Windows 10 first and 
then rebooting into openbsd without switching the laptop off. But 
sometimes, it also happens without having booted Windows first. Also, we 
had a case where the broken state persisted even if the laptop was 
switched off for a short time.  After the laptop had been switched off for 
several minutes, it worked again.

We have never seen the problem with i219LM (both on Fujitsu and HP 
laptops).

The attached patch seems to fix the problem. It ports the 
e1000_disable_ulp_lpt_lp() logic from the FreeBSD driver to disable 
ultra-low-power (ULP) mode.

The code has been merged in a way to make the diff from FreeBSD minimal.  
For example, the SWFW register is called H2ME on newer chips, so a new 
define is introduced. Also, the em_toggle_lanphypc_pch_lpt() function is 
left as separate function even though only used in one place at the 
moment.


For consumer NICs, the patch only does something on I218_LM_3/I218_V_3 or 
I219* or newer.  I am not quite sure which server chips are matching 
em_pch_spt. Testers, comments, OKs are welcome.

Cheers,
Stefan

diff --git a/sys/dev/pci/if_em_hw.c b/sys/dev/pci/if_em_hw.c
index d108555..8b3a0a0 100644
--- a/sys/dev/pci/if_em_hw.c
+++ b/sys/dev/pci/if_em_hw.c
@@ -93,6 +93,8 @@ static int32_tem_init_lcd_from_nvm(struct em_hw *);
 static int32_t em_phy_no_cable_workaround(struct em_hw *);
 static voidem_init_rx_addrs(struct em_hw *);
 static voidem_initialize_hardware_bits(struct em_hw *);
+static voidem_toggle_lanphypc_pch_lpt(struct em_hw *);
+static int em_disable_ulp_lpt_lp(struct em_hw *hw, bool force);
 static boolean_t em_is_onboard_nvm_eeprom(struct em_hw *);
 static int32_t em_kumeran_lock_loss_workaround(struct em_hw *);
 static int32_t em_mng_enable_host_if(struct em_hw *);
@@ -1194,6 +1196,192 @@ em_initialize_hardware_bits(struct em_hw *hw)
}
 }
 
+/**
+ *  e1000_toggle_lanphypc_pch_lpt - toggle the LANPHYPC pin value
+ *  @hw: pointer to the HW structure
+ *
+ *  Toggling the LANPHYPC pin value fully power-cycles the PHY and is
+ *  used to reset the PHY to a quiescent state when necessary.
+ **/
+static void
+em_toggle_lanphypc_pch_lpt(struct em_hw *hw)
+{
+   uint32_t mac_reg;
+
+   DEBUGFUNC("e1000_toggle_lanphypc_pch_lpt");
+
+   /* Set Phy Config Counter to 50msec */
+   mac_reg = E1000_READ_REG(hw, FEXTNVM3);
+   mac_reg &= ~E1000_FEXTNVM3_PHY_CFG_COUNTER_MASK;
+   mac_reg |= E1000_FEXTNVM3_PHY_CFG_COUNTER_50MSEC;
+   E1000_WRITE_REG(hw, FEXTNVM3, mac_reg);
+
+   /* Toggle LANPHYPC Value bit */
+   mac_reg = E1000_READ_REG(hw, CTRL);
+   mac_reg |= E1000_CTRL_LANPHYPC_OVERRIDE;
+   mac_reg &= ~E1000_CTRL_LANPHYPC_VALUE;
+   E1000_WRITE_REG(hw, CTRL, mac_reg);
+   E1000_WRITE_FLUSH(hw);
+   msec_delay(1);
+   mac_reg &= ~E1000_CTRL_LANPHYPC_OVERRIDE;
+   E1000_WRITE_REG(hw, CTRL, mac_reg);
+   E1000_WRITE_FLUSH(hw);
+
+   if (hw->mac_type < em_pch_lpt) {
+   msec_delay(50);
+   } else {
+   uint16_t count = 20;
+
+   do {
+   msec_delay(5);
+   } while (!(E1000_READ_REG(hw, CTRL_EXT) &
+   E1000_CTRL_EXT_LPCD) && count--);
+
+   msec_delay(30);
+   }
+}
+
+/**
+ *  em_disable_ulp_lpt_lp - unconfigure Ultra Low Power mode for LynxPoint-LP
+ *  @hw: pointer to the HW structure
+ *  @force: boolean indicating whether or not to force disabling ULP
+ *
+ *  Un-configure ULP mode when link is up, the system is transitioned from
+ *  Sx or the driver is unloaded.  If on a Manageability Engine (ME) enabled
+ *  system, poll for an indication from ME that ULP has been un-configured.
+ *  If not on an ME enabled system, un-configure the ULP mode by software.
+ *
+ *  During nominal operation, this function is called when link is acquired
+ *  to disable ULP mode (force=FALSE); otherwise, for example when unloading
+ *  the driver or during Sx->S0 transitions, this is called with force=TRUE
+ *  to forcibly disable ULP.
+ */
+static int
+em_disable_ulp_lpt_lp(struct em_hw *hw, bool force)
+{
+   int ret_val = E1000_SUCCESS;
+   uint32_t mac_reg;
+   uint16_t phy_reg;
+   int i = 0;
+
+   if ((hw->mac_type < em_pch_lpt) ||
+   (hw->device_id == E1000_DEV_ID_PCH_LPT_I217_LM) ||
+   (hw->device_id == E1000_DEV_ID_PCH_LPT_I217_V) ||
+   (hw->device_id == E1000_DEV_ID_PCH_I218_LM2) ||
+   (hw->device_id == E1000_DEV_ID_PCH_I218_V2))
+   return 0;
+
+   if (E1000_READ_REG(hw, 

Re: clang ld.so regress failures

[Joerg Sonnenberger]

On Tue, Aug 01, 2017 at 04:46:17PM +0200, Mark Kettenis wrote:
> FAIL libexec/ld.so/dlclose/test1/prog3/prog3
> 
>   This fails because clang doesn't respect ELF interposition:
> 
> http://lists.llvm.org/pipermail/llvm-dev/2016-November/107625.html
> 
>   We generally frown upon interposition so I can have some sympathy
>   for their position here.  Probably not a huge issue in practice.
>   But we still want to test the ld.so functionality.

Mark bbLazyFun with attribute noinline? Maybe also add an explicitly
memory clobber to it. _dl_debug_state in ld.so is likely only safe
because it is not called from the same translation unit, but you might
want to add the same there.

> FAIL libexec/ld.so/constructor/prog1/prog1
> FAIL libexec/ld.so/constructor/prog2/prog2
> FAIL libexec/ld.so/initfirst/test2/prog1/prog1
> FAIL libexec/ld.so/initfirst/test2/prog2/prog2
> FAIL libexec/ld.so/init-env/prog/prog
> 
>   These fail because libc++ doesn't support using stdio in
>   constructors.  Probably a bug:
> 
> https://reviews.llvm.org/D12689

Not stdio, but standard streams. Small but important difference. Using
printf and co should be fine here.

Joerg

clang ld.so regress failures

[Mark Kettenis]

Here is my analysis of the ld.so regress failures.  None of the
actually suggests that there is a bug in ld.so.

Cheers,

Mark


FAIL libexec/ld.so/dlclose/test1/prog3/prog3

  This fails because clang doesn't respect ELF interposition:

http://lists.llvm.org/pipermail/llvm-dev/2016-November/107625.html

  We generally frown upon interposition so I can have some sympathy
  for their position here.  Probably not a huge issue in practice.
  But we still want to test the ld.so functionality.

FAIL libexec/ld.so/constructor/prog1/prog1
FAIL libexec/ld.so/constructor/prog2/prog2
FAIL libexec/ld.so/initfirst/test2/prog1/prog1
FAIL libexec/ld.so/initfirst/test2/prog2/prog2
FAIL libexec/ld.so/init-env/prog/prog

  These fail because libc++ doesn't support using stdio in
  constructors.  Probably a bug:

https://reviews.llvm.org/D12689

FAIL libexec/ld.so/randomdata/prog-dynamic/prog
FAIL libexec/ld.so/randomdata/prog-static/prog
FAIL libexec/ld.so/randomdata/prog-pie/prog

  See the .openbsd.randomdata discussion.

Re: caesar(6) documents incorrect frequencies

[Theo de Raadt]

> No ones agree,

I think you are mistaken.

This is not an exact science, it is an approximation.  However one of
there is well-known, and the others are calculation-de-jour.

Re: caesar(6) documents incorrect frequencies

[sven falempin]

On Tue, Aug 1, 2017 at 9:49 AM, Theo de Raadt  wrote:
>> > Is it possible you've got the fix backwards?  I think ETAONRISHetc is
>> > from some well-known research, but ETSAOR* is brand new and even google
>> > cannot find a reference to that ordering.  It seems there is a bug here,
>> > but is it perhaps the other frequency table?
>>
>> I certainly don't claim to know which frequencies are more accurate.
>> Does anyone have a preferred source for which percentages to use?
>
> I suggest a google search for ETAONRISH, which leads to a handful of
> references from 1960, 1963, etc.  Of course it is only an estimate, and
> will vary between regions and countries EH?
>
> I think that frequency order is still the most accepted.
>

No ones agree,

Wikipedia : compares to < eotha sinrd luymw fgcbp kvjqxz of modern
English > ( https://en.wikipedia.org/wiki/Letter_frequency )

from: 
http://www.math.ucsd.edu/~crypto/Projects/MarshaMoreno/TimeComparisonFrequency.pdf

Note the paper from wikipedia reference talk  english and use
the bible ???

The tables can be sorted and gave : ETAOINSHR DLC ...



Meh

-- 
--
-
Knowing is not enough; we must apply. Willing is not enough; we must do

Re: caesar(6) documents incorrect frequencies

[Theo de Raadt]

> > Is it possible you've got the fix backwards?  I think ETAONRISHetc is
> > from some well-known research, but ETSAOR* is brand new and even google
> > cannot find a reference to that ordering.  It seems there is a bug here,
> > but is it perhaps the other frequency table?
> 
> I certainly don't claim to know which frequencies are more accurate.
> Does anyone have a preferred source for which percentages to use?

I suggest a google search for ETAONRISH, which leads to a handful of
references from 1960, 1963, etc.  Of course it is only an estimate, and
will vary between regions and countries EH?

I think that frequency order is still the most accepted.

Re: caesar(6) documents incorrect frequencies

[Matthew Martin]

On Tue, Aug 01, 2017 at 07:38:28AM -0600, Theo de Raadt wrote:
> > On Tue, Aug 01, 2017 at 07:28:39AM -0600, Theo de Raadt wrote:
> > > I've known about ETAONRISHetc basically forever.  Where is this new
> > > order (ETSAORINDHLCPMUYFWGBVKXQZJ) coming from.
> > > 
> > > Citation please?
> > 
> > I'm just updating the man page to reflect the percentages in caesar.c
> > which claims to get it's numbers from "some unix(tm) documentation".
> 
> Is it possible you've got the fix backwards?  I think ETAONRISHetc is
> from some well-known research, but ETSAOR* is brand new and even google
> cannot find a reference to that ordering.  It seems there is a bug here,
> but is it perhaps the other frequency table?

I certainly don't claim to know which frequencies are more accurate.
Does anyone have a preferred source for which percentages to use?

- Matthew Martin

Re: caesar(6) documents incorrect frequencies

[Theo de Raadt]

> On Tue, Aug 01, 2017 at 07:28:39AM -0600, Theo de Raadt wrote:
> > I've known about ETAONRISHetc basically forever.  Where is this new
> > order (ETSAORINDHLCPMUYFWGBVKXQZJ) coming from.
> > 
> > Citation please?
> 
> I'm just updating the man page to reflect the percentages in caesar.c
> which claims to get it's numbers from "some unix(tm) documentation".

Is it possible you've got the fix backwards?  I think ETAONRISHetc is
from some well-known research, but ETSAOR* is brand new and even google
cannot find a reference to that ordering.  It seems there is a bug here,
but is it perhaps the other frequency table?
 
> - Matthew Martin
> 
> > > On Tue, Aug 01, 2017 at 09:36:13AM +0100, Jason McIntyre wrote:
> > > > On Thu, Jul 27, 2017 at 01:36:15AM -0500, Matthew Martin wrote:
> > > > > The man page documents frequencies that are different than the code
> > > > > uses e.g. C (3.61 vs 2.7) and D (4.78 vs 3.8). This seems a bit much 
> > > > > for
> > > > > a man page. If anyone prefers the letter ordering be kept, the correct
> > > > > order is ETSAORINDHLCPMUYFWGBVKXQZJ .
> > > > > 
> > > > > - Matthew Martin
> > > > > 
> > > > 
> > > > morning.
> > > > 
> > > > i don;t see what harm there is in providing this information. the man
> > > > page itself is hardly a huge read, and who knows whether someome might
> > > > find it useful.
> > > > 
> > > > i'd be willing to commit a diff which updates the man page.
> > > > 
> > > > jmc
> > > 
> > > Morning
> > > 
> > > I assumed someone who cared to know the frequencies would open the
> > > source, and removing them means there's is one less thing to get out of
> > > sync. But I have no strong opinion here.
> > > 
> > > - Matthew Martin
> > > 
> > > 
> > > diff --git caesar.6 caesar.6
> > > index 9dc040a7a6d..94ad082327e 100644
> > > --- caesar.6
> > > +++ caesar.6
> > > @@ -64,13 +64,13 @@ their content.
> > >  .Pp
> > >  The frequency (from most common to least) of English letters is as 
> > > follows:
> > >  .Bd -filled -offset indent
> > > -ETAONRISHDLFCMUGPYWBVKXJQZ
> > > +ETSAORINDHLCPMUYFWGBVKXQZJ
> > >  .Ed
> > >  .Pp
> > >  Their frequencies as a percentage are as follows:
> > >  .Bd -filled -offset indent
> > > -E(13), T(10.5), A(8.1), O(7.9), N(7.1), R(6.8), I(6.3), S(6.1), H(5.2),
> > > -D(3.8), L(3.4), F(2.9), C(2.7), M(2.5), U(2.4), G(2),
> > > -P(1.9), Y(1.9),
> > > -W(1.5), B(1.4), V(.9), K(.4), X(.15), J(.13), Q(.11), Z(.07).
> > > +E(12.37), T(9.68), S(8.77), A(7.97), O(6.96), R(6.63), I(6.39), N(5.92),
> > > +D(4.78), H(4.49), L(3.81), C(3.61), P(2.91), M(2.69), U(2.62), Y(2.07),
> > > +F(2.01), W(1.88), G(1.46), B(1.35), V(0.81), K(0.42), X(0.23), Q(0.08),
> > > +Z(0.06), J(0.04).
> > >  .Ed
> > > 
> > 
> 

Re: caesar(6) documents incorrect frequencies

[Matthew Martin]

On Tue, Aug 01, 2017 at 07:28:39AM -0600, Theo de Raadt wrote:
> I've known about ETAONRISHetc basically forever.  Where is this new
> order (ETSAORINDHLCPMUYFWGBVKXQZJ) coming from.
> 
> Citation please?

I'm just updating the man page to reflect the percentages in caesar.c
which claims to get it's numbers from "some unix(tm) documentation".

- Matthew Martin

> > On Tue, Aug 01, 2017 at 09:36:13AM +0100, Jason McIntyre wrote:
> > > On Thu, Jul 27, 2017 at 01:36:15AM -0500, Matthew Martin wrote:
> > > > The man page documents frequencies that are different than the code
> > > > uses e.g. C (3.61 vs 2.7) and D (4.78 vs 3.8). This seems a bit much for
> > > > a man page. If anyone prefers the letter ordering be kept, the correct
> > > > order is ETSAORINDHLCPMUYFWGBVKXQZJ .
> > > > 
> > > > - Matthew Martin
> > > > 
> > > 
> > > morning.
> > > 
> > > i don;t see what harm there is in providing this information. the man
> > > page itself is hardly a huge read, and who knows whether someome might
> > > find it useful.
> > > 
> > > i'd be willing to commit a diff which updates the man page.
> > > 
> > > jmc
> > 
> > Morning
> > 
> > I assumed someone who cared to know the frequencies would open the
> > source, and removing them means there's is one less thing to get out of
> > sync. But I have no strong opinion here.
> > 
> > - Matthew Martin
> > 
> > 
> > diff --git caesar.6 caesar.6
> > index 9dc040a7a6d..94ad082327e 100644
> > --- caesar.6
> > +++ caesar.6
> > @@ -64,13 +64,13 @@ their content.
> >  .Pp
> >  The frequency (from most common to least) of English letters is as follows:
> >  .Bd -filled -offset indent
> > -ETAONRISHDLFCMUGPYWBVKXJQZ
> > +ETSAORINDHLCPMUYFWGBVKXQZJ
> >  .Ed
> >  .Pp
> >  Their frequencies as a percentage are as follows:
> >  .Bd -filled -offset indent
> > -E(13), T(10.5), A(8.1), O(7.9), N(7.1), R(6.8), I(6.3), S(6.1), H(5.2),
> > -D(3.8), L(3.4), F(2.9), C(2.7), M(2.5), U(2.4), G(2),
> > -P(1.9), Y(1.9),
> > -W(1.5), B(1.4), V(.9), K(.4), X(.15), J(.13), Q(.11), Z(.07).
> > +E(12.37), T(9.68), S(8.77), A(7.97), O(6.96), R(6.63), I(6.39), N(5.92),
> > +D(4.78), H(4.49), L(3.81), C(3.61), P(2.91), M(2.69), U(2.62), Y(2.07),
> > +F(2.01), W(1.88), G(1.46), B(1.35), V(0.81), K(0.42), X(0.23), Q(0.08),
> > +Z(0.06), J(0.04).
> >  .Ed
> > 
> 

Re: caesar(6) documents incorrect frequencies

[Theo de Raadt]

I've known about ETAONRISHetc basically forever.  Where is this new
order (ETSAORINDHLCPMUYFWGBVKXQZJ) coming from.

Citation please?

> On Tue, Aug 01, 2017 at 09:36:13AM +0100, Jason McIntyre wrote:
> > On Thu, Jul 27, 2017 at 01:36:15AM -0500, Matthew Martin wrote:
> > > The man page documents frequencies that are different than the code
> > > uses e.g. C (3.61 vs 2.7) and D (4.78 vs 3.8). This seems a bit much for
> > > a man page. If anyone prefers the letter ordering be kept, the correct
> > > order is ETSAORINDHLCPMUYFWGBVKXQZJ .
> > > 
> > > - Matthew Martin
> > > 
> > 
> > morning.
> > 
> > i don;t see what harm there is in providing this information. the man
> > page itself is hardly a huge read, and who knows whether someome might
> > find it useful.
> > 
> > i'd be willing to commit a diff which updates the man page.
> > 
> > jmc
> 
> Morning
> 
> I assumed someone who cared to know the frequencies would open the
> source, and removing them means there's is one less thing to get out of
> sync. But I have no strong opinion here.
> 
> - Matthew Martin
> 
> 
> diff --git caesar.6 caesar.6
> index 9dc040a7a6d..94ad082327e 100644
> --- caesar.6
> +++ caesar.6
> @@ -64,13 +64,13 @@ their content.
>  .Pp
>  The frequency (from most common to least) of English letters is as follows:
>  .Bd -filled -offset indent
> -ETAONRISHDLFCMUGPYWBVKXJQZ
> +ETSAORINDHLCPMUYFWGBVKXQZJ
>  .Ed
>  .Pp
>  Their frequencies as a percentage are as follows:
>  .Bd -filled -offset indent
> -E(13), T(10.5), A(8.1), O(7.9), N(7.1), R(6.8), I(6.3), S(6.1), H(5.2),
> -D(3.8), L(3.4), F(2.9), C(2.7), M(2.5), U(2.4), G(2),
> -P(1.9), Y(1.9),
> -W(1.5), B(1.4), V(.9), K(.4), X(.15), J(.13), Q(.11), Z(.07).
> +E(12.37), T(9.68), S(8.77), A(7.97), O(6.96), R(6.63), I(6.39), N(5.92),
> +D(4.78), H(4.49), L(3.81), C(3.61), P(2.91), M(2.69), U(2.62), Y(2.07),
> +F(2.01), W(1.88), G(1.46), B(1.35), V(0.81), K(0.42), X(0.23), Q(0.08),
> +Z(0.06), J(0.04).
>  .Ed
> 

Re: caesar(6) documents incorrect frequencies

[Matthew Martin]

On Tue, Aug 01, 2017 at 09:36:13AM +0100, Jason McIntyre wrote:
> On Thu, Jul 27, 2017 at 01:36:15AM -0500, Matthew Martin wrote:
> > The man page documents frequencies that are different than the code
> > uses e.g. C (3.61 vs 2.7) and D (4.78 vs 3.8). This seems a bit much for
> > a man page. If anyone prefers the letter ordering be kept, the correct
> > order is ETSAORINDHLCPMUYFWGBVKXQZJ .
> > 
> > - Matthew Martin
> > 
> 
> morning.
> 
> i don;t see what harm there is in providing this information. the man
> page itself is hardly a huge read, and who knows whether someome might
> find it useful.
> 
> i'd be willing to commit a diff which updates the man page.
> 
> jmc

Morning

I assumed someone who cared to know the frequencies would open the
source, and removing them means there's is one less thing to get out of
sync. But I have no strong opinion here.

- Matthew Martin


diff --git caesar.6 caesar.6
index 9dc040a7a6d..94ad082327e 100644
--- caesar.6
+++ caesar.6
@@ -64,13 +64,13 @@ their content.
 .Pp
 The frequency (from most common to least) of English letters is as follows:
 .Bd -filled -offset indent
-ETAONRISHDLFCMUGPYWBVKXJQZ
+ETSAORINDHLCPMUYFWGBVKXQZJ
 .Ed
 .Pp
 Their frequencies as a percentage are as follows:
 .Bd -filled -offset indent
-E(13), T(10.5), A(8.1), O(7.9), N(7.1), R(6.8), I(6.3), S(6.1), H(5.2),
-D(3.8), L(3.4), F(2.9), C(2.7), M(2.5), U(2.4), G(2),
-P(1.9), Y(1.9),
-W(1.5), B(1.4), V(.9), K(.4), X(.15), J(.13), Q(.11), Z(.07).
+E(12.37), T(9.68), S(8.77), A(7.97), O(6.96), R(6.63), I(6.39), N(5.92),
+D(4.78), H(4.49), L(3.81), C(3.61), P(2.91), M(2.69), U(2.62), Y(2.07),
+F(2.01), W(1.88), G(1.46), B(1.35), V(0.81), K(0.42), X(0.23), Q(0.08),
+Z(0.06), J(0.04).
 .Ed

Re: Changing default compiler for usr/ports buiding

[Denis]

Ok, but how to point cmake-3.5.2 to build the needed "source" which
using Boost 1.53 or higher libraries ver.?

Boost 1.59.0 itself was downloaded from boost web site and builded from
sources using gcc 4.9 already. Some patches have been installed.

I have tried to point cmake-3.5.2 to Boost-1.59.0 (builded from source
by gcc 4.9) by using some documented hints
cmake -DBoost_NO_SYSTEM_PATHS=ON -DBOOST_ROOT=/boost-gcc49/output
-DBOOST_INCLUDEDIR=/boost-gcc49/output/include -
DBOOST_LIBRARYDIR=/boost-gcc49/output/lib
-DCMAKE_INSTALL_PREFIX=/build/src-output

But Cmake wan't see the prebuilded Boost 1.59.0 libraries, but clearly
sees the paths to Boost ROOT dir, include, and lib dirs.

So I tried to build Boost 1.58 which is a part of ports of OpenBSD 6.0
amd64 by newer compiler gcc 4.9 which is required for the sources build...

What can I do to have Boost 1.58 or Boost 1.59 builded by gcc 4.9 and
working with cmake-3.5.2 ?

Thanks for answer in advance.

On 31.07.2017 21:34, Marc Espie wrote:
> On Mon, Jul 31, 2017 at 05:47:59PM +0300, Denis wrote:
>> I'm trying to change default compiler to build some ports.
>> Tried to do it using bsd.port.mk and by system variables CXX=eg++
>> CPP=egcc, but nothing changes while building a port.
>>
>> How can I force the default gcc 4.2 to egcc (gcc 4.9)?
>>
>> Thanks
> You can't.
>
> Things generally won't work.
>
> Current uses clang on i386 and amd64.
>
> And that's wildly incompatible with gcc 4.2 or 4.9...
>

Re: [diff] typo in tls_load_file.3

[Jason McIntyre]

On Sat, Jul 29, 2017 at 03:15:56PM -0700, Carlos Cardenas wrote:
> Missing 'ocsp' in the function name.
> 

fixed, thanks.
jmc

> +--+
> Carlos
> 
> diff --git lib/libtls/man/tls_load_file.3 lib/libtls/man/tls_load_file.3
> index fcaa5eef029..b83f55e0fe4 100644
> --- lib/libtls/man/tls_load_file.3
> +++ lib/libtls/man/tls_load_file.3
> @@ -254,7 +254,7 @@ sets the files from which the public certificate, and
> private key will be read.
>  .Fn tls_config_set_keypair_mem
>  directly sets the public certificate, and private key from memory.
>  .Pp
> -.Fn tls_config_set_keypair_file
> +.Fn tls_config_set_keypair_ocsp_file
>  sets the files from which the public certificate, private key, and DER
> encoded
>  OCSP staple will be read.
>  .Pp

Re: caesar(6) documents incorrect frequencies

[Jason McIntyre]

On Thu, Jul 27, 2017 at 01:36:15AM -0500, Matthew Martin wrote:
> The man page documents frequencies that are different than the code
> uses e.g. C (3.61 vs 2.7) and D (4.78 vs 3.8). This seems a bit much for
> a man page. If anyone prefers the letter ordering be kept, the correct
> order is ETSAORINDHLCPMUYFWGBVKXQZJ .
> 
> - Matthew Martin
> 

morning.

i don;t see what harm there is in providing this information. the man
page itself is hardly a huge read, and who knows whether someome might
find it useful.

i'd be willing to commit a diff which updates the man page.

jmc

> 
> diff --git caesar.6 caesar.6
> index 9dc040a7a6d..889f24c6548 100644
> --- caesar.6
> +++ caesar.6
> @@ -61,16 +61,3 @@ and in some of the databases used by the
>  program to
>  .Dq disguise
>  their content.
> -.Pp
> -The frequency (from most common to least) of English letters is as follows:
> -.Bd -filled -offset indent
> -ETAONRISHDLFCMUGPYWBVKXJQZ
> -.Ed
> -.Pp
> -Their frequencies as a percentage are as follows:
> -.Bd -filled -offset indent
> -E(13), T(10.5), A(8.1), O(7.9), N(7.1), R(6.8), I(6.3), S(6.1), H(5.2),
> -D(3.8), L(3.4), F(2.9), C(2.7), M(2.5), U(2.4), G(2),
> -P(1.9), Y(1.9),
> -W(1.5), B(1.4), V(.9), K(.4), X(.15), J(.13), Q(.11), Z(.07).
> -.Ed
> 

ftp(1): remove self assignment

[Anton Lindqvist]

Hi,
Discovered while compiling with `-Wall`. My guess is that this line was
added back in 2004 in order to silence a compiler warning since the
parameter is not used. Unfortunately it can't be removed since the
function prototype is dictated by el_set(3).

Comments? OK?

Index: complete.c
===
RCS file: /cvs/src/usr.bin/ftp/complete.c,v
retrieving revision 1.30
diff -u -p -r1.30 complete.c
--- complete.c  21 Jan 2017 08:33:07 -  1.30
+++ complete.c  1 Aug 2017 07:05:44 -
@@ -288,7 +288,6 @@ complete(EditLine *el, int ch)
int celems, dolist;
size_t len;
 
-   ch = ch;/* not used */
lf = el_line(el);
len = lf->lastchar - lf->buffer;
if (len >= sizeof(line))