Re: specify curves via ecdhe statement in httpd.conf

2017-02-03 Thread Joel Sing 
On Wednesday 01 February 2017 15:41:29 Andreas Bartelt wrote:
> Hello,
> 
> after reading the LibreSSL accouncement from today, I assumed that
> specifying ecdhe "auto" in /etc/httpd.conf would enable X25519, P-256
> and P-384 on current.

This is correct.

> I've noticed that "auto" enables only curves x25519 and P-256 (which is
> what I'd want to use - but somehow unexpected with regard to the
> announcement).

Why do you believe this is the case?

> Diff is attached which clarifies the meaning of "auto" in httpd.conf.5.

There are some documentation improvements that could be used here, however the 
meaning of auto for httpd.conf.5 needs to refer to the meaning of "auto" for 
libtls (currently tls_config_set_ecdhecurve()). Otherwise libtls changes and 
httpd becomes out of date.

> There currently seems to be no way to explicitly specify x25519, or to
> specify multiple colon separated curves with the ecdhe statement. Would
> it make sense to change semantics and make the ecdhe statement in
> httpd.conf consistent with the recent changes to openssl s_client
> -groups (e.g., to also allow more common names like P-256 instead of
> prime256v1)?

Yes - tls_config_set_ecdhecurve() needs to change to accept the same colon 
separate list of priority ordered curve names, that SSL_set1_curves_list() 
accepts.

Re: make sosetopt responsible for m_free

2017-02-03 Thread David Hill 
On Fri, Feb 03, 2017 at 09:50:40AM +0100, Martin Pieuchot wrote:
> On 02/02/17(Thu) 12:12, David Hill wrote:
> > On Thu, Feb 02, 2017 at 09:34:07AM +0100, Martin Pieuchot wrote:
> > > On 01/02/17(Wed) 19:27, David Hill wrote:
> > > > Hello -
> > > > 
> > > > This diff makes sosetopt responsible for m_free which is much simpler.
> > > > Requested by bluhm@ 
> > > 
> > > I'd suggest to move the m_free(9) calls to sys_setsockopt().  This
> > > simplifies the existing code even more and will make it easier to use
> > > the stack for this temporary storage.
> > > 
> > 
> > New diff with mpi@'s suggestion. 
> 
> You forgot NFS and BFD that should now call m_free(9) after sosetopt(9). 
>

Indeed!  Now with BFD and NFS...

Index: kern/uipc_socket.c
===
RCS file: /cvs/src/sys/kern/uipc_socket.c,v
retrieving revision 1.176
diff -u -p -r1.176 uipc_socket.c
--- kern/uipc_socket.c  1 Feb 2017 20:59:47 -   1.176
+++ kern/uipc_socket.c  3 Feb 2017 16:00:26 -
@@ -1551,16 +1551,15 @@ sowwakeup(struct socket *so)
 }
 
 int
-sosetopt(struct socket *so, int level, int optname, struct mbuf *m0)
+sosetopt(struct socket *so, int level, int optname, struct mbuf *m)
 {
int s, error = 0;
-   struct mbuf *m = m0;
 
if (level != SOL_SOCKET) {
if (so->so_proto && so->so_proto->pr_ctloutput) {
NET_LOCK(s);
error = (*so->so_proto->pr_ctloutput)(PRCO_SETOPT, so,
-   level, optname, m0);
+   level, optname, m);
NET_UNLOCK(s);
return (error);
}
@@ -1707,7 +1706,7 @@ sosetopt(struct socket *so, int level, i
level = dom->dom_protosw->pr_protocol;
NET_LOCK(s);
error = (*so->so_proto->pr_ctloutput)
-   (PRCO_SETOPT, so, level, optname, m0);
+   (PRCO_SETOPT, so, level, optname, m);
NET_UNLOCK(s);
return (error);
}
@@ -1739,14 +1738,11 @@ sosetopt(struct socket *so, int level, i
if (error == 0 && so->so_proto && so->so_proto->pr_ctloutput) {
NET_LOCK(s);
(*so->so_proto->pr_ctloutput)(PRCO_SETOPT, so,
-   level, optname, m0);
+   level, optname, m);
NET_UNLOCK(s);
-   m = NULL;   /* freed by protocol */
}
}
 bad:
-   if (m)
-   (void) m_free(m);
return (error);
 }
 
Index: kern/uipc_syscalls.c
===
RCS file: /cvs/src/sys/kern/uipc_syscalls.c,v
retrieving revision 1.148
diff -u -p -r1.148 uipc_syscalls.c
--- kern/uipc_syscalls.c26 Jan 2017 01:58:00 -  1.148
+++ kern/uipc_syscalls.c3 Feb 2017 16:00:26 -
@@ -962,19 +962,13 @@ sys_setsockopt(struct proc *p, void *v, 
goto bad;
}
}
-   if (m == NULL) {
-   error = ENOBUFS;
-   goto bad;
-   }
error = copyin(SCARG(uap, val), mtod(m, caddr_t),
SCARG(uap, valsize));
-   if (error) {
+   if (error)
goto bad;
-   }
m->m_len = SCARG(uap, valsize);
}
error = sosetopt(fp->f_data, SCARG(uap, level), SCARG(uap, name), m);
-   m = NULL;
 bad:
m_freem(m);
FRELE(fp, p);
Index: net/bfd.c
===
RCS file: /cvs/src/sys/net/bfd.c,v
retrieving revision 1.58
diff -u -p -r1.58 bfd.c
--- net/bfd.c   24 Jan 2017 10:08:30 -  1.58
+++ net/bfd.c   3 Feb 2017 16:00:26 -
@@ -418,7 +418,7 @@ bfd_listener(struct bfd_config *bfd, uns
struct sockaddr_in  *sin;
struct sockaddr_in6 *sin6;
struct socket   *so;
-   struct mbuf *m = NULL, *mopt = NULL;
+   struct mbuf *m = NULL, *mopt;
int *ip, error;
 
/* sa_family and sa_len must be equal */
@@ -437,6 +437,7 @@ bfd_listener(struct bfd_config *bfd, uns
ip = mtod(mopt, int *);
*ip = MAXTTL;
error = sosetopt(so, IPPROTO_IP, IP_MINTTL, mopt);
+   m_free(mopt);
if (error) {
printf("%s: sosetopt error %d\n",
__func__, error);
@@ -487,7 +488,7 @@ bfd_sender(struct bfd_config *bfd, unsig
struct socket   *so;
struct rtentry  *rt = bfd->bc_rt;
struct proc *p = curproc;
-   struct mbuf *m = NULL,

Re: Help with the NET_LOCK()

2017-02-03 Thread Hrvoje Popovski 
On 25.1.2017. 7:32, Martin Pieuchot wrote:
> I just enabled the NET_LOCK() again and I'm looking for test reports.
> Please go build a kernel from sources or wait for the next snapshot,
> run it and report back.
> 
> If you're looking for some small coding tasks related to the NET_LOCK()
> just do:
> 
>   # sysctl kern.splassert=2
>   # sysctl kern.pool_debug=2


while browsing samba shares or copy files over samba i'm seeing this trace


splassert: yield: want 0 have 1
Starting stack trace...
yield() at yield+0xac
pool_get() at pool_get+0x1ca
softdep_freefile() at softdep_freefile+0x43
ffs_inode_free() at ffs_inode_free+0x27
ufs_inactive() at ufs_inactive+0x158
VOP_INACTIVE() at VOP_INACTIVE+0x35
vrele() at vrele+0x65
unp_detach() at unp_detach+0x59
uipc_usrreq() at uipc_usrreq+0x2cd
soclose() at soclose+0x78
soo_close() at soo_close+0x1c
fdrop() at fdrop+0x2c
closef() at closef+0xcb
sys_close() at sys_close+0x60
syscall() at syscall+0x27b
--- syscall (number 6) ---
end trace frame: 0x0, count: 242
0x22c3209083a:
End of stack trace.


while copying files over local disk there aren't any traces


this is gnome desktop with today's -current


# mount
/dev/sd0a on / type ffs (local)
/dev/sd0l on /home type ffs (local, noatime, nodev, nosuid, softdep)
/dev/sd0d on /tmp type ffs (local, noatime, nodev, nosuid, softdep)
/dev/sd0f on /usr type ffs (local, noatime, nodev, softdep)
/dev/sd0g on /usr/X11R6 type ffs (local, noatime, nodev, softdep)
/dev/sd0h on /usr/local type ffs (local, noatime, nodev, wxallowed, softdep)
/dev/sd0k on /usr/obj type ffs (local, noatime, nodev, nosuid, softdep)
/dev/sd0j on /usr/src type ffs (local, noatime, nodev, nosuid, softdep)
/dev/sd0e on /var type ffs (local, noatime, nodev, nosuid, softdep)


# cat /etc/sysctl.conf
ddb.console=1
kern.bufcachepercent=90
kern.pool_debug=2
kern.splassert=2



OpenBSD 6.0-current (GENERIC.MP) #0: Fri Feb  3 13:57:23 CET 2017
dow...@viziogot.srce.hr:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8456093696 (8064MB)
avail mem = 8195158016 (7815MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe87b1 (86 entries)
bios0: vendor Hewlett-Packard version "J01 v02.29" date 04/04/2016
bios0: Hewlett-Packard HP Compaq 8200 Elite CMT PC
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC SSDT MCFG HPET SSDT SLIC TCPA
acpi0: wakeup devices PS2K(S3) PS2M(S3) BR20(S4) EUSB(S3) USBE(S3)
PEX0(S4) PEX1(S4) PEX2(S4) PEX3(S4) PEX4(S4) PEX5(S4) PEX6(S4) PEX7(S4)
P0P1(S4) P0P2(S4) P0P3(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) Core(TM) i5-2500 CPU @ 3.30GHz, 3293.26 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: TSC frequency 3293258160 Hz
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.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i5-2500 CPU @ 3.30GHz, 3292.52 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Core(TM) i5-2500 CPU @ 3.30GHz, 3292.52 MHz
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Core(TM) i5-2500 CPU @ 3.30GHz, 3292.52 MHz
cpu3:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 3, package 0
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 5 (BR20)
acpiprt2 at acpi0: bus 1 (PEX0)
acpiprt3 at acpi0: bus -1 (PEX1)
acpiprt4 at acpi0: bus -1

arm64: flush data and instruction cache before calling kernel

2017-02-03 Thread Patrick Wildt 
Hi,

turns out that machines (in my case the AMD machine) can have the MMU
and caches enabled while running EFI.  This means that once we jump into
the kernel and disable the MMU, the cache is lost and we kind of crash.

To fix that, make sure to clean the data cache and flush the instruction
cache before jumping into kernel.  This fixes issues on my AMD machine
where it "hangs" 3 instructions in.

Based on FreeBSD code.

ok?

Patrick


diff --git a/sys/arch/arm64/stand/efiboot/exec.c 
b/sys/arch/arm64/stand/efiboot/exec.c
index 088401a48eb..88c1355f030 100644
--- a/sys/arch/arm64/stand/efiboot/exec.c
+++ b/sys/arch/arm64/stand/efiboot/exec.c
@@ -27,11 +27,65 @@
 #include 
 #include 
 
+#include 
+
 #include "efiboot.h"
 #include "libsa.h"
 
 typedef void (*startfuncp)(void *, void *, void *) __attribute__ ((noreturn));
 
+unsigned int cpu_get_dcache_line_size(void);
+void cpu_flush_dcache(vaddr_t, vsize_t);
+void cpu_inval_icache(void);
+
+unsigned int
+cpu_get_dcache_line_size(void)
+{
+   uint64_t ctr;
+   unsigned int dcl_size;
+
+   /* Accessible from all security levels */
+   ctr = READ_SPECIALREG(ctr_el0);
+
+   /*
+* Relevant field [19:16] is LOG2
+* of the number of words in DCache line
+*/
+   dcl_size = CTR_DLINE_SIZE(ctr);
+
+   /* Size of word shifted by cache line size */
+   return (sizeof(int) << dcl_size);
+}
+
+void
+cpu_flush_dcache(vaddr_t addr, vsize_t len)
+{
+   uint64_t cl_size;
+   vaddr_t end;
+
+   cl_size = cpu_get_dcache_line_size();
+
+   /* Calculate end address to clean */
+   end = addr + len;
+   /* Align start address to cache line */
+   addr = addr & ~(cl_size - 1);
+
+   for (; addr < end; addr += cl_size)
+   __asm volatile("dc civac, %0" :: "r" (addr) : "memory");
+
+   /* Full system DSB */
+   __asm volatile("dsb sy" ::: "memory");
+}
+
+void
+cpu_inval_icache(void)
+{
+   __asm volatile(
+   "ic ialluis \n"
+   "dsbish \n"
+   : : : "memory");
+}
+
 void
 run_loadfile(u_long *marks, int howto)
 {
@@ -81,6 +135,9 @@ run_loadfile(u_long *marks, int howto)
 
efi_cleanup();
 
+   cpu_flush_dcache(marks[MARK_ENTRY], marks[MARK_END] - 
marks[MARK_ENTRY]);
+   cpu_inval_icache();
+
(*(startfuncp)(marks[MARK_ENTRY]))((void *)esym, 0, fdt);
 
/* NOTREACHED */

arm64: properly exit EFI BootServices

2017-02-03 Thread Patrick Wildt 
Hi,

reading the UEFI specification (and also FreeBSD code) it turns out that
to make EFI properly exit, we need to prove that we know the state of
the current memory mappings.  Otherwise EFI can opt to only do a partial
shutdown of its services.

It would be nice to eventually parse and use the EFI memory descriptors
in the kernel, but for now on arm64 it would be good enough to simply
make EFI exit properly.

Since the memory map, and thus the mapkey, can change between the
GetMemoryMap and ExitBootServices, we need to try reading/exiting a few
times.

ok?

Patrick

diff --git a/sys/arch/arm64/stand/efiboot/efiboot.c 
b/sys/arch/arm64/stand/efiboot/efiboot.c
index a9e7ea38d0b..64bb6f618cf 100644
--- a/sys/arch/arm64/stand/efiboot/efiboot.c
+++ b/sys/arch/arm64/stand/efiboot/efiboot.c
@@ -292,9 +292,35 @@ machdep(void)
 void
 efi_cleanup(void)
 {
+   EFI_STATUS   status;
+   UINTNmapkey, mmsiz, siz;
+   UINT32   mmver;
+   EFI_MEMORY_DESCRIPTOR   *mm;
+   int  i;
+
efi_timer_cleanup();
 
-   BS->ExitBootServices(NULL, 0);
+   for (i = 3; i > 0; i--) {
+   siz = 0;
+   status = EFI_CALL(BS->GetMemoryMap, , NULL, , ,
+   );
+   if (status != EFI_BUFFER_TOO_SMALL)
+   continue;
+   mm = alloc(siz);
+   status = EFI_CALL(BS->GetMemoryMap, , mm, , , 
);
+   if (status != EFI_SUCCESS) {
+   free(mm, siz);
+   continue;
+   }
+
+   status = BS->ExitBootServices(IH, mapkey);
+   if (status != EFI_SUCCESS) {
+   free(mm, siz);
+   continue;
+   }
+
+   break;
+   }
 }
 
 void

Re: 11n support for athn(4)

2017-02-03 Thread Peter Faiman 

> On Jan 18, 2017, at 2:02 AM, Stefan Sperling  wrote:
> 
> On Wed, Jan 18, 2017 at 09:19:28AM +0100, Uwe Werler wrote:
>> On 16. Jan 17:46:48, Uwe Werler wrote:
>>> 
>>> Unfortunately the throughput is very low, only ~7 MBit. With mode 11g I get 
>>> ~16 MBit.
>>> 
>>> 
>>> zarathustra:~# tcpbench apu01
>>>  elapsed_ms  bytes mbps   bwidth
>>>1004 7482725.962  100.00%
>>> Conn:   1 Mbps:5.962 Peak Mbps:5.962 Avg Mbps:5.962
>>>2007 8396646.697  100.00%
>>> Conn:   1 Mbps:6.697 Peak Mbps:6.697 Avg Mbps:6.697
>>>3010 8182446.533  100.00%
>>> Conn:   1 Mbps:6.533 Peak Mbps:6.697 Avg Mbps:6.533
>>>4013 9096367.255  100.00%
>>> Conn:   1 Mbps:7.255 Peak Mbps:7.255 Avg Mbps:7.255
>>>5014 8568006.848  100.00%
>>> Conn:   1 Mbps:6.848 Peak Mbps:7.255 Avg Mbps:6.848
>>>6015 8682246.946  100.00%
>>> Conn:   1 Mbps:6.946 Peak Mbps:7.255 Avg Mbps:6.946
>>>7021 8725086.945  100.00%
>>> Conn:   1 Mbps:6.945 Peak Mbps:7.255 Avg Mbps:6.945
>>>8023 8353806.670  100.00%
>>> Conn:   1 Mbps:6.670 Peak Mbps:7.255 Avg Mbps:6.670
>>>9025 8482326.779  100.00%
>>> Conn:   1 Mbps:6.779 Peak Mbps:7.255 Avg Mbps:6.779
>>>   10028 8439486.731  100.00%
>>> Conn:   1 Mbps:6.731 Peak Mbps:7.255 Avg Mbps:6.731
>>>   11036 8310966.596  100.00%
>>> Conn:   1 Mbps:6.596 Peak Mbps:7.255 Avg Mbps:6.596
>>> 
>>> I'm now ready to test furhter.
>>> 
>> 
>> I tested yesterday with my Android phone (Galaxy S7) and got only ~4 MBit.
> 
> Thank you for providing these numbers.
> 
> I would like to note though that there are many factors determining the
> effective throughput of wifi, ranging from wifi hardware, across OS and
> driver code, to specific AP/client behaviour and environmental RF conditions.
> 
> So when you report a number, you help with establishing a picture of the
> overall range of throughput people are seeing. But a number does not tell
> anybody anything about why throughput is lower than expected in your case.
> So this number cannot be used to actually improve the driver.
> It is just a data point.
> 
> What would help a small bit is a direct comparison with Linux running on the
> same access point hardware in the exact same environment. That would indicate
> which performance levels could be reached in your environment if OpenBSD was
> optimally tuned. I assume Linux has reached optimal performance levels on
> this several years old hardware by now.
> 
> In my testing I have noticed that Intel clients send data much faster than
> athn APs/clients do. The AP is able to receive higher data rates than it
> is sending. I don't know why that is happening and under which conditions
> this is to be expected. But it points to a problem with the athn driver.
> Perhaps the hardware is not tuned towards the specific way in which our
> driver makes use of it.
> 
> For now, I am happy if your AP works without crashing.
> As mentioned in the driver's man page, our 11n support is still incomplete
> and a whole lot remains to be done.
> 

Thanks for all your work on 11n!

I just got my system set up with a wle200nx in hostap mode, with the OpenBSD 
snapshots from today. It’s working great so far, I’m able to consistently get 
13-16 megabits up and down with this config, enough to watch Netflix with no 
issues! Has anyone seen better than 16 megabit?

It’s proven robust so far, and I get much better signal all over my apartment 
whereas my old WRT610N had some trouble. I will compare with Linux as soon as I 
can, but realistically it’s working so well I don’t have a lot of motivation to 
change it. I can also report that I was changing modes and channels over ssh to 
test out different things, and didn’t have any crashes or issues.

WRT the receive vs send data rates, I observed that as well before I landed on 
this config. For me, 2.4 ghz 11n channels were getting 3-4 mbits to the AP, and 
11+ mbits down. I kind of assumed that, like many wireless chips, the receive 
is just better on this chip.

Ah, and all my testing was done with a late 2013 MacBook pro, and an iPhone 
6s+. As far as my environment, my MacBook detects ~37 networks around me, 
mostly on 2.4 ghz channels, about 1/3 on 5 ghz. I’m using chan 165 since none 
of the other APs seemed to pick it (they are maxing out at 161), so it seemed 
like a sensible choice for a static config.

If there is any other useful information I could report, I’d be happy to!

athn0 at pci4 dev 0 function 0 "Atheros AR9281" rev 0x01: apic 5 int 16
athn0:

Re: Add quirks to support M-Audio FastTrack Pro (uaudio)

2017-02-03 Thread Christopher Zimmermann 
Hi, 

thanks for your patience.
If some things are still unclear I'll be glad to clarify.


Christopher


On 2017-02-02 Martin Pieuchot  wrote:
> On 31/01/17(Tue) 14:05, Christopher Zimmermann wrote:
> > On 2017-01-29 Martin Pieuchot  wrote:  
> > > On 29/01/17(Sun) 19:33, Christopher Zimmermann wrote:  
> > > > [...]
> > > > @@ -444,6 +447,11 @@ uaudio_match(struct device *parent, void
> > > > if (uaa->iface == NULL || uaa->device == NULL)
> > > > return (UMATCH_NONE);
> > > >  
> > > > +   if (uaa->vendor == USB_VENDOR_MAUDIO &&
> > > > +   uaa->product == USB_PRODUCT_MAUDIO_FASTTRACKPRO &&
> > > > +   uaa->configno != 2)
> > > > +   return UMATCH_NONE;
> > > 
> > > Why to you need this?  
> > 
> > This device exposes only a very limited set of features in
> > configuration 1.  
> 
> But configuration 1 is midi not audio right?  So it won't match, so
> why do you need that?

In config 1 the device exposes these ifaces:
0 audio control
1 midi
2 audio play
3 audio rec

in config 2 the device exposes these ifaces:
0 audio control
1 midi
2 audio analog out
3 audio analog / digital out
4 audio analog in (with mic preamps)
5 audio digital in

if any iface in config 1 is claimed the device cannot switch to config 2.

> > > > @@ -3312,6 +3340,9 @@ uaudio_set_params(void *addr, int setmod
> > > > }
> > > > break;
> > > > }
> > > > +
> > > > +   if (sc->sc_quirks & UAUDIO_FLAG_BE)
> > > > +   p->encoding =
> > > > AUDIO_ENCODING_SLINEAR_BE;
> > > 
> > > Why do you need this chunk and we don't need to set
> > > AUDIO_ENCODING_SLINEAR_LE in the other case?  
> > 
> > We probably should set it to _LE in the other case. I moved this
> > piece of code into uaudio_match_alt() and made it agnostic about
> > the specific endianness. 
> > > > @@ -152,6 +153,11 @@ umidi_match(struct device *parent, void 
> > > > DPRINTFN(1,("umidi_match\n"));
> > > >  
> > > > if (uaa->iface == NULL)
> > > > +   return UMATCH_NONE;
> > > > +
> > > > +   if (uaa->vendor == USB_VENDOR_MAUDIO &&
> > > > +   uaa->product == USB_PRODUCT_MAUDIO_FASTTRACKPRO &&
> > > > +   uaa->configno != 2)
> > > > return UMATCH_NONE;
> > > 
> > > I'd leave the configno check out and add a comment explaining why
> > > we want to force this driver to attach to uaudio(4).  
> > 
> > See my comment above about the same piece of code in uaudio.c.
> > If I don't add this condition umidi will attach to configuration 1
> > and configuration 2 wouldn't be tried, uaudio wouldn't attach.  
> 
> Please re-read my comment.  I'm talking about the "configno" check.
> Think about somebody reading your code in 5 years, it will just looks
> like black magic.

What about adding this comment:

/*
 * This combined audio / midi device exposes its
 * full set of features only in configuration 2.
 */

> What you're doing is working around our stupid USB detection mechanism
> to use a specific configuration.  So you don't want your device to
> attach to umidi(4) no matter with which configuration.
> 
> > +   if (p->precision > 8)
> > +   /*
> > +* Don't search for matching encoding.
> > +* Just tell the upper layers which one we support.
> > +*/
> > +   p->encoding = sc->sc_alts[i].encoding;  
> 
> Why do you need that?

- The audio device is big endian.
- The uaudio driver was written for little endian devices.
- The audio driver assumes _host_ endianness.
- The uaudio driver will reject AUDIO_SETPAR (audio(4)) requests which don't
  exactly match the device encoding. 
- I change uaudio to communicate the supported endianness back to audio(4), so
  that userspace will receive the supported parameters via AUDIO_GETPAR and
  will use a supported encoding.

> > +   else if (p->encoding != sc->sc_alts[i].encoding)
> > +   continue;
> > +
> > alts_eh |= 1 << i;
> > DPRINTFN(6,("%s: matched %s alt %d for enc/pre\n",
> > __func__, mode == AUMODE_RECORD ? "rec" : "play", i));  



-- 
http://gmerlin.de
OpenPGP: http://gmerlin.de/christopher.pub
2779 7F73 44FD 0736 B67A  C410 69EC 7922 34B4 2566


pgpwepgVnSMc9.pgp
Description: OpenPGP digital signature

arm64: efiboot pass physical esym address

2017-02-03 Thread Patrick Wildt 
Hi,

due to the previous armv7 non-EFI history, our current efiboot on armv7
still manually modifies a symbol in the kernel before booting it.

Since efiboot for arm64 was copied from armv7, this code is still there
and the mechanism is partially in use.  Why partially?  Well, we pass
the virtual address of esym, which we calculated in efiboot, to the
kernel and the kernel then overwrites the variable again.  So there is
no actual sense in doing that in the bootloader.

Instead, I would prefer to pass the physical address, so that efiboot
does not have to do any virtual address juggling.  Instead, we let the
kernel find out which virtual address the end of symbols is by using
the delta.

Bump the version while there to show the change.

ok?

Patrick


Index: arm64/locore.S
===
RCS file: /cvs/src/sys/arch/arm64/arm64/locore.S,v
retrieving revision 1.6
diff -u -p -u -r1.6 locore.S
--- arm64/locore.S  23 Jan 2017 13:43:50 -  1.6
+++ arm64/locore.S  3 Feb 2017 10:02:12 -
@@ -82,6 +82,7 @@ _start:
adr x0, .Lesym
ldr x0, [x0]
sub x0, x0, x29
+   add x21, x21, x29
str x21, [x0]
 
/*
Index: stand/efiboot/conf.c
===
RCS file: /cvs/src/sys/arch/arm64/stand/efiboot/conf.c,v
retrieving revision 1.1
diff -u -p -u -r1.1 conf.c
--- stand/efiboot/conf.c17 Dec 2016 23:38:33 -  1.1
+++ stand/efiboot/conf.c3 Feb 2017 10:02:12 -
@@ -35,7 +35,7 @@
 #include "efiboot.h"
 #include "efidev.h"
 
-const char version[] = "0.1";
+const char version[] = "0.2";
 intdebug = 0;
 
 struct fs_ops file_system[] = {
Index: stand/efiboot/exec.c
===
RCS file: /cvs/src/sys/arch/arm64/stand/efiboot/exec.c,v
retrieving revision 1.2
diff -u -p -u -r1.2 exec.c
--- stand/efiboot/exec.c23 Jan 2017 12:02:14 -  1.2
+++ stand/efiboot/exec.c3 Feb 2017 10:02:12 -
@@ -35,29 +35,9 @@ typedef void (*startfuncp)(void *, void 
 void
 run_loadfile(u_long *marks, int howto)
 {
-   Elf_Ehdr *elf = (Elf_Ehdr *)marks[MARK_SYM];
-   Elf_Shdr *shp = (Elf_Shdr *)(marks[MARK_SYM] + elf->e_shoff);
-   u_long esym = marks[MARK_END] & 0x000fff;
-   u_long offset = 0;
char args[256];
char *cp;
void *fdt;
-   int i;
-
-   /*
-* Tell locore.S where the symbol table ends by setting
-* 'esym', which should be the first word in the .data
-* section.
-*/
-   for (i = 0; i < elf->e_shnum; i++) {
-   /* XXX Assume .data is the first writable segment. */
-   if (shp[i].sh_flags & SHF_WRITE) {
-   /* XXX We have to store the virtual address. */
-   esym |= shp[i].sh_addr & 0xff80;
-   *(u_long *)(LOADADDR(shp[i].sh_addr)) = esym;
-   break;
-   }
-   }
 
snprintf(args, sizeof(args) - 8, "%s:%s", cmd.bootdev, cmd.image);
cp = args + strlen(args);
@@ -81,7 +61,7 @@ run_loadfile(u_long *marks, int howto)
 
efi_cleanup();
 
-   (*(startfuncp)(marks[MARK_ENTRY]))((void *)esym, 0, fdt);
+   (*(startfuncp)(marks[MARK_ENTRY]))((void *)marks[MARK_END], 0, fdt);
 
/* NOTREACHED */
 }

Re: net80211: fix bogus rateset in assoc requests in 11b mode

2017-02-03 Thread Stefan Sperling 
On Fri, Feb 03, 2017 at 09:49:21AM +0100, Martin Pieuchot wrote:
> On 02/02/17(Thu) 22:14, Stefan Sperling wrote:
> > Note that rates get fixed up again after association is confirmed,
> > via ieee80211_recv_assoc_resp() -> ieee80211_setup_rates().
> > Which is why 11b clients were already working fine in spite of sending
> > a bogus rateset in the association request.
> 
> Does that mean this second correction is now unnecessary?

Not sure about that. Technically, nobody is allowed to flip-flop on what
they support. But it happens due to bugs such as this one.
I hae seen evidence of other devices having similar bugs, e.g. Nintendo 3DS
clients send a garbage SSID and rateset in a first probe request:

SSID parameter set: K%mUL5MD:HWISMM2?E`|Yvt/bFIhp.cb
Supported Rates 1(B), 2(B), 5.5(B), 6, 9, 11(B), 12, 18, [Mbit/sec]
Extended Supported Rates 24, 36, 48, 54, [Mbit/sec]

And then change their mind in the next one:

SSID parameter set: stsp.name
Supported Rates 1(B), 2(B), 5.5(B), 11(B), [Mbit/sec]

Always using the most recently received information from the peer
is probably the best thing to do.

Re: make sosetopt responsible for m_free

2017-02-03 Thread Martin Pieuchot 
On 02/02/17(Thu) 12:12, David Hill wrote:
> On Thu, Feb 02, 2017 at 09:34:07AM +0100, Martin Pieuchot wrote:
> > On 01/02/17(Wed) 19:27, David Hill wrote:
> > > Hello -
> > > 
> > > This diff makes sosetopt responsible for m_free which is much simpler.
> > > Requested by bluhm@ 
> > 
> > I'd suggest to move the m_free(9) calls to sys_setsockopt().  This
> > simplifies the existing code even more and will make it easier to use
> > the stack for this temporary storage.
> > 
> 
> New diff with mpi@'s suggestion. 

You forgot NFS and BFD that should now call m_free(9) after sosetopt(9). 

> Index: kern/uipc_socket.c
> ===
> RCS file: /cvs/src/sys/kern/uipc_socket.c,v
> retrieving revision 1.176
> diff -u -p -r1.176 uipc_socket.c
> --- kern/uipc_socket.c1 Feb 2017 20:59:47 -   1.176
> +++ kern/uipc_socket.c2 Feb 2017 16:59:45 -
> @@ -1551,16 +1551,15 @@ sowwakeup(struct socket *so)
>  }
>  
>  int
> -sosetopt(struct socket *so, int level, int optname, struct mbuf *m0)
> +sosetopt(struct socket *so, int level, int optname, struct mbuf *m)
>  {
>   int s, error = 0;
> - struct mbuf *m = m0;
>  
>   if (level != SOL_SOCKET) {
>   if (so->so_proto && so->so_proto->pr_ctloutput) {
>   NET_LOCK(s);
>   error = (*so->so_proto->pr_ctloutput)(PRCO_SETOPT, so,
> - level, optname, m0);
> + level, optname, m);
>   NET_UNLOCK(s);
>   return (error);
>   }
> @@ -1707,7 +1706,7 @@ sosetopt(struct socket *so, int level, i
>   level = dom->dom_protosw->pr_protocol;
>   NET_LOCK(s);
>   error = (*so->so_proto->pr_ctloutput)
> - (PRCO_SETOPT, so, level, optname, m0);
> + (PRCO_SETOPT, so, level, optname, m);
>   NET_UNLOCK(s);
>   return (error);
>   }
> @@ -1739,14 +1738,11 @@ sosetopt(struct socket *so, int level, i
>   if (error == 0 && so->so_proto && so->so_proto->pr_ctloutput) {
>   NET_LOCK(s);
>   (*so->so_proto->pr_ctloutput)(PRCO_SETOPT, so,
> - level, optname, m0);
> + level, optname, m);
>   NET_UNLOCK(s);
> - m = NULL;   /* freed by protocol */
>   }
>   }
>  bad:
> - if (m)
> - (void) m_free(m);
>   return (error);
>  }
>  
> Index: kern/uipc_syscalls.c
> ===
> RCS file: /cvs/src/sys/kern/uipc_syscalls.c,v
> retrieving revision 1.148
> diff -u -p -r1.148 uipc_syscalls.c
> --- kern/uipc_syscalls.c  26 Jan 2017 01:58:00 -  1.148
> +++ kern/uipc_syscalls.c  2 Feb 2017 16:59:45 -
> @@ -962,19 +962,13 @@ sys_setsockopt(struct proc *p, void *v, 
>   goto bad;
>   }
>   }
> - if (m == NULL) {
> - error = ENOBUFS;
> - goto bad;
> - }
>   error = copyin(SCARG(uap, val), mtod(m, caddr_t),
>   SCARG(uap, valsize));
> - if (error) {
> + if (error)
>   goto bad;
> - }
>   m->m_len = SCARG(uap, valsize);
>   }
>   error = sosetopt(fp->f_data, SCARG(uap, level), SCARG(uap, name), m);
> - m = NULL;
>  bad:
>   m_freem(m);
>   FRELE(fp, p);
> Index: net/rtsock.c
> ===
> RCS file: /cvs/src/sys/net/rtsock.c,v
> retrieving revision 1.222
> diff -u -p -r1.222 rtsock.c
> --- net/rtsock.c  1 Feb 2017 20:59:47 -   1.222
> +++ net/rtsock.c  2 Feb 2017 16:59:45 -
> @@ -240,12 +240,8 @@ route_ctloutput(int op, struct socket *s
>   int error = 0;
>   unsigned int tid;
>  
> - if (level != AF_ROUTE) {
> - error = EINVAL;
> - if (op == PRCO_SETOPT && m)
> - m_free(m);
> - return (error);
> - }
> + if (level != AF_ROUTE)
> + return EINVAL;
>  
>   switch (op) {
>   case PRCO_SETOPT:
> @@ -271,7 +267,6 @@ route_ctloutput(int op, struct socket *s
>   error = ENOPROTOOPT;
>   break;
>   }
> - m_free(m);
>   break;
>   case PRCO_GETOPT:
>   switch (optname) {
> Index: netinet/ip_mroute.c
> ===
> RCS file: /cvs/src/sys/netinet/ip_mroute.c,v
> retrieving revision 1.108
> diff -u -p -r1.108 ip_mroute.c
> --- netinet/ip_mroute.c   1 Feb 2017 20:59:47