Re: Add Intel Optane P1600X to pcidevs

[Andreas Bartelt]

Hi,

forgot to include the corresponding dmesg output:
nvme1 at pci20 dev 0 function 0 "Intel P1600X" rev 0x00: msix, NVMe 1.1
nvme1: INTEL SSDPEK1A118GA, firmware U5110550, serial BTOC14120X9P118B

Could this please be committed?

Best regards
Andreas

On 8/20/23 14:00, Andreas Bartelt wrote:

Hi,

Intel Optane P1600X Series SSDs are not yet identified in CURRENT (e.g., 
https://www.intel.com/content/www/us/en/products/sku/211867/intel-optane-ssd-p1600x-series-118gb-m-2-80mm-pcie-3-0-x4-3d-xpoint/specifications.html ).


The following patch adds a suitable description (tested with 118GB model).

Index: src/sys/dev/pci/pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.2045
diff -u -p -r1.2045 pcidevs
--- src/sys/dev/pci/pcidevs    9 Aug 2023 21:27:47 -    1.2045
+++ src/sys/dev/pci/pcidevs    20 Aug 2023 11:53:01 -
@@ -4566,6 +4566,7 @@ product INTEL WL_8265_1    0x24fd    Dual Ban
  product INTEL 82820_HB    0x2501    82820 Host
  product INTEL 82820_AGP    0x250f    82820 AGP
  product INTEL OPTANE    0x2522    Optane
+product INTEL P1600X    0x2525    P1600X
  product INTEL WL_9260_1    0x2526    Dual Band Wireless-AC 9260
  product INTEL 82850_HB    0x2530    82850 Host
  product INTEL 82860_HB    0x2531    82860 Host

Add Intel Optane P1600X to pcidevs

[Andreas Bartelt]

Hi,

Intel Optane P1600X Series SSDs are not yet identified in CURRENT (e.g., 
https://www.intel.com/content/www/us/en/products/sku/211867/intel-optane-ssd-p1600x-series-118gb-m-2-80mm-pcie-3-0-x4-3d-xpoint/specifications.html 
).


The following patch adds a suitable description (tested with 118GB model).

Index: src/sys/dev/pci/pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.2045
diff -u -p -r1.2045 pcidevs
--- src/sys/dev/pci/pcidevs 9 Aug 2023 21:27:47 -   1.2045
+++ src/sys/dev/pci/pcidevs 20 Aug 2023 11:53:01 -
@@ -4566,6 +4566,7 @@ product INTEL WL_8265_1   0x24fd  Dual Ban
 product INTEL 82820_HB 0x2501  82820 Host
 product INTEL 82820_AGP0x250f  82820 AGP
 product INTEL OPTANE   0x2522  Optane
+product INTEL P1600X   0x2525  P1600X
 product INTEL WL_9260_10x2526  Dual Band Wireless-AC 9260
 product INTEL 82850_HB 0x2530  82850 Host
 product INTEL 82860_HB 0x2531  82860 Host

Re: Add Intel Optane DC to pcidevs

[Andreas Bartelt]

On 12/2/22 04:54, Jonathan Gray wrote:

On Sun, Nov 27, 2022 at 03:21:45PM +0100, Andreas Bartelt wrote:

Hi,

Intel Optane DC SSDs are not yet identified in CURRENT (e.g., 
https://ark.intel.com/content/www/us/en/ark/products/201861/intel-optane-ssd-dc-p5800x-series-400gb-2-5in-pcie-x4-3d-xpoint.html
).

The following patch gets rid of the "unknown product 0x4140" output of the
corresponding nvme(4) device (tested with a Intel Optane SSD DC P5800X
Series model):


Optane DC devices don't only use the one device id.

PCI\VEN_8086_0A53.DeviceDesc = "Intel(R) Solid-State Drive DC P3520 Series"
PCI\VEN_8086_0A54.DeviceDesc = "Intel(R) SSD DC 
P4500/4600/4501/4601/4608/4510/4610/4511 Series"
PCI\VEN_8086_0A55.DeviceDesc = "Intel(R) SSD DC P4600 Series"
PCI\VEN_8086_2701.DeviceDesc = "Intel(R) Optane(tm) SSD DC P4800X Series"
PCI\VEN_8086_4140.DeviceDesc = "Intel(R) Optane(tm) SSD DC P5800X Series"


From the previous Optane discussion:

https://marc.info/?l=openbsd-tech=166061996818130=2

How about just P5800X?



Yes, it's unambiguous this way.


Index: pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.2011
diff -u -p -r1.2011 pcidevs
--- pcidevs 11 Nov 2022 07:58:42 -  1.2011
+++ pcidevs 2 Dec 2022 03:44:37 -
@@ -5418,6 +5418,7 @@ product INTEL GMA600_60x4106  GMA 600
  product INTEL GMA600_70x4107  GMA 600
  product INTEL GMA600_80x4108  GMA 600
  product INTEL E600_HB 0x4114  E600 Host
+product INTEL P5800X   0x4140  P5800X
  product INTEL PRO_WL_2200BG   0x4220  PRO/Wireless 2200BG
  product INTEL PRO_WL_2225BG   0x4221  PRO/Wireless 2225BG
  product INTEL PRO_WL_3945ABG_10x4222  PRO/Wireless 3945ABG

Add Intel Optane DC to pcidevs

[Andreas Bartelt]

Hi,

Intel Optane DC SSDs are not yet identified in CURRENT (e.g., 
https://ark.intel.com/content/www/us/en/ark/products/201861/intel-optane-ssd-dc-p5800x-series-400gb-2-5in-pcie-x4-3d-xpoint.html 
).


The following patch gets rid of the "unknown product 0x4140" output of 
the corresponding nvme(4) device (tested with a Intel Optane SSD DC 
P5800X Series model):


Index: src/sys/dev/pci/pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.2011
diff -u -p -r1.2011 pcidevs
--- src/sys/dev/pci/pcidevs 11 Nov 2022 07:58:42 -  1.2011
+++ src/sys/dev/pci/pcidevs 27 Nov 2022 13:51:00 -
@@ -5418,6 +5418,7 @@ product INTEL GMA600_60x4106  GMA 600
 product INTEL GMA600_7 0x4107  GMA 600
 product INTEL GMA600_8 0x4108  GMA 600
 product INTEL E600_HB  0x4114  E600 Host
+product INTEL OPTANE_DC0x4140  Optane DC
 product INTEL PRO_WL_2200BG0x4220  PRO/Wireless 2200BG
 product INTEL PRO_WL_2225BG0x4221  PRO/Wireless 2225BG
 product INTEL PRO_WL_3945ABG_1 0x4222  PRO/Wireless 3945ABG

Index: src/sys/dev/pci/pcidevs.h
===
RCS file: /cvs/src/sys/dev/pci/pcidevs.h,v
retrieving revision 1.2005
diff -u -p -r1.2005 pcidevs.h
--- src/sys/dev/pci/pcidevs.h   11 Nov 2022 07:59:19 -  1.2005
+++ src/sys/dev/pci/pcidevs.h   27 Nov 2022 13:51:24 -
@@ -5423,6 +5423,7 @@
 #definePCI_PRODUCT_INTEL_GMA600_7  0x4107  /* GMA 600 */
 #definePCI_PRODUCT_INTEL_GMA600_8  0x4108  /* GMA 600 */
 #definePCI_PRODUCT_INTEL_E600_HB   0x4114  /* E600 Host */
+#definePCI_PRODUCT_INTEL_OPTANE_DC 0x4140  /* Optane DC */
 #definePCI_PRODUCT_INTEL_PRO_WL_2200BG 0x4220  /* PRO/Wireless 
2200BG */
 #definePCI_PRODUCT_INTEL_PRO_WL_2225BG 0x4221  /* PRO/Wireless 
2225BG */
 #define	PCI_PRODUCT_INTEL_PRO_WL_3945ABG_1	0x4222		/* PRO/Wireless 
3945ABG */


Index: src/sys/dev/pci/pcidevs_data.h
===
RCS file: /cvs/src/sys/dev/pci/pcidevs_data.h,v
retrieving revision 1.2000
diff -u -p -r1.2000 pcidevs_data.h
--- src/sys/dev/pci/pcidevs_data.h  11 Nov 2022 07:59:20 -  1.2000
+++ src/sys/dev/pci/pcidevs_data.h  27 Nov 2022 13:51:45 -
@@ -19068,6 +19068,10 @@ static const struct pci_known_product pc
"E600 Host",
},
{
+   PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_OPTANE_DC,
+   "Optane DC",
+   },
+   {
PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_PRO_WL_2200BG,
"PRO/Wireless 2200BG",
},

Best regards
Andreas

Re: Add Intel Optane 900P/905P NVMe

[Andreas Bartelt]

On 8/16/22 05:22, Jonathan Gray wrote:

On Sun, Aug 14, 2022 at 04:03:59PM +0200, Andreas Bartelt wrote:

Hi,

Intel Optane 905p NVMe devices were not yet recognized in CURRENT (e.g., 
https://ark.intel.com/content/www/us/en/ark/products/148607/intel-optane-ssd-905p-series-380gb-m-2-110mm-pcie-x4-20nm-3d-xpoint.html
).

I've managed to get it working with the following diff:

Index: pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.2000
diff -u -p -u -p -r1.2000 pcidevs
--- pcidevs 2 Aug 2022 05:35:01 -   1.2000
+++ pcidevs 14 Aug 2022 13:46:32 -
@@ -4623,6 +4623,7 @@ product INTEL 6321ESB_ACM 0x2699  6321ESB
  product INTEL 6321ESB_HDA 0x269a  6321ESB HD Audio
  product INTEL 6321ESB_SMB 0x269b  6321ESB SMBus
  product INTEL 6321ESB_IDE 0x269e  6321ESB IDE
+product INTEL NVME_6   0x2700  Optane 900P/905P NVMe
  product INTEL WL_22500_1  0x2723  Wi-Fi 6 AX200
  product INTEL WL_22500_9  0x2725  Wi-Fi 6 AX210
  product INTEL WL_22500_10 0x2726  Wi-Fi 6 AX211

Index: pcidevs.h
===
RCS file: /cvs/src/sys/dev/pci/pcidevs.h,v
retrieving revision 1.1994
diff -u -p -u -p -r1.1994 pcidevs.h
--- pcidevs.h   2 Aug 2022 05:35:34 -   1.1994
+++ pcidevs.h   14 Aug 2022 13:48:44 -
@@ -4628,6 +4628,7 @@
  #define   PCI_PRODUCT_INTEL_6321ESB_HDA   0x269a  /* 6321ESB HD 
Audio */
  #define   PCI_PRODUCT_INTEL_6321ESB_SMB   0x269b  /* 6321ESB 
SMBus */
  #define   PCI_PRODUCT_INTEL_6321ESB_IDE   0x269e  /* 6321ESB IDE 
*/
+#define PCI_PRODUCT_INTEL_NVME_6   0x2700  /* Optane 900P/905P 
NVMe */
  #define   PCI_PRODUCT_INTEL_WL_22500_10x2723  /* Wi-Fi 6 
AX200 */
  #define   PCI_PRODUCT_INTEL_WL_22500_90x2725  /* Wi-Fi 6 
AX210 */
  #define   PCI_PRODUCT_INTEL_WL_22500_10   0x2726  /* Wi-Fi 6 
AX211 */

Index: pcidevs_data.h
===
RCS file: /cvs/src/sys/dev/pci/pcidevs_data.h,v
retrieving revision 1.1989
diff -u -p -u -p -r1.1989 pcidevs_data.h
--- pcidevs_data.h  2 Aug 2022 05:35:34 -   1.1989
+++ pcidevs_data.h  14 Aug 2022 13:49:55 -
@@ -15888,6 +15888,10 @@ static const struct pci_known_product pc
"6321ESB IDE",
},
{
+   PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_NVME_6,
+   "Optane 900P/905P NVMe",
+   },
+   {
PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_22500_1,
"Wi-Fi 6 AX200",
},

I've also noticed the following in nvme_pci.c which seems to be related to
some kind of Intel Optane device:
81 static const struct pci_matchid nvme_msi_blacklist[] = {
  82 { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_OPTANE },
  83 };

It is unclear to me if this is also relevant for the Optane 900P/905P
series, i.e., should the line "{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_NVME_6
}," also be added there? [didn't notice any problems yet without having the
device included there...]

The affected parts of dmesg after applying the patch:
nvme1 at pci4 dev 0 function 0 "Intel Optane 900P/905P NVMe" rev 0x00: msix,
NVMe 1.0
nvme1: INTEL SSDPEL1D380GA, firmware E2010603, serial PHMC93620015380A
scsibus3 at nvme1: 2 targets, initiator 0
sd1 at scsibus3 targ 1 lun 0: 
sd1: 362476MB, 512 bytes/sector, 742352688 sectors


Intel's windows driver uses

PCI\VEN_8086_F1A6.DeviceDesc = "Intel(R) SSD Pro 7600p/760p/E 6100p Series"
PCI\VEN_8086_F1A8.DeviceDesc = "Intel(R) SSD 660p Series"
PCI\VEN_8086_FAF0.DeviceDesc = "Intel(R) SSD 665p Series"
PCI\VEN_8086_0953.DeviceDesc = "Intel(R) Solid-State Drive 
P3700/P3600/P3500/P3520/750 Series"
PCI\VEN_8086_0A53.DeviceDesc = "Intel(R) Solid-State Drive DC P3520 Series"
PCI\VEN_8086_0A54.DeviceDesc = "Intel(R) SSD DC 
P4500/4600/4501/4601/4608/4510/4610/4511 Series"
PCI\VEN_8086_0A55.DeviceDesc = "Intel(R) SSD DC P4600 Series"
PCI\VEN_8086_2700.DeviceDesc = "Intel(R) Optane(tm) SSD 900P/905P Series"
PCI\VEN_8086_2701.DeviceDesc = "Intel(R) Optane(tm) SSD DC P4800X Series"
PCI\VEN_8086_0B60.DeviceDesc = "Intel(R) SSD D7-P5500/P5600 Series"
PCI\VEN_8086_4140.DeviceDesc = "Intel(R) Optane(tm) SSD DC P5800X Series"
PCI\VEN_8086_2525.DeviceDesc = "Intel(R) SSD P1600X Series"

900P/905P are referred to as "Intel Optane SSD 9 Series" on
https://ark.intel.com/content/www/us/en/ark/products/series/213701/intel-optane-ssd-9-series.html

Index: sys/dev/pci/pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.2000
diff -u -p -r1.2000 pcidevs
--- sys/dev/pci/pcidevs 2 Aug 2022 05:35:01 -   1.2

Add Intel Optane 900P/905P NVMe

[Andreas Bartelt]

Hi,

Intel Optane 905p NVMe devices were not yet recognized in CURRENT (e.g., 
https://ark.intel.com/content/www/us/en/ark/products/148607/intel-optane-ssd-905p-series-380gb-m-2-110mm-pcie-x4-20nm-3d-xpoint.html 
).


I've managed to get it working with the following diff:

Index: pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.2000
diff -u -p -u -p -r1.2000 pcidevs
--- pcidevs 2 Aug 2022 05:35:01 -   1.2000
+++ pcidevs 14 Aug 2022 13:46:32 -
@@ -4623,6 +4623,7 @@ product INTEL 6321ESB_ACM 0x2699  6321ESB
 product INTEL 6321ESB_HDA  0x269a  6321ESB HD Audio
 product INTEL 6321ESB_SMB  0x269b  6321ESB SMBus
 product INTEL 6321ESB_IDE  0x269e  6321ESB IDE
+product INTEL NVME_6   0x2700  Optane 900P/905P NVMe
 product INTEL WL_22500_1   0x2723  Wi-Fi 6 AX200
 product INTEL WL_22500_9   0x2725  Wi-Fi 6 AX210
 product INTEL WL_22500_10  0x2726  Wi-Fi 6 AX211

Index: pcidevs.h
===
RCS file: /cvs/src/sys/dev/pci/pcidevs.h,v
retrieving revision 1.1994
diff -u -p -u -p -r1.1994 pcidevs.h
--- pcidevs.h   2 Aug 2022 05:35:34 -   1.1994
+++ pcidevs.h   14 Aug 2022 13:48:44 -
@@ -4628,6 +4628,7 @@
 #definePCI_PRODUCT_INTEL_6321ESB_HDA   0x269a  /* 6321ESB HD 
Audio */
 #definePCI_PRODUCT_INTEL_6321ESB_SMB   0x269b  /* 6321ESB 
SMBus */
 #definePCI_PRODUCT_INTEL_6321ESB_IDE   0x269e  /* 6321ESB IDE 
*/
+#define PCI_PRODUCT_INTEL_NVME_6   0x2700  /* Optane 900P/905P 
NVMe */
 #definePCI_PRODUCT_INTEL_WL_22500_10x2723  /* Wi-Fi 6 
AX200 */
 #definePCI_PRODUCT_INTEL_WL_22500_90x2725  /* Wi-Fi 6 
AX210 */
 #definePCI_PRODUCT_INTEL_WL_22500_10   0x2726  /* Wi-Fi 6 
AX211 */

Index: pcidevs_data.h
===
RCS file: /cvs/src/sys/dev/pci/pcidevs_data.h,v
retrieving revision 1.1989
diff -u -p -u -p -r1.1989 pcidevs_data.h
--- pcidevs_data.h  2 Aug 2022 05:35:34 -   1.1989
+++ pcidevs_data.h  14 Aug 2022 13:49:55 -
@@ -15888,6 +15888,10 @@ static const struct pci_known_product pc
"6321ESB IDE",
},
{
+   PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_NVME_6,
+   "Optane 900P/905P NVMe",
+   },
+   {
PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_WL_22500_1,
"Wi-Fi 6 AX200",
},

I've also noticed the following in nvme_pci.c which seems to be related 
to some kind of Intel Optane device:

81 static const struct pci_matchid nvme_msi_blacklist[] = {
 82 { PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_OPTANE },
 83 };

It is unclear to me if this is also relevant for the Optane 900P/905P 
series, i.e., should the line "{ PCI_VENDOR_INTEL, 
PCI_PRODUCT_INTEL_NVME_6 }," also be added there? [didn't notice any 
problems yet without having the device included there...]


The affected parts of dmesg after applying the patch:
nvme1 at pci4 dev 0 function 0 "Intel Optane 900P/905P NVMe" rev 0x00: 
msix, NVMe 1.0

nvme1: INTEL SSDPEL1D380GA, firmware E2010603, serial PHMC93620015380A
scsibus3 at nvme1: 2 targets, initiator 0
sd1 at scsibus3 targ 1 lun 0: 
sd1: 362476MB, 512 bytes/sector, 742352688 sectors

Best regards
Andreas

Re: SSHFP with EDNS0/DNSSEC

[Andreas Bartelt]

On 07/12/17 18:49, Jeremie Courreges-Anglas wrote:

Eric Faurot  writes:


On Wed, Jul 12, 2017 at 07:45:36AM +0200, Christian Barthel wrote:

Hi,

earlier this year, jca@ worked on support for DNSSEC and the EDNS0
extension [1] and committed this work at [2] (thanks!).  I tried this
with SSHFP records to check authenticity of hosts with DNSSEC; but ssh
reported that the hostkey fingerprints were insecure.

I am using this configuration file:

# cat /etc/resolv.conf
nameserver 8.8.8.8
options edns0

And ssh reports the following:

$ ssh -o VerifyHostKeyDNS=yes - doamin_with_sshpf_dnssec
   ...
debug3: verify_host_key_dns
debug1: found 8 insecure fingerprints in DNS
debug1: matching host key fingerprint found in DNS
The authenticity of host 'xxx ()' can't be established.
ECDSA key fingerprint is 
Matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)?
   ...

I tried to find out why and after going through the asr code, I found
the following:

Index: lib/libc/asr/res_send_async.c
===
RCS file: /cvs/src/lib/libc/asr/res_send_async.c,v
retrieving revision 1.36
diff -u -p -r1.36 res_send_async.c
--- lib/libc/asr/res_send_async.c   15 Mar 2017 15:54:41 -  1.36
+++ lib/libc/asr/res_send_async.c   11 Jul 2017 20:09:59 -
@@ -385,7 +385,7 @@ setup_query(struct asr_query *as, const
_asr_pack_query(, type, class, dname);
if (as->as_ctx->ac_options & (RES_USE_EDNS0 | RES_USE_DNSSEC))
_asr_pack_edns0(, MAXPACKETSZ,
-   as->as_ctx->ac_options & RES_USE_DNSSEC);
+   as->as_ctx->ac_options & (RES_USE_EDNS0 | RES_USE_DNSSEC));
if (p.err) {
DPRINT("error packing query");
errno = EINVAL;


The current code is correct, RES_USE_EDNS0 does not imply RES_USE_DNSSEC.
The real problem is that there is no resolv.conf option for RES_USE_DNSSEC.


RES_USE_DNSSEC is set by applications that *do* care about the AD bit.
There's no point in setting globally RES_USE_DNSSEC, so I don't think we
need a resolv.conf option.



I recently ran into the same problem regarding the ssh(1) warning. I 
don't understand yet why a global option in resolv.conf would be 
pointless or a bad idea. For example, the following simple patch seems 
to work for me, and I didn't observe any side effects yet:


Index: src/lib/libc/asr/asr.c
===
RCS file: /cvs/src/lib/libc/asr/asr.c,v
retrieving revision 1.57
diff -u -p -u -r1.57 asr.c
--- src/lib/libc/asr/asr.c  27 Feb 2017 10:44:46 -  1.57
+++ src/lib/libc/asr/asr.c  7 Sep 2017 15:15:44 -
@@ -597,6 +597,8 @@ pass0(char **tok, int n, struct asr_ctx
ac->ac_options |= RES_USEVC;
else if (!strcmp(tok[i], "edns0"))
ac->ac_options |= RES_USE_EDNS0;
+   else if (!strcmp(tok[i], "dnssec"))
+   ac->ac_options |= (RES_USE_DNSSEC | 
RES_USE_EDNS0);
else if ((!strncmp(tok[i], "ndots:", 6))) {
e = NULL;
d = strtonum(tok[i] + 6, 1, 16, );

What am I missing here?


It can only be set in user code by tweaking _res.options.


ssh(1) uses getrrsetbyname(3) to look at SSHFP records, so the fix is to
teach getrrsetbyname to request DNSSEC processing.  Eric and I have
already discussed this and need to settle on the implementation.

Re: [patch] ocspcheck: nextUpdate is optional according to RFC 6960

[Andreas Bartelt]

On 09/06/17 16:24, Bob Beck wrote:

effectivelyu providing a limitless OCSP staple is kind of stupid - you may
as well simply *not staple*



I guess a stapled response without the next_update field set would be 
treated as valid until the client considers this_update to be too old 
(for ocspcheck, this seems to be set to 14 days via MAXAGE_SEC). In the 
case of stapling, I agree that it typically would be much better to use 
a short period for next_update than not to provide it at all.


In my case, I didn't want to use ocspcheck specifically for storing OCSP 
responses for stapling but in order to check if my local OCSP responder 
is actually working (i.e., the out-of-band way). In the out-of-band 
case, clients could also check for freshness by using nonces.


During these kinds of tests, I've also noticed that ocspcheck currently 
only connects to HTTP and HTTPS over their well-known ports which seems 
to be fine for all public CAs but not necessarily for all local CAs with 
a corresponding OCSP daemon.


In case this lack of flexibility is intended in order to keep the tool 
simple, I'm also fine with it.

Re: [patch] ocspcheck: nextUpdate is optional according to RFC 6960

[Andreas Bartelt]

On 09/06/17 04:40, Bob Beck wrote:

Andreas where are you seeing this as being a real issue - who is shipping
out OCSP responses without a next update field?



I've noticed this while playing with a local CA and a corresponding OCSP 
responder on my LAN. For openssl ocsp, the -nmin or -ndays argument is 
optional. If these arguments are not explicitly provided, the next 
update field will not be set.





On Sat, Sep 2, 2017 at 11:28 AM, Andreas Bartelt <o...@bartula.de> wrote:


ocspcheck effectively treats a missing nextUpdate like an error, i.e., it
always provides a warning and no staplefile is written out. According to
RFC 6960, the nextUpdate field is optional. The following patch should
handle this case more gracefully and include a suitable debug message only
in case -vv is specified.

OK?

Index: src/usr.sbin/ocspcheck/ocspcheck.c
===
RCS file: /cvs/src/usr.sbin/ocspcheck/ocspcheck.c,v
retrieving revision 1.21
diff -u -p -u -r1.21 ocspcheck.c
--- src/usr.sbin/ocspcheck/ocspcheck.c  8 May 2017 20:15:34 -
  1.21
+++ src/usr.sbin/ocspcheck/ocspcheck.c  2 Sep 2017 17:09:00 -
@@ -368,7 +368,7 @@ validate_response(char *buf, size_t size
  {
 ASN1_GENERALIZEDTIME *revtime = NULL, *thisupd = NULL, *nextupd =
NULL;
 const unsigned char **p = (const unsigned char **)
-   int status, cert_status=0, crl_reason=0;
+   int status, cert_status=0, crl_reason=0, next_update=0;
 time_t now, rev_t = -1, this_t, next_t;
 OCSP_RESPONSE *resp;
 OCSP_BASICRESP *bresp;
@@ -447,12 +447,14 @@ validate_response(char *buf, size_t size
 return 0;
 }
 if ((next_t = parse_ocsp_time(nextupd)) == -1) {
-   warnx("unable to parse next update time in OCSP reply");
-   return 0;
+   if (verbose >= 2)
+   fprintf(stderr, "Optional timestamp for next
update not included in OCSP reply\n");
 }
+   else
+   next_update = 1;

 /* Don't allow this update to precede next update */
-   if (this_t >= next_t) {
+   if (next_update == 1 && this_t >= next_t) {
 warnx("Invalid OCSP reply: this update >= next update");
 return 0;
 }
@@ -481,7 +483,7 @@ validate_response(char *buf, size_t size
 /*
  * Check that next update is still valid
  */
-   if (next_t < now - JITTER_SEC) {
+   if (next_update == 1 && next_t < now - JITTER_SEC) {
 warnx("Invalid OCSP reply: reply has expired (%s)",
 ctime(_t));
 return 0;
@@ -489,7 +491,8 @@ validate_response(char *buf, size_t size

 vspew("OCSP response validated from %s\n", host);
 vspew("This Update: %s", ctime(_t));
-   vspew("Next Update: %s", ctime(_t));
+   if (next_update == 1)
+   vspew("Next Update: %s", ctime(_t));
 return 1;
  }

Re: [patch] ocspcheck: nextUpdate is optional according to RFC 6960

[Andreas Bartelt]

On 09/06/17 04:40, Bob Beck wrote:

Andreas where are you seeing this as being a real issue - who is shipping
out OCSP responses without a next update field?



I've noticed this while playing with a local CA and a corresponding OCSP 
responder on my LAN. For openssl ocsp, the -nmin or -ndays argument is 
optional. If these arguments are not explicitly provided, the next 
update field will not be set.





On Sat, Sep 2, 2017 at 11:28 AM, Andreas Bartelt <o...@bartula.de> wrote:


ocspcheck effectively treats a missing nextUpdate like an error, i.e., it
always provides a warning and no staplefile is written out. According to
RFC 6960, the nextUpdate field is optional. The following patch should
handle this case more gracefully and include a suitable debug message only
in case -vv is specified.

OK?

Index: src/usr.sbin/ocspcheck/ocspcheck.c
===
RCS file: /cvs/src/usr.sbin/ocspcheck/ocspcheck.c,v
retrieving revision 1.21
diff -u -p -u -r1.21 ocspcheck.c
--- src/usr.sbin/ocspcheck/ocspcheck.c  8 May 2017 20:15:34 -
  1.21
+++ src/usr.sbin/ocspcheck/ocspcheck.c  2 Sep 2017 17:09:00 -
@@ -368,7 +368,7 @@ validate_response(char *buf, size_t size
  {
 ASN1_GENERALIZEDTIME *revtime = NULL, *thisupd = NULL, *nextupd =
NULL;
 const unsigned char **p = (const unsigned char **)
-   int status, cert_status=0, crl_reason=0;
+   int status, cert_status=0, crl_reason=0, next_update=0;
 time_t now, rev_t = -1, this_t, next_t;
 OCSP_RESPONSE *resp;
 OCSP_BASICRESP *bresp;
@@ -447,12 +447,14 @@ validate_response(char *buf, size_t size
 return 0;
 }
 if ((next_t = parse_ocsp_time(nextupd)) == -1) {
-   warnx("unable to parse next update time in OCSP reply");
-   return 0;
+   if (verbose >= 2)
+   fprintf(stderr, "Optional timestamp for next
update not included in OCSP reply\n");
 }
+   else
+   next_update = 1;

 /* Don't allow this update to precede next update */
-   if (this_t >= next_t) {
+   if (next_update == 1 && this_t >= next_t) {
 warnx("Invalid OCSP reply: this update >= next update");
 return 0;
 }
@@ -481,7 +483,7 @@ validate_response(char *buf, size_t size
 /*
  * Check that next update is still valid
  */
-   if (next_t < now - JITTER_SEC) {
+   if (next_update == 1 && next_t < now - JITTER_SEC) {
 warnx("Invalid OCSP reply: reply has expired (%s)",
 ctime(_t));
 return 0;
@@ -489,7 +491,8 @@ validate_response(char *buf, size_t size

 vspew("OCSP response validated from %s\n", host);
 vspew("This Update: %s", ctime(_t));
-   vspew("Next Update: %s", ctime(_t));
+   if (next_update == 1)
+   vspew("Next Update: %s", ctime(_t));
 return 1;
  }

[patch] ocspcheck: nextUpdate is optional according to RFC 6960

[Andreas Bartelt]

ocspcheck effectively treats a missing nextUpdate like an error, i.e., 
it always provides a warning and no staplefile is written out. According 
to RFC 6960, the nextUpdate field is optional. The following patch 
should handle this case more gracefully and include a suitable debug 
message only in case -vv is specified.


OK?

Index: src/usr.sbin/ocspcheck/ocspcheck.c
===
RCS file: /cvs/src/usr.sbin/ocspcheck/ocspcheck.c,v
retrieving revision 1.21
diff -u -p -u -r1.21 ocspcheck.c
--- src/usr.sbin/ocspcheck/ocspcheck.c  8 May 2017 20:15:34 -   1.21
+++ src/usr.sbin/ocspcheck/ocspcheck.c  2 Sep 2017 17:09:00 -
@@ -368,7 +368,7 @@ validate_response(char *buf, size_t size
 {
ASN1_GENERALIZEDTIME *revtime = NULL, *thisupd = NULL, *nextupd = NULL;
const unsigned char **p = (const unsigned char **)
-   int status, cert_status=0, crl_reason=0;
+   int status, cert_status=0, crl_reason=0, next_update=0;
time_t now, rev_t = -1, this_t, next_t;
OCSP_RESPONSE *resp;
OCSP_BASICRESP *bresp;
@@ -447,12 +447,14 @@ validate_response(char *buf, size_t size
return 0;
}
if ((next_t = parse_ocsp_time(nextupd)) == -1) {
-   warnx("unable to parse next update time in OCSP reply");
-   return 0;
+   if (verbose >= 2)
+			fprintf(stderr, "Optional timestamp for next update not included in 
OCSP reply\n");

}
+   else
+   next_update = 1;

/* Don't allow this update to precede next update */
-   if (this_t >= next_t) {
+   if (next_update == 1 && this_t >= next_t) {
warnx("Invalid OCSP reply: this update >= next update");
return 0;
}
@@ -481,7 +483,7 @@ validate_response(char *buf, size_t size
/*
 * Check that next update is still valid
 */
-   if (next_t < now - JITTER_SEC) {
+   if (next_update == 1 && next_t < now - JITTER_SEC) {
warnx("Invalid OCSP reply: reply has expired (%s)",
ctime(_t));
return 0;
@@ -489,7 +491,8 @@ validate_response(char *buf, size_t size

vspew("OCSP response validated from %s\n", host);
vspew("   This Update: %s", ctime(_t));
-   vspew("   Next Update: %s", ctime(_t));
+   if (next_update == 1)
+   vspew("   Next Update: %s", ctime(_t));
return 1;
 }

[patch] make cipher list preference configurable in httpd

[Andreas Bartelt]

The following patch makes the TLS cipher list preference (server vs. 
client) configurable in httpd (like in relayd):



Index: src/usr.sbin/httpd/config.c
===
RCS file: /cvs/src/usr.sbin/httpd/config.c,v
retrieving revision 1.53
diff -u -p -u -r1.53 config.c
--- src/usr.sbin/httpd/config.c 19 Jul 2017 17:36:25 -  1.53
+++ src/usr.sbin/httpd/config.c 16 Aug 2017 12:40:59 -
@@ -472,6 +472,8 @@ config_getserver_config(struct httpd *en
srv_conf->hsts_max_age = parent->hsts_max_age;
srv_conf->hsts_flags = parent->hsts_flags;

+   srv_conf->tls_flags = parent->tls_flags;
+
memcpy(_conf->timeout, >timeout,
sizeof(srv_conf->timeout));
srv_conf->maxrequests = parent->maxrequests;
Index: src/usr.sbin/httpd/httpd.conf.5
===
RCS file: /cvs/src/usr.sbin/httpd/httpd.conf.5,v
retrieving revision 1.84
diff -u -p -u -r1.84 httpd.conf.5
--- src/usr.sbin/httpd/httpd.conf.5 11 Aug 2017 20:30:45 -  1.84
+++ src/usr.sbin/httpd/httpd.conf.5 16 Aug 2017 12:40:59 -
@@ -518,6 +518,10 @@ The
 should contain a PEM encoded certificate.
 The default is
 .Pa /etc/ssl/server.crt .
+.It Oo Ic no Oc Ic cipher-server-preference
+Prefer the server's cipher list over the client's preferences when
+choosing a cipher for the connection.
+This is enabled by default.
 .It Ic ciphers Ar string
 Specify the TLS cipher string.
 If not specified, the default value
Index: src/usr.sbin/httpd/httpd.h
===
RCS file: /cvs/src/usr.sbin/httpd/httpd.h,v
retrieving revision 1.134
diff -u -p -u -r1.134 httpd.h
--- src/usr.sbin/httpd/httpd.h  11 Aug 2017 18:48:56 -  1.134
+++ src/usr.sbin/httpd/httpd.h  16 Aug 2017 12:40:59 -
@@ -416,6 +416,8 @@ SPLAY_HEAD(client_tree, client);
"\10\01NODELAY\02NO_NODELAY\03SACK\04NO_SACK" \
"\05SOCKET_BUFFER_SIZE\06IP_TTL\07IP_MINTTL\10NO_SPLICE"

+#define TLSFLAG_CIPHER_SERVER_PREF 0x01
+
 #define HSTSFLAG_SUBDOMAINS0x01
 #define HSTSFLAG_PRELOAD   0x02
 #define HSTSFLAG_BITS  "\10\01SUBDOMAINS\02PRELOAD"
@@ -514,6 +516,8 @@ struct server_config {

int  hsts_max_age;
uint8_t  hsts_flags;
+
+   uint8_t  tls_flags;

TAILQ_ENTRY(server_config) entry;
 };
Index: src/usr.sbin/httpd/parse.y
===
RCS file: /cvs/src/usr.sbin/httpd/parse.y,v
retrieving revision 1.91
diff -u -p -u -r1.91 parse.y
--- src/usr.sbin/httpd/parse.y  11 Aug 2017 18:48:56 -  1.91
+++ src/usr.sbin/httpd/parse.y  16 Aug 2017 12:40:59 -
@@ -129,12 +129,13 @@ typedef struct {

 %}

-%token	ACCESS ALIAS AUTO BACKLOG BODY BUFFER CERTIFICATE CHROOT CIPHERS 
COMMON
-%token	COMBINED CONNECTION DHE DIRECTORY ECDHE ERR FCGI INDEX IP KEY 
LIFETIME
-%token	LISTEN LOCATION LOG LOGDIR MATCH MAXIMUM NO NODELAY OCSP ON PORT 
PREFORK
-%token	PROTOCOLS REQUESTS ROOT SACK SERVER SOCKET STRIP STYLE SYSLOG 
TCP TICKET
-%token	TIMEOUT TLS TYPE TYPES HSTS MAXAGE SUBDOMAINS DEFAULT PRELOAD 
REQUEST

-%token ERROR INCLUDE AUTHENTICATE WITH BLOCK DROP RETURN PASS
+%token	ACCESS ALIAS AUTO BACKLOG BODY BUFFER CERTIFICATE CHROOT 
CIPHERSRVPREF
+%token	CIPHERS COMMON COMBINED CONNECTION DHE DIRECTORY ECDHE ERR FCGI 
INDEX

+%token IP KEY LIFETIME LISTEN LOCATION LOG LOGDIR MATCH MAXIMUM NO NODELAY
+%token	OCSP ON PORT PREFORK PROTOCOLS REQUESTS ROOT SACK SERVER SOCKET 
STRIP
+%token	STYLE SYSLOG TCP TICKET TIMEOUT TLS TYPE TYPES HSTS MAXAGE 
SUBDOMAINS

+%token DEFAULT PRELOAD REQUEST ERROR INCLUDE AUTHENTICATE WITH BLOCK DROP
+%token RETURN PASS
 %token STRING
 %token NUMBER
 %typeport
@@ -260,6 +261,7 @@ server  : SERVER optmatch STRING{
if ((s->srv_conf.tls_key_file =
strdup(HTTPD_TLS_KEY)) == NULL)
fatal("out of memory");
+   s->srv_conf.tls_flags = TLSFLAG_CIPHER_SERVER_PREF;
strlcpy(s->srv_conf.tls_ciphers,
HTTPD_TLS_CIPHERS,
sizeof(s->srv_conf.tls_ciphers));
@@ -727,6 +729,12 @@ tlsopts: CERTIFICATE STRING{
fatal("out of memory");
free($2);
}
+   | CIPHERSRVPREF {
+   srv_conf->tls_flags |= TLSFLAG_CIPHER_SERVER_PREF;
+   }
+   | NO CIPHERSRVPREF  {
+   srv_conf->tls_flags &= ~TLSFLAG_CIPHER_SERVER_PREF;
+   }
| CIPHERS STRING{
if (strlcpy(srv_conf->tls_ciphers, $2,

Default TLS configuration of httpd / libtls

[Andreas Bartelt]

After responding to a question on misc@ ( 
http://marc.info/?l=openbsd-misc=150280482525307=2 ), I've noticed 
that the part of my response with regard to default-enabled TLS cipher 
suites on current was wrong. I was testing with an ECDSA-based instead 
of an RSA-based certificate which renders the set of enabled cipher 
suites significantly shorter.


In case an RSA-based certificate is used with httpd on current, the 
following cipher suites are currently enabled by default:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
OLD_TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA

I am surprised why the set of default-enabled cipher suites is so large. 
According to httpd.conf(5), it maps to "HIGH:!aNULL" which corresponds 
to "compat" in libtls's tls_config_set_ciphers(). I then did some more 
tests on the available cipher suite keywords/profiles in libtls (the 
following discussion is based on tests with an RSA-based certificate).


tls_config_set_ciphers defines the following 4 profiles:
1) secure / default
since RFC 7905 is over a year old now, shouldn't 
OLD_TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 be removed from this set?


2) compat
3) legacy

These two profiles currently only differ by one cipher suite which is 
TLS_RSA_WITH_3DES_EDE_CBC_SHA in 'legacy'. However, 'compat' also 
contains a 3DES cipher suite which is 
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA -- I guess this one should not be 
classified as "HIGH" and only be listed in 'legacy' (since security 
level <128 bits) but not in 'compat'.


It's not clear to me at which point in time CAMELLIA cipher suites have 
been added to 'compat' and 'legacy'. There was a previous discussion on 
tech@ about adding them to libssl/libtls as an option but not enabling 
them by default ( http://marc.info/?l=openbsd-tech=147213883819627=2 
). I don't find a commit which explicitly enabled CAMELLIA cipher suites 
by default -- did they accidentally sneak into httpd's default TLS 
config due to the use of openssl's ciphers strings?


In case an ECDSA-based certificate is used, the 'compat' profile 
implicitly corresponds to ECDHE-only cipher suites (since all 
ECDSA-based cipher suites provide forward secrecy). Wouldn't it make 
sense to also remove all RSA key transport based cipher suites from 
'compat' in the case of RSA-based certificates? In case RSA key 
transport cipher suites would remain in 'legacy', this would also 
provide better differentiation between these two profiles.


4) insecure / all

Since this profile includes RC4 and DES cipher suites, I guess we all 
agree that these should never be used. In case someone actually wants to 
enable dangerous stuff in libtls, direct use of openssl's ALL ciphers 
string could still be used in order to provide the same damage. Is there 
a sufficiently good reason to keep these keywords in libtls at all?


Best regards
Andreas

Re: specify curves via ecdhe statement in httpd.conf

[Andreas Bartelt]

On 02/06/17 14:44, Joel Sing wrote:

On Sunday 05 February 2017 17:05:40 Andreas Bartelt wrote:

- What type of public certificate are you using (RSA or ECDSA)?


ECDSA with P-256. Certificate signed by letsencrypt (via RSA).
Must-staple is enabled - that's why I'm also using the ocsp line for
testing.


Ah, this was the missing piece of information.

In order to use ECDSA the client must support the curve used for the server
certificate, otherwise when the server signs the server key exchange, the
client will not be able to verify the signature. In the case where you
announce that the client only supports P-384, any ECDSA ciphers are considered
to be invalid for this session, effectively resulting in no shared ciphers and
the handshake failure alert.



Yes, right - thanks. I wasn't aware that this is actually a MUST 
requirement from RFC 4492. I'm quite surprised that the "Supported 
Elliptic Curves Extension" is also used in order to specify any allowed 
curves for use in the context of certificates. I think this is quite 
inconsistent but it's what this RFC seems to mandate. It's inconsistent 
because there is no such binding with regard to -ECDHE-RSA- or -DHE-RSA- 
cipher suites.


I've successfully tested a P-384-based certificate which allowed me to 
explicitly specify -groups secp384r1 for ECDHE on the client side.



In order for this configuration to work you need to include P-256 in the client
supported groups. Specifying groups as "P-384:P-256" should still get you
P-384, depending on the server configuration and whether the preference for a
curve is based on the client or server preference (for libtls and hence httpd,
it will be server preference).



Test 1 (with P-384-based certificate): httpd/libtls's preference seems 
to be hard-coded with the following order: X25519, P-256, P-384. In this 
specific case, the httpd's default tls configuration negotiates 
ECDHE-ECDSA-AES256-GCM-SHA384 which has a target security level of 256 
bits. I suppose P-384 would be the preferred choice for ECDHE in this 
case since the certificate also uses P-384 the other two group choices 
effectively lower the overall security level to ~128 bits? [also see RFC 
7919 for a similar discussion wrt RSA key size and FFDHE parameter choice]


Test 2 (with P-256-based certificate): since httpd's preference is 
hard-coded and P-256 must be specified due to the certificate's public 
key, P-384 is actually never selected for ECDHE - this was what I 
initially noticed with regard to the ecdhe "auto" option. For example, 
secp384r1:prime256v1:X25519 effectively selects X25519 for ECDHE.


I think it would be beneficial to allow to explicitly specify multiple 
groups with the ecdhe statement in httpd.conf, and also to respect their 
order.

Re: specify curves via ecdhe statement in httpd.conf

[Andreas Bartelt]

On 02/05/17 15:41, Joel Sing wrote:

On Sunday 05 February 2017 11:13:16 Andreas Bartelt wrote:

On 02/05/17 07:41, Joel Sing wrote:

You can just specify X25519 as a group - it will not appear in `openssl
ecparam -list_curves' since it is not a standard EC curve.


thanks - I didn't notice that capitalization is important here. Maybe
x25519 and ecdh_x25519 [IANA] should also be accepted as valid names
[http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml].


I'll consider this, however all of the RFCs refer to it as X25519 (e.g.
RFC7748 and draft-ietf-curdle-pkix-03). This is also no different to the fact
that you cannot use 'Prime256v1' or 'p-384'.


The definition of the curve itself is provided in RFC 7748 - RFCs for
some other listed curves (e.g., brainpool) are also only tagged as
Informational. What is missing with regard to X25519?


There is nothing missing as such - X25519 is a function that performs scalar
multiplication on a curve known as curve25519. The X25519 function is in turn
used to perform Diffie-Hellman key exchange. Neither X25519 nor curve25519 fit
the OpenSSL Elliptic Curve API (largely due to design), hence it does not make
sense for it to appear in 'openssl ecparam -list_curves', which would require
it to be treated and manipulated as if it was a standard EC curve.



thanks for the explanation.


This is really weird. Although my test results for X25519 were similarly
confusing -- for simplicity, I'll provide some more results which were
restricted to explicitly testing secp384r1.

[snip]

Error messages when failing against httpd:
 > openssl s_client -connect :443 -servername 

-groups secp384r1
CONNECTED(0003)
1225438578:error:14FFF410:SSL routines:SSL_internal:sslv3 alert
handshake failure:/usr/src/lib/libssl/ssl_pkt.c:1205:SSL alert number 40
1225438578:error:14FFF0E5:SSL routines:SSL_internal:ssl handshake
failure:/usr/src/lib/libssl/ssl_pkt.c:585:


This is the server-side responding with a fatal SSL handshake failure alert -
there are only a few cases where this will happen, the most likely of which is
when there is no matching cipher suite.

- Is there any other configuration that would limit the cipher suites in use?



I've tested the following tls configurations with httpd:
config 1)
tls {
key "/etc/ssl/private/server.key"
certificate "/etc/ssl/server.crt"
ecdhe "secp384r1"
ocsp "/etc/ssl/server_ocsp.der" # [manually fetched a 
fresh one via ocspcheck]

}


config 2)
tls {
key "/etc/ssl/private/server.key"
certificate "/etc/ssl/server.crt"
ecdhe "secp384r1"
ciphers 
"ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA384"

ocsp "/etc/ssl/server_ocsp.der"
}

A fresh /etc/ssl/server_ocsp.der was manually fetched with ocspcheck.


- What cipher suite is used if you connect without specifying -groups?



config 1: ECDHE-ECDSA-AES256-GCM-SHA384
config 2: ECDHE-ECDSA-CHACHA20-POLY1305


- What type of public certificate are you using (RSA or ECDSA)?



ECDSA with P-256. Certificate signed by letsencrypt (via RSA). 
Must-staple is enabled - that's why I'm also using the ocsp line for 
testing.


I could verify that OCSP stapling is not the problem here since I've 
also tested without the ocsp line in httpd.conf [and then using another 
certificate without the encoded "must staple" extension]. Both results 
were identical.



- If you're still unable to get to the bottom of it, try running 'openssl
s_client' with -debug and provide the output.




> openssl s_client -connect www.bartelt.name:443 -servername 
www.bartelt.name -debug -groups secp384r1

CONNECTED(0003)
write to 0x59765414700 [0x59775e64003] (261 bytes => 261 (0x105))
 - 16 03 01 01 00 01 00 00-fc 03 03 79 f3 5f 4c fe   ...y._L.
0010 - 4f b8 30 11 07 81 ba cc-a4 1e 1b 21 da 3f da 0c   O.0!.?..
0020 - 69 b8 f0 12 b9 33 83 75-ac 35 1d 00 00 7e c0 30   i3.u.5...~.0
0030 - c0 2c c0 28 c0 24 c0 14-c0 0a 00 a3 00 9f 00 6b   .,.(.$.k
0040 - 00 6a 00 39 00 38 cc a9-cc a8 cc aa cc 14 cc 13   .j.9.8..
0050 - cc 15 ff 85 00 c4 00 c3-00 88 00 87 00 81 00 9d   
0060 - 00 3d 00 35 00 c0 00 84-c0 2f c0 2b c0 27 c0 23   .=.5./.+.'.#
0070 - c0 13 c0 09 00 a2 00 9e-00 67 00 40 00 33 00 32   .g.@.3.2
0080 - 00 be 00 bd 00 45 00 44-00 9c 00 3c 00 2f 00 ba   .E.D...<./..
0090 - 00 41 c0 11 c0 07 00 05-00 04 c0 12 c0 08 00 16   .A..
00a0 - 00 13 00 0a 00 15 00 12-00 09 00 ff 01 00 00 55   ...U
00b0 - 00 00 00 15 00 13 00 00-10 77 77 77 2e 62 61 72   .www.bar
00c0 - 74 65 6c 74 2e 6e 61 6d-65 00 0b 00 02 01 00 00   telt.name...
00d0 - 0a 00 04 

Re: specify curves via ecdhe statement in httpd.conf

[Andreas Bartelt]

On 02/05/17 11:13, Andreas Bartelt wrote:
...

The following combinations were tested:
server httpd with ecdhe "secp384r1" & server nginx with ssl_ecdh_curve
secp384r1; (identical results)
connect via openssl [secp384r1]: fails
connect via eopenssl [secp384r1]: fails


replying to myself here... this is interesting: in case -groups or 
-curves secp384r1 is omitted on the client side, it also succeeds 
against httpd and nginx on current [with the server side enforcing 
secp384r1].

Re: specify curves via ecdhe statement in httpd.conf

[Andreas Bartelt]

On 02/05/17 07:41, Joel Sing wrote:

On Saturday 04 February 2017 15:51:02 Andreas Bartelt wrote:

On 02/04/17 05:26, Joel Sing wrote:

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?


Tested with a build of today's current:
- httpd started with ecdhe "auto" in /etc/httpd.conf
- then trying to connect via openssl s_client with -groups P-384 option
doesn't negotiate a cipher suite.

However, specifying -groups P-256 works. I don't know how to specify
x25519 with OpenBSD's openssl s_client (it's not yet listed in openssl
ecparam -list_curves output) but SSL Labs successfully negotiates via
x25519 and P-256 (but not P-384). P-384 doesn't seem to be enabled with
"auto".


You can just specify X25519 as a group - it will not appear in `openssl
ecparam -list_curves' since it is not a standard EC curve.



thanks - I didn't notice that capitalization is important here. Maybe 
x25519 and ecdh_x25519 [IANA] should also be accepted as valid names 
[http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml].


The definition of the curve itself is provided in RFC 7748 - RFCs for 
some other listed curves (e.g., brainpool) are also only tagged as 
Informational. What is missing with regard to X25519?



Another confusing test result:
- httpd started with ecdhe "secp384r1" (P-384)
- then trying to connect via openssl s_client with -groups P-384 option
also doesn't negotiate a cipher suite!

However, SSL Labs successfully connects to httpd and confirms support
for secp384r1.

Can you reproduce this?


No, it works correctly for me (OpenBSD -current, amd64).

With "tls ecdhe auto":

$ for group in X25519 P-256 P-384; do openssl s_client -connect localhost:443
-groups $group &1 | grep 'Server Temp Key:'; done
Server Temp Key: ECDH, X25519, 253 bits
Server Temp Key: ECDH, P-256, 256 bits
Server Temp Key: ECDH, P-384, 384 bits

With "tls ecdhe secp384r1":

 $ for group in X25519 P-256 P-384; do openssl s_client -connect localhost:443
-groups $group &1 | grep 'Server Temp Key:'; done
Server Temp Key: ECDH, P-384, 384 bits



This is really weird. Although my test results for X25519 were similarly 
confusing -- for simplicity, I'll provide some more results which were 
restricted to explicitly testing secp384r1.


TLS config of httpd has been stripped down for simplicity:
 tls {
key "/etc/ssl/private/server.key"
certificate "/etc/ssl/server.crt"
ecdhe "secp384r1"
}

Server side:
one the same amd64 -current box with the same certs:
- httpd with ecdhe "secp384r1"
- nginx with ssl_ecdh_curve secp384r1;
external site:
- www.openbsd.org

Client side (on amd64 -current):
- openssl s_client -connect :443 -servername  
-groups secp384r1
- eopenssl s_client -connect :443 -servername  
-curves secp384r1

- nc -vvv -c  443

The following combinations were tested:
server httpd with ecdhe "secp384r1" & server nginx with ssl_ecdh_curve 
secp384r1; (identical results)

connect via openssl [secp384r1]: fails
connect via eopenssl [secp384r1]: fails
connect via nc: succeeds
connect via SSL Labs: succeeds
connect via firefox: succeeds
LibreSSL 2.4.2 based client from OpenBSD current ~06/2016 on some older 
test laptop:

connect via openssl [-groups was not yet available]: succeeds
then installed OpenSSL 1.0.2h from ports:
connect via eopenssl [without -curves option]: succeeds!
connect via eopenssl [with -curves secp384r1]: fails!

connect to www.openbsd.org:443
connect via openssl [secp384r1]: succeeds
connect via eopenssl [secp384r1]: succeeds
connect via nc: succeeds

I can't make any sense out of this.

Error messages when failing against httpd:
> openssl s_client -connect :443 -servername  
-groups secp384r1

CONNECTED(0003)
1225438578:error:14FFF410:SSL routines:SSL_internal:sslv3 alert 
handshake failure:/usr/src/lib/libssl/ssl_pkt.c:1205:SSL alert number 40
1225438578:error:14FFF0E5:SSL routines:SSL_internal:ssl handshake 
failure:/usr/src/lib/libssl/ssl_pkt.c:585:

---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol  : TLSv1.2
Cipher: 
Session-ID:
Session-ID-ctx:
Master-Key:
Start Time: 1486

Re: specify curves via ecdhe statement in httpd.conf

[Andreas Bartelt]

On 02/04/17 17:15, Bob Beck wrote:

try connecting with openbsd nc rather than s-client



with ecdhe "auto" as well as ecdhe "secp384r1" in /etc/httpd.conf, I can 
successfully negotiate a TLS cipher suite via nc -vvv -c  443


However, nc doesn't give any output with regard to the negotiated curve 
for ecdhe.



On Sat, Feb 4, 2017 at 09:13 Bob Beck <b...@obtuse.com> wrote:



On Sat, Feb 4, 2017 at 07:51 Andreas Bartelt <o...@bartula.de> wrote:

On 02/04/17 05:26, Joel Sing wrote:

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?



Tested with a build of today's current:
- httpd started with ecdhe "auto" in /etc/httpd.conf
- then trying to connect via openssl s_client with -groups P-384 option
doesn't negotiate a cipher suite.

However, specifying -groups P-256 works. I don't know how to specify
x25519 with OpenBSD's openssl s_client (it's not yet listed in openssl
ecparam -list_curves output) but SSL Labs successfully negotiates via
x25519 and P-256 (but not P-384). P-384 doesn't seem to be enabled with
"auto".

Another confusing test result:
- httpd started with ecdhe "secp384r1" (P-384)
- then trying to connect via openssl s_client with -groups P-384 option
also doesn't negotiate a cipher suite!

However, SSL Labs successfully connects to httpd and confirms support
for secp384r1.

Can you reproduce this?


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: specify curves via ecdhe statement in httpd.conf

[Andreas Bartelt]

On 02/04/17 05:26, Joel Sing wrote:

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?



Tested with a build of today's current:
- httpd started with ecdhe "auto" in /etc/httpd.conf
- then trying to connect via openssl s_client with -groups P-384 option 
doesn't negotiate a cipher suite.


However, specifying -groups P-256 works. I don't know how to specify 
x25519 with OpenBSD's openssl s_client (it's not yet listed in openssl 
ecparam -list_curves output) but SSL Labs successfully negotiates via 
x25519 and P-256 (but not P-384). P-384 doesn't seem to be enabled with 
"auto".


Another confusing test result:
- httpd started with ecdhe "secp384r1" (P-384)
- then trying to connect via openssl s_client with -groups P-384 option 
also doesn't negotiate a cipher suite!


However, SSL Labs successfully connects to httpd and confirms support 
for secp384r1.


Can you reproduce this?


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.

specify curves via ecdhe statement in httpd.conf

[Andreas Bartelt]

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.


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). Diff is attached which clarifies the meaning of "auto" in 
httpd.conf.5.


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)?


Best Regards
Andreas
Index: httpd.conf.5
===
RCS file: /cvs/src/usr.sbin/httpd/httpd.conf.5,v
retrieving revision 1.78
diff -u -p -u -r1.78 httpd.conf.5
--- httpd.conf.5	24 Jan 2017 13:28:47 -	1.78
+++ httpd.conf.5	1 Feb 2017 14:18:45 -
@@ -527,7 +527,7 @@ The default is none, which disables DHE 
 .It Ic ecdhe Ar curve
 Specify the ECDHE curve to use for ECDHE cipher suites.
 Valid parameter values are none, auto and the short name of any known curve.
-The default is auto.
+The default is auto which enables curves X25519 and P-256.
 .It Ic key Ar file
 Specify the private key to use for this server.
 The

Re: Problems with rdomain and net/if.c v1.455

[Andreas Bartelt]

On 11/10/16 20:36, Andreas Bartelt wrote:

On 11/09/16 11:55, Martin Pieuchot wrote:
...

I'm going to commit this fixed diff unless somebody has something to add.



I've tested this - it works for me.



Sorry, I probably was too fast - I've observed a problem with smtpd in 
rdomain 0 (which exits) after upgrading to current with your patch.

Re: Problems with rdomain and net/if.c v1.455

[Andreas Bartelt]

On 11/09/16 11:55, Martin Pieuchot wrote:
...

I'm going to commit this fixed diff unless somebody has something to add.



I've tested this - it works for me.

Best regards
Andreas

Re: Problems with rdomain and net/if.c v1.455

[Andreas Bartelt]

On 11/09/16 16:43, Martin Pieuchot wrote:

On 09/11/16(Wed) 16:29, Andreas Bartelt wrote:

On 11/09/16 15:11, Martin Pieuchot wrote:
...

Fair point.  What about adding backward compatible goo to help people
doing the transition:

# ifconfig lo1 create
# ifconfig vether0 rdomain 1
warning: lo1 cannot be used for rdomain 1
# ifconfig lo
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 32768
index 8 priority 0 llprio 3
groups: lo
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x8
inet 127.0.0.1 netmask 0xff00
lo1: flags=8008<LOOPBACK,MULTICAST> mtu 32768
index 13 priority 0 llprio 3
groups: lo
lo101: flags=8008<LOOPBACK,MULTICAST> rdomain 1 mtu 32768
index 14 priority 0 llprio 3
groups: lo



Would this mean that a /etc/hostname.lo1 which configures an IP address for
lo1 in rdomain 1 would actually result in configuration of lo101 (in rdomain
1) instead? I would find this quite confusing.


In your case you can simply /etc/hostname.lo1 you won't need it.



I'm actually not using 127.0.0.1 as IP address on lo1 in my specific 
setup -- I'm using the same LAN-visible IP address which unbound listens 
on in rdomain 0 (due to the nameserver IP entries in /etc/resolv.conf 
which, by design, are used for all rdomains). Because of this, I suppose 
I would then still need to explicitly configure this IP alias for lo1 in 
rdomain 1 (i.e., via /etc/hostname.lo1). Alternatively, would it make 
sense to explicitly create a second lo(4) interface for rdomain 1 with 
this IP address?



I personally never had any problems with explicit configuration of lo(4)
interfaces for rdomains until somewhere after October 9th - this was the
time when the actual behaviour of my previous configuration changed. What I
don't understand -- why is there a need for changing the way of explicitly
configuring lo(4) interfaces (beyond lo0) for rdomains?


Because every rdomain is currently using lo0 which is wrong.



thx, this explains why my pf rules for lo0 were previously also 
effectively applied to lo1.

Re: Problems with rdomain and net/if.c v1.455

[Andreas Bartelt]

On 11/09/16 15:11, Martin Pieuchot wrote:
...

Fair point.  What about adding backward compatible goo to help people
doing the transition:

# ifconfig lo1 create
# ifconfig vether0 rdomain 1
warning: lo1 cannot be used for rdomain 1
# ifconfig lo
lo0: flags=8049 mtu 32768
index 8 priority 0 llprio 3
groups: lo
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x8
inet 127.0.0.1 netmask 0xff00
lo1: flags=8008 mtu 32768
index 13 priority 0 llprio 3
groups: lo
lo101: flags=8008 rdomain 1 mtu 32768
index 14 priority 0 llprio 3
groups: lo



Would this mean that a /etc/hostname.lo1 which configures an IP address 
for lo1 in rdomain 1 would actually result in configuration of lo101 (in 
rdomain 1) instead? I would find this quite confusing.


I personally never had any problems with explicit configuration of lo(4) 
interfaces for rdomains until somewhere after October 9th - this was the 
time when the actual behaviour of my previous configuration changed. 
What I don't understand -- why is there a need for changing the way of 
explicitly configuring lo(4) interfaces (beyond lo0) for rdomains?


Best regards
Andreas

Re: Default softraid crypto PBKDF2 rounds

[Andreas Bartelt]

On 09/07/16 09:16, Damien Miller wrote:

On Tue, 6 Sep 2016, David Coppa wrote:


Il 6 settembre 2016 14:56:32 CEST, Filippo Valsorda  ha 
scritto:

Hello,

I recently had the occasion to dive into the softraid crypto code [1]
and was quite pleased with the cleanliness of it all. However, I found
surprising the default value of 8k PBKDF2 rounds.

I know it is easy to override and I should have RTFM, but I (naively,
I'll admit) assumed OpenBSD would pick very robust defaults, erring on
the conservative side. Is it maybe time to bump it up, or pick it based
on a quick machine benchmark?

If there's consensus I might also provide a patch for the live
benchmark
option.


yes, autodetection of a sensible value would be cool...


using bcrypt_kdf would be better :)




yes, due to the larger internal state of the blowfish algorithm which is 
harder to efficiently realize in dedicated hardware. However, since 
bcrypt's internal state effectively is of fixed size, scrypt would be an 
even better option since it allows for a parameterization of this 
internal state. Is there any interest in switching to scrypt in the 
context of password authentication on OpenBSD?

Re: add option for disabling TLS session tickets to libttls

[Andreas Bartelt]

On 08/22/16 08:17, Claudio Jeker wrote:

On Sun, Aug 21, 2016 at 02:25:15PM -0400, Ted Unangst wrote:

Andreas Bartelt wrote:

Since the use of TLS session tickets potentially interferes with forward
secrecy on a per-session basis, I'd personally prefer an opt-in in
libtls as well as in httpd with regard to its usage. However, such a
semantic change would not be transparent. Any opinions on this?


Defaulting to off makes sense to me. It's the marginally safer option and at
small scale probably not a performance concern. But if the default results in
900 "tutorials" telling people to turn it back on because web scale, then all
we've done is make things difficult.



While I agree it is important to turn them on for HTTP servers or any
other protocol that does a lot of reconnects. This should also include
the magic to make them work accross multiple processes (see my relayd diff
for that -- which uses the libssl callback madness though).
Without tickets the full TLS handshake will be made for every reconnect
which is a common mode of operation for HTTP. Also I think tickets are a
bit saver than the session cache (which AFAIK is also default on for
servers) and probably the fallback mode.
Client side tickets should be enabled since they are just pass along to
the next connect without processing them.



here's another diff which also adds enable/disable functions with regard 
to TLS session resumption. Although this mechanism is technically not a 
TLS extension, it is also optional and basically provides the same 
functionality as the TLS session ticket extension.


This diff is transparent to the current behaviour of libtls, i.e., it 
enables session tickets as well as session resumption by default. As I 
already said, I personally don't like the current default. In 
particular, I don't like the lack of key management for TLS tickets 
which always has to be done manually (see Claudio's relayd patch on 
tech@). If things go wrong, the corresponding damage might be pretty 
high on long-running TLS servers.


I suppose further API functions should be added for explicitly 
configuring session resumption and session ticket parameters.


During testing, I've also noticed that the session resumption mechanism 
currently doesn't work reliably. It always seems to fail at the first 
session resumption attempt, and it works with unpredictable reliability 
afterwards. I didn't look at the corresponding code in libssl yet.


OK?
Index: src/lib/libtls/tls.h
===
RCS file: /cvs/src/lib/libtls/tls.h,v
retrieving revision 1.35
diff -u -p -u -r1.35 tls.h
--- src/lib/libtls/tls.h	22 Aug 2016 14:58:26 -	1.35
+++ src/lib/libtls/tls.h	28 Aug 2016 10:35:31 -
@@ -41,6 +41,10 @@ extern "C" {
 #define TLS_WANT_POLLIN		-2
 #define TLS_WANT_POLLOUT	-3
 
+/* TLS extensions and other optional mechanisms */
+#define TLS_SESSION_RESUMPTION		0x0001L
+#define TLS_SESSION_TICKETS		0x0002L
+
 struct tls;
 struct tls_config;
 
@@ -78,6 +82,12 @@ int tls_config_set_keypair_mem(struct tl
 size_t _cert_len, const uint8_t *_key, size_t _key_len);
 void tls_config_set_protocols(struct tls_config *_config, uint32_t _protocols);
 void tls_config_set_verify_depth(struct tls_config *_config, int _verify_depth);
+
+void tls_config_enable_session_resumption(struct tls_config *_config);
+void tls_config_enable_session_tickets(struct tls_config *_config);
+
+void tls_config_disable_session_resumption(struct tls_config *_config);
+void tls_config_disable_session_tickets(struct tls_config *_config);
 
 void tls_config_prefer_ciphers_client(struct tls_config *_config);
 void tls_config_prefer_ciphers_server(struct tls_config *_config);
Index: src/lib/libtls/tls_config.c
===
RCS file: /cvs/src/lib/libtls/tls_config.c,v
retrieving revision 1.28
diff -u -p -u -r1.28 tls_config.c
--- src/lib/libtls/tls_config.c	22 Aug 2016 14:55:59 -	1.28
+++ src/lib/libtls/tls_config.c	28 Aug 2016 10:35:32 -
@@ -193,6 +193,9 @@ tls_config_new(void)
 	tls_config_set_protocols(config, TLS_PROTOCOLS_DEFAULT);
 	tls_config_set_verify_depth(config, 6);
 
+	tls_config_enable_session_resumption(config);
+	tls_config_enable_session_tickets(config);
+
 	tls_config_prefer_ciphers_server(config);
 
 	tls_config_verify(config);
@@ -580,6 +583,30 @@ void
 tls_config_set_verify_depth(struct tls_config *config, int verify_depth)
 {
 	config->verify_depth = verify_depth;
+}
+
+void
+tls_config_enable_session_resumption(struct tls_config *config)
+{
+	config->tls_extensions |= TLS_SESSION_RESUMPTION;
+}
+
+void
+tls_config_enable_session_tickets(struct tls_config *config)
+{
+	config->tls_extensions |= TLS_SESSION_TICKETS;
+}
+
+void
+tls_config_disable_session_resumption(struct tls_config *config)
+{
+	config->tls_extensions &= ~TLS_SESSION_RESUMPTION;
+}
+
+void
+tls_config_disable_session_tickets(st

Re: Enable Camellia ciphers with SHA-2 family HMAC

[Andreas Bartelt]

On 08/25/16 15:58, Brent Cook wrote:

No objection here. Anyone else?



in general, I personally would only add further cryptographic primitives 
to a TLS configuration in case they provide sufficiently distinctive 
advantages over the already available primitives. I don't see this for 
Camellia since it doesn't seem to provide any better trade-offs than 
AES. Or am I missing something here?

add option for disabling TLS session tickets to libttls

[Andreas Bartelt]

Hello,

LibreSSL enables the use of the TLS session ticket extension [RFC 5077, 
or, according to comments in source code its older version 4507] by 
default, and libtls currently doesn't provide an API call for disabling 
this feature.


Consequently, OpenBSD's httpd has TLS session tickets enabled by default 
and doesn't provide an option to turn this TLS extension off. Moreover, 
there's currently no way to provide a specific policy with regard to the 
use of TLS session tickets (e.g., lifetime of the corresponding secret 
key which is used for encrypting all session tickets, the encryption 
scheme for session tickets etc).


Since the use of TLS session tickets potentially interferes with forward 
secrecy on a per-session basis, I'd personally prefer an opt-in in 
libtls as well as in httpd with regard to its usage. However, such a 
semantic change would not be transparent. Any opinions on this?


As kind of a first step, the attached diff adds an function to libtls 
which allows to (optionally) disable the use of tls session tickets.


Best regards
Andreas
Index: src/lib/libtls/tls.h
===
RCS file: /cvs/src/lib/libtls/tls.h,v
retrieving revision 1.33
diff -u -p -u -r1.33 tls.h
--- src/lib/libtls/tls.h	12 Aug 2016 15:10:59 -	1.33
+++ src/lib/libtls/tls.h	21 Aug 2016 15:08:32 -
@@ -41,6 +41,9 @@ extern "C" {
 #define TLS_WANT_POLLIN		-2
 #define TLS_WANT_POLLOUT	-3
 
+#define TLS_SESSION_TICKETS_DISABLE	0
+#define TLS_SESSION_TICKETS_ENABLE	1
+
 struct tls;
 struct tls_config;
 
@@ -73,6 +76,8 @@ int tls_config_set_keypair_mem(struct tl
 size_t _cert_len, const uint8_t *_key, size_t _key_len);
 void tls_config_set_protocols(struct tls_config *_config, uint32_t _protocols);
 void tls_config_set_verify_depth(struct tls_config *_config, int _verify_depth);
+
+void tls_config_disable_session_tickets(struct tls_config *_config);
 
 void tls_config_prefer_ciphers_client(struct tls_config *_config);
 void tls_config_prefer_ciphers_server(struct tls_config *_config);
Index: src/lib/libtls/tls_config.c
===
RCS file: /cvs/src/lib/libtls/tls_config.c,v
retrieving revision 1.27
diff -u -p -u -r1.27 tls_config.c
--- src/lib/libtls/tls_config.c	13 Aug 2016 13:15:53 -	1.27
+++ src/lib/libtls/tls_config.c	21 Aug 2016 15:08:32 -
@@ -193,6 +193,8 @@ tls_config_new(void)
 	tls_config_set_protocols(config, TLS_PROTOCOLS_DEFAULT);
 	tls_config_set_verify_depth(config, 6);
 
+	config->session_tickets = TLS_SESSION_TICKETS_ENABLE;
+
 	tls_config_prefer_ciphers_server(config);
 
 	tls_config_verify(config);
@@ -524,6 +526,12 @@ void
 tls_config_set_verify_depth(struct tls_config *config, int verify_depth)
 {
 	config->verify_depth = verify_depth;
+}
+
+void
+tls_config_disable_session_tickets(struct tls_config *config)
+{
+	config->session_tickets = TLS_SESSION_TICKETS_DISABLE;
 }
 
 void
Index: src/lib/libtls/tls_init.3
===
RCS file: /cvs/src/lib/libtls/tls_init.3,v
retrieving revision 1.66
diff -u -p -u -r1.66 tls_init.3
--- src/lib/libtls/tls_init.3	18 Aug 2016 15:43:12 -	1.66
+++ src/lib/libtls/tls_init.3	21 Aug 2016 15:08:32 -
@@ -39,6 +39,7 @@
 .Nm tls_config_set_keypair_mem ,
 .Nm tls_config_set_protocols ,
 .Nm tls_config_set_verify_depth ,
+.Nm tls_config_disable_session_tickets ,
 .Nm tls_config_prefer_ciphers_client ,
 .Nm tls_config_prefer_ciphers_server ,
 .Nm tls_config_clear_keys ,
@@ -119,6 +120,8 @@
 .Fn tls_config_set_protocols "struct tls_config *config" "uint32_t protocols"
 .Ft "void"
 .Fn tls_config_set_verify_depth "struct tls_config *config" "int verify_depth"
+.Ft "void"
+.Fn tls_config_disable_session_tickets "struct tls_config *config"
 .Ft "void"
 .Fn tls_config_prefer_ciphers_client "struct tls_config *config"
 .Ft "void"
Index: src/lib/libtls/tls_internal.h
===
RCS file: /cvs/src/lib/libtls/tls_internal.h,v
retrieving revision 1.39
diff -u -p -u -r1.39 tls_internal.h
--- src/lib/libtls/tls_internal.h	15 Aug 2016 15:44:58 -	1.39
+++ src/lib/libtls/tls_internal.h	21 Aug 2016 15:08:32 -
@@ -64,6 +64,7 @@ struct tls_config {
 	int ecdhecurve;
 	struct tls_keypair *keypair;
 	uint32_t protocols;
+	int session_tickets;
 	int verify_cert;
 	int verify_client;
 	int verify_depth;
Index: src/lib/libtls/tls_server.c
===
RCS file: /cvs/src/lib/libtls/tls_server.c,v
retrieving revision 1.24
diff -u -p -u -r1.24 tls_server.c
--- src/lib/libtls/tls_server.c	18 Aug 2016 15:52:03 -	1.24
+++ src/lib/libtls/tls_server.c	21 Aug 2016 15:08:32 -
@@ -113,6 +113,9 @@ tls_configure_server_ssl(struct tls *ctx
 	if (ctx->config->ciphers_server == 1)
 		SSL_CTX_set_options(*ssl_ctx, SSL_OP_CIPHER_SERVER_PREFERENCE);
 
+	if (ctx->config->session_tickets == 

starttls support for nc(1)

[Andreas Bartelt]

Hello,

I've written some code which basically allows to emulate the behavior of 
starttls-enabled clients and servers via nc(1). I mainly use it for 
debugging purposes since it is more generic than openssl s_client 
-starttls. However, the solution is probably ugly since I'm not very 
proficient in writing code.


Best regards
Andreas
Index: netcat.c
===
RCS file: /cvs/src/usr.bin/nc/netcat.c,v
retrieving revision 1.150
diff -u -p -u -r1.150 netcat.c
--- netcat.c	4 Jan 2016 02:18:31 -	1.150
+++ netcat.c	4 Jan 2016 15:41:10 -
@@ -71,6 +71,7 @@
 #define TLS_NOVERIFY	(1 << 2)
 #define TLS_NONAME	(1 << 3)
 #define TLS_CCERT	(1 << 4)
+#define TLS_STARTTLS	(1 << 5)
 
 /* Command Line Options */
 int	dflag;	/* detached, no stdin */
@@ -95,6 +96,7 @@ int	Oflag;	/* TCP send buffer size *
 int	Sflag;	/* TCP MD5 signature option */
 int	Tflag = -1;/* IP Type of Service */
 int	rtableid = -1;
+char	*host;
 
 int	usetls;	/* use TLS */
 char*Cflag;	/* Public cert file */
@@ -110,12 +112,15 @@ uint8_t *privkey;
 size_t  privkeylen;
 uint8_t *pubcert;
 size_t  pubcertlen;
+struct	tls_config *tls_cfg;
 
 int timeout = -1;
 int family = AF_UNSPEC;
 char *portlist[PORT_MAX+1];
 char *unix_dg_tmp_socket;
 
+volatile sig_atomic_t seenint;			/* set when we receive SIGINT */
+
 void	atelnet(int, unsigned char *, unsigned int);
 void	build_ports(char *);
 void	help(void);
@@ -140,12 +145,13 @@ ssize_t drainbuf(int, unsigned char *, s
 ssize_t fillbuf(int, unsigned char *, size_t *, struct tls *);
 void	tls_setup_client(struct tls *, int, char *);
 struct tls *tls_setup_server(struct tls *, int, char *);
+void	onsigint(int);
 
 int
 main(int argc, char *argv[])
 {
 	int ch, s, ret, socksv;
-	char *host, *uport;
+	char *uport;
 	struct addrinfo hints;
 	struct servent *sv;
 	socklen_t len;
@@ -154,9 +160,10 @@ main(int argc, char *argv[])
 	const char *errstr, *proxyhost = "", *proxyport = NULL;
 	struct addrinfo proxyhints;
 	char unix_dg_tmp_socket_buf[UNIX_DG_TMP_SOCKET_SIZE];
-	struct tls_config *tls_cfg = NULL;
 	struct tls *tls_ctx = NULL;
 
+	seenint = 0;		
+	tls_cfg = NULL;
 	ret = 1;
 	s = 0;
 	socksv = 5;
@@ -474,7 +481,7 @@ main(int argc, char *argv[])
 s = unix_listen(host);
 		}
 
-		if (usetls) {
+		if (usetls && !(TLSopt & TLS_STARTTLS)) {
 			tls_config_verify_client_optional(tls_cfg);
 			if ((tls_ctx = tls_server()) == NULL)
 errx(1, "tls server creation failed");
@@ -529,10 +536,16 @@ main(int argc, char *argv[])
 }
 if (vflag)
 	report_connect((struct sockaddr *), len);
-if ((usetls) &&
-(tls_cctx = tls_setup_server(tls_ctx, connfd, host)))
-	readwrite(connfd, tls_cctx);
-if (!usetls)
+if (usetls) {
+	if (TLSopt & TLS_STARTTLS) {
+		/* install SIGINT handler which is
+		   the delayed trigger for TLS */
+		(void)signal(SIGINT, onsigint);
+		readwrite(connfd, tls_ctx);
+	}
+	else if (tls_cctx = tls_setup_server(tls_ctx, connfd, host))
+		readwrite(connfd, tls_cctx);
+} else
 	readwrite(connfd, NULL);
 if (tls_cctx) {
 	int i;
@@ -580,7 +593,7 @@ main(int argc, char *argv[])
 			if (s)
 close(s);
 
-			if (usetls) {
+			if (usetls && !(TLSopt & TLS_STARTTLS)) {
 if ((tls_ctx = tls_client()) == NULL)
 	errx(1, "tls client creation failed");
 if (tls_configure(tls_ctx, tls_cfg) == -1)
@@ -625,8 +638,14 @@ main(int argc, char *argv[])
 			if (Fflag)
 fdpass(s);
 			else {
-if (usetls)
-	tls_setup_client(tls_ctx, s, host);
+if (usetls) {
+	if (TLSopt & TLS_STARTTLS)
+		/* install SIGINT handler which is
+		   the delayed trigger for TLS */
+		(void)signal(SIGINT, onsigint);
+	else
+		tls_setup_client(tls_ctx, s, host);
+}
 if (!zflag)
 	readwrite(s, tls_ctx);
 if (tls_ctx) {
@@ -1003,6 +1022,37 @@ readwrite(int net_fd, struct tls *tls_ct
 		/* poll */
 		num_fds = poll(pfd, 4, timeout);
 
+		/* received SIGINT triggers TLS handshake */
+		if (seenint) {
+			/* restore default SIGINT handler */
+			(void)signal(SIGINT, SIG_DFL);
+
+			if (tls_ctx != NULL)
+continue;
+
+			if (lflag) {
+tls_config_verify_client_optional(tls_cfg);
+if ((tls_ctx = tls_server()) == NULL)
+	errx(1, "tls server creation failed");
+if (tls_configure(tls_ctx, tls_cfg) == -1)
+	errx(1, "tls configuration failed (%s)",
+	tls_error(tls_ctx));
+if (!(tls_ctx = tls_setup_server(tls_ctx, net_fd,
+	host)))
+	return;
+			} else {
+if ((tls_ctx = tls_client()) == NULL)
+	errx(1, "tls client creation failed");
+if (tls_configure(tls_ctx, tls_cfg) == -1)
+	errx(1, "tls configuration failed (%s)",
+	tls_error(tls_ctx));
+tls_setup_client(tls_ctx, net_fd, host);
+			}
+
+			seenint = 0;
+			continue;
+		}
+
 		/* treat poll errors */
 		if (num_fds == -1) {
 			close(net_fd);
@@ -1451,6 +1501,7 @@ map_tls(char *s, int 

nc(1) - fix use of certificates for TLS

[Andreas Bartelt]

Hello,

the use of certificates for TLS didn't work with nc(1). Fix is attached.

Best regards
Andreas
Index: netcat.c
===
RCS file: /cvs/src/usr.bin/nc/netcat.c,v
retrieving revision 1.149
diff -u -p -u -r1.149 netcat.c
--- netcat.c	28 Dec 2015 14:17:47 -	1.149
+++ netcat.c	4 Jan 2016 00:52:22 -
@@ -429,9 +429,9 @@ main(int argc, char *argv[])
 	if (usetls) {
 		if (Rflag && (cacert=tls_load_file(Rflag, , NULL)) == NULL)
 			errx(1, "unable to load root CA file %s", Rflag);
-		if (Cflag && (pubcert=tls_load_file(Rflag, , NULL)) == NULL)
+		if (Cflag && (pubcert=tls_load_file(Cflag, , NULL)) == NULL)
 			errx(1, "unable to load TLS certificate file %s", Cflag);
-		if (Kflag && (privkey=tls_load_file(Rflag, , NULL)) == NULL)
+		if (Kflag && (privkey=tls_load_file(Kflag, , NULL)) == NULL)
 			errx(1, "unable to load TLS key file %s", Kflag);
 
 		if (pledge("stdio inet dns", NULL) == -1)
@@ -443,7 +443,7 @@ main(int argc, char *argv[])
 			errx(1, "unable to allocate TLS config");
 		if (Rflag && tls_config_set_ca_mem(tls_cfg, cacert, cacertlen) == -1)
 			errx(1, "unable to set root CA file %s", Rflag);
-		if (Cflag && tls_config_set_cert_mem(tls_cfg, cacert, cacertlen) == -1)
+		if (Cflag && tls_config_set_cert_mem(tls_cfg, pubcert, pubcertlen) == -1)
 			errx(1, "unable to set TLS certificate file %s", Cflag);
 		if (Kflag && tls_config_set_key_mem(tls_cfg, privkey, privkeylen) == -1)
 			errx(1, "unable to set TLS key file %s", Kflag);

revision 1.201 of sys/conf/GENERIC (enable mpath, rdac and sym) breaks suspend on Thinkpad X200s

[Andreas Bartelt]

Hi,

with this patch enabled on a Thinkpad X200s, the system doesn't wake up 
anymore after being suspended via apm -z. This problem is reproducible.


dmesg before and after this patch is attached to this mail.

Best Regards
Andreas

OpenBSD 5.4-current (GENERIC.MP) #0: Mon Sep 30 22:21:24 CEST 2013
a...@obsd.bartula.de:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4166717440 (3973MB)
avail mem = 4047679488 (3860MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (68 entries)
bios0: vendor LENOVO version 6DET72WW (3.22 ) date 10/25/2012
bios0: LENOVO 746988G
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET SLIC BOOT ASF! SSDT TCPA DMAR 
SSDT SSDT SSDT
acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP0(S4) EXP1(S4) EXP2(S4) 
EXP3(S4) USB0(S3) USB3(S3) USB5(S3) EHC0(S3) EHC1(S3) HDEF(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM)2 Duo CPU L9600 @ 2.13GHz, 2128.28 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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF
cpu0: 6MB 64b/line 16-way L2 cache
cpu0: smt 0, core 0, package 0
cpu0: apic clock running at 266MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM)2 Duo CPU L9600 @ 2.13GHz, 2128.01 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,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF
cpu1: 6MB 64b/line 16-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 2, remapped to apid 1
acpimcfg0 at acpi0 addr 0xe000, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (AGP_)
acpiprt2 at acpi0: bus 2 (EXP0)
acpiprt3 at acpi0: bus 3 (EXP1)
acpiprt4 at acpi0: bus -1 (EXP2)
acpiprt5 at acpi0: bus -1 (EXP3)
acpicpu0 at acpi0: C3, C2, C1, PSS
acpicpu1 at acpi0: C3, C2, C1, PSS
acpipwrres0 at acpi0: PUBS
acpitz0 at acpi0: critical temperature is 127 degC
acpitz1 at acpi0: critical temperature is 104 degC
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
acpibat0 at acpi0: BAT0 model 42T4650 serial   355 type LION oem Panasonic
acpibat1 at acpi0: BAT1 not present
acpiac0 at acpi0: AC unit offline
acpithinkpad0 at acpi0
acpidock0 at acpi0: GDCK not docked (0)
cpu0: Enhanced SpeedStep 2128 MHz: speeds: 2134, 2133, 1600, 800 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 Intel GM45 Host rev 0x07
vga1 at pci0 dev 2 function 0 Intel GM45 Video rev 0x07
intagp0 at vga1
agp0 at intagp0: aperture at 0xd000, size 0x1000
inteldrm0 at vga1
drm0 at inteldrm0
inteldrm0: 1440x900
wsdisplay0 at vga1 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
Intel GM45 Video rev 0x07 at pci0 dev 2 function 1 not configured
Intel GM45 HECI rev 0x07 at pci0 dev 3 function 0 not configured
em0 at pci0 dev 25 function 0 Intel ICH9 IGP M AMT rev 0x03: msi, address 
00:1f:16:1c:a3:34
uhci0 at pci0 dev 26 function 0 Intel 82801I USB rev 0x03: apic 1 int 20
uhci1 at pci0 dev 26 function 1 Intel 82801I USB rev 0x03: apic 1 int 21
uhci2 at pci0 dev 26 function 2 Intel 82801I USB rev 0x03: apic 1 int 22
ehci0 at pci0 dev 26 function 7 Intel 82801I USB rev 0x03: apic 1 int 23
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 82801I HD Audio rev 0x03: msi
azalia0: codecs: Conexant CX20561
audio0 at azalia0
ppb0 at pci0 dev 28 function 0 Intel 82801I PCIE rev 0x03: msi
pci1 at ppb0 bus 2
ppb1 at pci0 dev 28 function 1 Intel 82801I PCIE rev 0x03: msi
pci2 at ppb1 bus 3
iwn0 at pci2 dev 0 function 0 Intel WiFi Link 5300 rev 0x00: msi, MIMO 3T3R, 
MoW, address 00:21:6a:4f:9c:2a
uhci3 at pci0 dev 29 function 0 Intel 82801I USB rev 0x03: apic 1 int 16
uhci4 at pci0 dev 29 function 1 Intel 82801I USB rev 0x03: apic 1 int 17
uhci5 at pci0 dev 29 function 2 Intel 82801I USB rev 0x03: apic 1 int 18
ehci1 at pci0 dev 29 function 7 Intel 82801I USB rev 0x03: apic 1 int 19
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 Intel EHCI root hub rev 2.00/1.00 addr 1
ppb2 at pci0 dev 30 function 0 Intel 82801BAM Hub-to-PCI rev 0x93
pci3 at ppb2 bus 13
pcib0 at pci0 dev 31 function 0 Intel 82801IEM LPC rev 0x03
ahci0 at pci0 dev 31 function 2 Intel 82801I AHCI rev 0x03: msi, AHCI 1.2
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 0 lun 0: ATA, INTEL SSDSA2CW12, 4PC1 SCSI3 0/direct 
fixed naa.5001517bb27a077b
sd0: 114473MB, 512 bytes/sector, 234441648 sectors, thin
ichiic0 at pci0 dev 31 function 3 Intel 82801I SMBus rev 0x03: apic 1 

jumbos for bnx(4) (again)

[Andreas Bartelt]

Hello,

last year, a patch regarding bnx(4) jumbos was provided and refined by 
dlg@, kettenis@ and brad@.


I've tested the diff for if_bnx.c against current and setting MTUs  
1500 works in principle.


However, with this diff enabled on current, there's quickly 
deteriorating packet loss regardless of packet size (i.e. when pinging a 
directly connected host) and the interface quickly becomes unusable.


Are these problems probably related to BCM5709 (I think Brad tested with 
BCM5708) or are there general problems with this patch?


# dmesg|grep -i bcm
bnx0 at pci7 dev 0 function 0 Broadcom BCM5709 rev 0x20: apic 0 int 6
bnx1 at pci7 dev 0 function 1 Broadcom BCM5709 rev 0x20: apic 0 int 13
bnx2 at pci8 dev 0 function 0 Broadcom BCM5709 rev 0x20: apic 0 int 7
bnx3 at pci8 dev 0 function 1 Broadcom BCM5709 rev 0x20: apic 0 int 15
brgphy0 at bnx0 phy 1: BCM5709 10/100/1000baseT PHY, rev. 8
brgphy1 at bnx1 phy 1: BCM5709 10/100/1000baseT PHY, rev. 8
brgphy2 at bnx2 phy 1: BCM5709 10/100/1000baseT PHY, rev. 8
brgphy3 at bnx3 phy 1: BCM5709 10/100/1000baseT PHY, rev. 8

Best Regards
Andreas
Index: sys/dev/pci/if_bnx.c
===
RCS file: /cvs/src/sys/dev/pci/if_bnx.c,v
retrieving revision 1.100
diff -u -r1.100 if_bnx.c
--- sys/dev/pci/if_bnx.c13 Jan 2013 05:45:10 -  1.100
+++ sys/dev/pci/if_bnx.c2 Mar 2013 10:06:46 -
@@ -848,6 +848,8 @@
sc-bnx_rx_ticks   = 18;
 #endif
 
+   sc-mbuf_alloc_size = BNX_MAX_JUMBO_MRU;
+
/* Update statistics once every second. */
sc-bnx_stats_ticks = 100  0x00;
 
@@ -878,9 +880,10 @@
ifp-if_ioctl = bnx_ioctl;
ifp-if_start = bnx_start;
ifp-if_watchdog = bnx_watchdog;
+   ifp-if_hardmtu = BNX_MAX_JUMBO_MTU;
IFQ_SET_MAXLEN(ifp-if_snd, USABLE_TX_BD - 1);
IFQ_SET_READY(ifp-if_snd);
-   m_clsetwms(ifp, MCLBYTES, 2, USABLE_RX_BD);
+   m_clsetwms(ifp, sc-mbuf_alloc_size, 2, USABLE_RX_BD);
bcopy(sc-eaddr, sc-arpcom.ac_enaddr, ETHER_ADDR_LEN);
bcopy(sc-bnx_dev.dv_xname, ifp-if_xname, IFNAMSIZ);
 
@@ -894,8 +897,6 @@
ifp-if_capabilities |= IFCAP_VLAN_HWTAGGING;
 #endif
 
-   sc-mbuf_alloc_size = BNX_MAX_MRU;
-
printf(%s: address %s\n, sc-bnx_dev.dv_xname,
ether_sprintf(sc-arpcom.ac_enaddr));
 
@@ -2664,8 +2665,8 @@
 * Create DMA maps for the Rx buffer mbufs.
 */
for (i = 0; i  TOTAL_RX_BD; i++) {
-   if (bus_dmamap_create(sc-bnx_dmatag, BNX_MAX_MRU,
-   BNX_MAX_SEGMENTS, BNX_MAX_MRU, 0, BUS_DMA_NOWAIT,
+   if (bus_dmamap_create(sc-bnx_dmatag, sc-mbuf_alloc_size,
+   1, sc-mbuf_alloc_size, 0, BUS_DMA_NOWAIT,
sc-rx_mbuf_map[i])) {
printf(: Could not create Rx mbuf %d DMA map!\n, i);
rc = ENOMEM;
@@ -3680,10 +3681,10 @@
*prod_bseq);
 
/* This is a new mbuf allocation. */
-   m = MCLGETI(NULL, M_DONTWAIT, sc-arpcom.ac_if, MCLBYTES);
+   m = MCLGETI(NULL, M_DONTWAIT, sc-arpcom.ac_if, sc-mbuf_alloc_size);
if (!m)
return (ENOBUFS);
-   m-m_len = m-m_pkthdr.len = MCLBYTES;
+   m-m_len = m-m_pkthdr.len = sc-mbuf_alloc_size;
/* the chip aligns the ip header for us, no need to m_adj */
 
/* Map the mbuf cluster into device memory. */
@@ -4013,6 +4014,16 @@
REG_WR(sc, BNX_MQ_MAP_L2_5, val | BNX_MQ_MAP_L2_5_ARM);
}
 
+   CTX_WR(sc, GET_CID_ADDR(RX_CID), BNX_L2CTX_RX_PG_BUF_SIZE, 0);
+
+   /* Configure the rx_bd and page chain mbuf cluster size. */
+   val = (sc-mbuf_alloc_size  16);
+   CTX_WR(sc, GET_CID_ADDR(RX_CID), BNX_L2CTX_RX_PG_BUF_SIZE, val);
+
+   /* Configure the context reserved for jumbo support. */
+   CTX_WR(sc, GET_CID_ADDR(RX_CID), BNX_L2CTX_RX_RBDC_KEY,
+   BNX_L2CTX_RX_RBDC_JUMBO_KEY);
+
/* Point the hardware to the first page in the chain. */
val = (u_int32_t)((u_int64_t)sc-rx_bd_chain_paddr[0]  32);
CTX_WR(sc, GET_CID_ADDR(RX_CID), BNX_L2CTX_NX_BDHADDR_HI, val);
@@ -4787,7 +4798,7 @@
bnx_set_mac_addr(sc);
 
/* Calculate and program the Ethernet MRU size. */
-   ether_mtu = BNX_MAX_STD_ETHER_MTU_VLAN;
+   ether_mtu = BNX_MAX_JUMBO_ETHER_MTU_VLAN;
 
DBPRINT(sc, BNX_INFO, %s(): setting MRU = %d\n,
__FUNCTION__, ether_mtu);

Re: em(4): enable TCP/UDP checksum offload

[Andreas Bartelt]

looks good:

# dmesg |grep ^em
em0 at pci9 dev 0 function 0 Intel PRO/1000 PT (82571EB) rev 0x06: 
apic 0 int 8, address X:X:X:X:X:X
em1 at pci9 dev 0 function 1 Intel PRO/1000 PT (82571EB) rev 0x06: 
apic 0 int 18, address X:X:X:X:X:X


# ifconfig em hwfeatures
em0: flags=8b43UP,BROADCAST,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST 
mtu 1500

hwfeatures=36CSUM_TCPv4,CSUM_UDPv4,VLAN_MTU,VLAN_HWTAGGING
lladdr X:X:X:X:X:X
priority: 0
trunk: trunkdev trunk0
media: Ethernet autoselect (1000baseT full-duplex)
status: active
em1: flags=8b43UP,BROADCAST,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST 
mtu 1500

hwfeatures=36CSUM_TCPv4,CSUM_UDPv4,VLAN_MTU,VLAN_HWTAGGING
lladdr X:X:X:X:X:X
priority: 0
trunk: trunkdev trunk0
media: Ethernet autoselect (1000baseT full-duplex)
status: active

Re: em(4): enable TCP/UDP checksum offload

[Andreas Bartelt]

and these also look good:

 dmesg|grep ^em
em0 at pci3 dev 0 function 0 Intel PRO/1000 PT (82572EI) rev 0x06: 
apic 2 int 17, address X:X:X:X:X:X


 ifconfig em hwfeatures
em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
hwfeatures=36CSUM_TCPv4,CSUM_UDPv4,VLAN_MTU,VLAN_HWTAGGING
lladdr X:X:X:X:X:X
priority: 0
groups: egress
media: Ethernet autoselect (1000baseT full-duplex)
status: active

# dmesg|grep ^em
em0 at pci0 dev 25 function 0 Intel ICH8 IGP M AMT rev 0x03: msi, 
address X:X:X:X:X:X


# ifconfig em0 hwfeatures
em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
hwfeatures=36CSUM_TCPv4,CSUM_UDPv4,VLAN_MTU,VLAN_HWTAGGING
lladdr X:X:X:X:X:X
priority: 0
groups: egress
media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause)
status: active

I will keep the patch enabled on these interfaces and report if there 
should be any problems which I didn't notice yet.


Best Regards
Andreas

Re: Huawei E303

[Andreas Bartelt]

On 07/16/12 09:09, David Coppa wrote:
...


Please report back if you have (at least) a port responding to AT
commands: I'd like to commit your diff.



the stick seems to recognize the correct PIN, i.e., in case my SIM card 
PIN would be 1234, I would get the following output:


# cu -l cuaU0
Connected
AT+CPIN=1234
OK

[after disconnecting and reattaching the stick...]

Entering the wrong PIN, let's say 1235, gives an error:

# cu -l cuaU0
Connected
AT+CPIN=1235
+CME ERROR: 16

I also noticed after connecting to cuaU0, the following lines are added 
to dmesg:

umsm0: this device is not using CDC notify message in intr pipe.
Please send your dmesg to b...@openbsd.org, thanks.
umsm0: intr buffer 0xc1 0x1 0x3 0x0 0x0 0x0 0x0

So what does this mean -- is the stick working?

Should I test something more specific?

Best Regards
Andreas

Re: Huawei E303

[Andreas Bartelt]

On 07/16/12 14:54, Stuart Henderson wrote:

On 2012/07/15 19:00, Paul Irofti wrote:

On Sun, Jul 15, 2012 at 05:40:03PM +0200, David Coppa wrote:

Il giorno 15/lug/2012 16:56, Paul Irofti p...@irofti.net ha scritto:



Unfortunately, I have no clue where to go from there. I'd like to
connect to vodafone in Germany via UMTS, but I didn't find a
/etc/ppp/peers/ and a corresponding chat script configuration in the
archives which works for me.

Is anybody else using a similar setup?


I tried the same with Vodafone RO for quite a few months two years ago.
Bottom line is it doesn't work.

I had the same problems two years ago. Tried to make the config work
with Vodafone RO and failed miserably. I can firmly say that those were
two months that I lost in vain.

What I would recommand is to stop wasting time now and only use that
modem on Windows with the applications provided by Vodafone.



Why?

I've used the setup described below with Vodafone Italia without problems
for years:

http://marc.info/?l=openbsd-miscm=128816834527997w=2


That script didn't work for me. Couldn't authentificate.

Maybe it will work for Germany.



The PPP session is with the adapter, not the provider. You usually want
to disable anything clever as they rarely cope with this correctly.
It shouldn't make a difference which country if it's the same
adapter and firmware.

For a different huawei card I'm using this in /etc/ppp/peers/3g

debug
/dev/cuaU0
921600
0.0.0.0:10.99.1.2
defaultroute
noipdefault
user x
crtscts
persist
deflate 0
refuse-pap
refuse-chap
noauth
noipdefault
noccp
novj
novjccomp
nopcomp
connect '/usr/sbin/chat -v -f /etc/ppp/peers/3g.chat'

and this in /etc/ppp/peers/3g.chat

TIMEOUT 120
ABORT BUSY
ABORT ERROR
ABORT NO CARRIER
ABORT VOICE
ABORT NO DIALTONE
 ATZ
OK ATD*99#
CONNECT \c

and in /etc/ppp/chap-secrets (possibly unused)

# clientserver  secret  IP addresses
x   *   blah*

I already have the phone provider's APN programmed into context 1
so I can just use ATD*99# and skip the AT+CGDCONT line, or you can
set it yourself like in dcoppa's post.

If the APN isn't already setup and you aren't certain about which
one to use, then it's probably useful to connect with the provider's
normal software on a Windows/MacOS machine and close the connection,
then open a terminal to the serial port of the device (putty can
do serial if you're on a newer version of Windows with no built-in
terminal software) and type AT+CGDCONT? to see how the contexts
are setup.




Thanks a lot -- it basically works!

# cat /etc/ppp/peers/vodafone 


debug
/dev/cuaU0
921600
0.0.0.0:10.99.1.2
defaultroute
noipdefault
user web
crtscts
persist
deflate 0
refuse-pap
refuse-chap
noauth
noipdefault
noccp
novj
novjccomp
nopcomp
connect '/usr/sbin/chat -v -f /etc/ppp/vodafone.chat'

# cat /etc/ppp/vodafone.chat 


TIMEOUT 120
ABORT BUSY
ABORT ERROR
ABORT NO CARRIER
ABORT VOICE
ABORT NO DIALTONE
 ATZ
OK 'AT+CPIN=1234'
OK 'AT+CGDCONT=1,IP,web.vodafone.de'
OK ATD*99#
CONNECT \c

# cat /etc/ppp/pap-secrets 


#   $OpenBSD: pap-secrets,v 1.3 2002/06/09 06:15:15 todd Exp $

# Secrets for authentication using PAP
# clientserver  secret  IP addresses
web *   web

commands for dialing in:
# ifconfig ppp0 create
# pppd file /etc/ppp/peers/vodafone

I get an IP and a default route. I can also ping/connect to remote hosts.

From /var/log/messages:
Jul 16 19:52:36 obsd pppd[19227]: Connect: ppp0 -- /dev/cuaU0
Jul 16 19:52:36 obsd pppd[19227]: Received bad configure-ack:
Jul 16 19:52:40 obsd pppd[19227]: Received bad configure-ack:
Jul 16 19:52:42 obsd pppd[19227]: local  IP address 109.43.234.229
Jul 16 19:52:42 obsd pppd[19227]: remote IP address 10.99.1.2

Any ideas what's causing the bad configure-acks?

Is there a way to automatically receive a DNS resolver config for 
/etc/resolv.conf from the mobile ISP? (currently I use the DNS resolver 
at my local network...)


Best Regards
Andreas

Huawei E303

[Andreas Bartelt]

Hi,

I've got a Huawei E303 UMTS stick which doesn't work out of the box in 
current.


After adding the following patch, the E303 seems to be recognized:
# cvs diff -u usbdevs usbdevs.h usbdevs_data.h umsm.c 


Index: usbdevs
===
RCS file: /cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.580
diff -u -r1.580 usbdevs
--- usbdevs 7 Jul 2012 17:59:03 -   1.580
+++ usbdevs 15 Jul 2012 14:14:59 -
@@ -2033,6 +2033,7 @@
 product HUAWEI K3765_INIT  0x1520  HUAWEI Mobile K3765 Initial
 product HUAWEI E173S   0x1c05  HUAWEI Mobile E173s
 product HUAWEI E173S_INIT  0x1c0b  HUAWEI Mobile E173s Initial
+product HUAWEI E3030x1f01  HUAWEI Mobile E303

 /* HUMAX products */
 product HUMAX PVRSMART 0x138c  PVR-SMART
Index: usbdevs.h
===
RCS file: /cvs/src/sys/dev/usb/usbdevs.h,v
retrieving revision 1.590
diff -u -r1.590 usbdevs.h
--- usbdevs.h   7 Jul 2012 17:59:44 -   1.590
+++ usbdevs.h   15 Jul 2012 14:14:59 -
@@ -2040,6 +2040,7 @@
 #defineUSB_PRODUCT_HUAWEI_K3765_INIT   0x1520  /* 
HUAWEI Mobile K3765 Initial */
 #defineUSB_PRODUCT_HUAWEI_E173S0x1c05  /* 
HUAWEI Mobile E173s */
 #defineUSB_PRODUCT_HUAWEI_E173S_INIT   0x1c0b  /* 
HUAWEI Mobile E173s Initial */
+#defineUSB_PRODUCT_HUAWEI_E303 0x1f01  /* 
HUAWEI Mobile E303 */


 /* HUMAX products */
 #defineUSB_PRODUCT_HUMAX_PVRSMART  0x138c  /* 
PVR-SMART */

Index: usbdevs_data.h
===
RCS file: /cvs/src/sys/dev/usb/usbdevs_data.h,v
retrieving revision 1.584
diff -u -r1.584 usbdevs_data.h
--- usbdevs_data.h  7 Jul 2012 17:59:45 -   1.584
+++ usbdevs_data.h  15 Jul 2012 14:15:00 -
@@ -4242,6 +4242,10 @@
HUAWEI Mobile E173s Initial,
},
{
+   USB_VENDOR_HUAWEI, USB_PRODUCT_HUAWEI_E303,
+   HUAWEI Mobile E303,
+   },
+   {
USB_VENDOR_HUMAX, USB_PRODUCT_HUMAX_PVRSMART,
PVR-SMART,
},
Index: umsm.c
===
RCS file: /cvs/src/sys/dev/usb/umsm.c,v
retrieving revision 1.85
diff -u -r1.85 umsm.c
--- umsm.c  14 Jan 2012 10:26:11 -  1.85
+++ umsm.c  15 Jul 2012 14:15:00 -
@@ -138,6 +138,7 @@
{{ USB_VENDOR_HUAWEI,   USB_PRODUCT_HUAWEI_E182 }, DEV_UMASS5},
{{ USB_VENDOR_HUAWEI,   USB_PRODUCT_HUAWEI_E1820 }, DEV_UMASS5},
{{ USB_VENDOR_HUAWEI,   USB_PRODUCT_HUAWEI_E220 }, DEV_HUAWEI},
+   {{ USB_VENDOR_HUAWEI,   USB_PRODUCT_HUAWEI_E303 }, DEV_UMASS5},
{{ USB_VENDOR_HUAWEI,   USB_PRODUCT_HUAWEI_E510 }, DEV_HUAWEI},
{{ USB_VENDOR_HUAWEI,   USB_PRODUCT_HUAWEI_E618 }, DEV_HUAWEI},
{{ USB_VENDOR_HUAWEI,   USB_PRODUCT_HUAWEI_EM770W }, 0},

from dmesg after the patch:
umsm0 at uhub0 port 5 configuration 1 interface 0 HUAWEI HUAWEI HiLink 
rev 2.00/1.02 addr 2

umsm0 detached
umsm0 at uhub0 port 5 configuration 1 interface 0 HUAWEI HUAWEI HiLink 
rev 2.00/1.02 addr 2

ucom0 at umsm0
umsm1 at uhub0 port 5 configuration 1 interface 1 HUAWEI HUAWEI HiLink 
rev 2.00/1.02 addr 2

ucom1 at umsm1
umsm2 at uhub0 port 5 configuration 1 interface 2 HUAWEI HUAWEI HiLink 
rev 2.00/1.02 addr 2

ucom2 at umsm2

Unfortunately, I have no clue where to go from there. I'd like to 
connect to vodafone in Germany via UMTS, but I didn't find a 
/etc/ppp/peers/ and a corresponding chat script configuration in the 
archives which works for me.


Is anybody else using a similar setup?

Best Regards
Andreas

Re: Huawei E303

[Andreas Bartelt]

On 07/15/12 16:53, Paul Irofti wrote:

Unfortunately, I have no clue where to go from there. I'd like to
connect to vodafone in Germany via UMTS, but I didn't find a
/etc/ppp/peers/ and a corresponding chat script configuration in the
archives which works for me.

Is anybody else using a similar setup?


I tried the same with Vodafone RO for quite a few months two years ago.
Bottom line is it doesn't work.

I had the same problems two years ago. Tried to make the config work
with Vodafone RO and failed miserably. I can firmly say that those were
two months that I lost in vain.

What I would recommand is to stop wasting time now and only use that
modem on Windows with the applications provided by Vodafone.



thanks for crushing my hope ;)

I would be fine with ANY 3G or 4G mobile ISP in Germany which works via 
umsm(4) on OpenBSD. Is there one?


Best Regards
Andreas

Re: nc(1), GNU netcat and FIN segments after all data has been sent

[Andreas Bartelt]

On 06/23/11 21:05, Christopher Zimmermann wrote:
...

Maybe you can force nc(1) not to send a FIN segment by using something
like this:

cat infile - |nc host 1234



This works. Thanks!

nc(1), GNU netcat and FIN segments after all data has been sent

[Andreas Bartelt]

Hello,

I've noticed that there's a difference in behavior between nc(1) and GNU 
netcat when they talk to some daemon via TCP.


The commands in the following example are basically the same:

GNU netcat:
netcat host 1234  infile

nc(1):
nc host 1234  infile

nc(1) sends a FIN segment after all data has been read from stdin: 
shutdown(nfd, SHUT_WR) in netcat.c causes TCP to enter FIN-WAIT-1 state. 
GNU netcat doesn't do this. I've noticed that some daemons behave 
differently because of this, i.e., they won't return any data although 
they are still allowed to send data.


I think both variants are allowed in RFC 793. Would it make sense to add 
a further option to nc(1) which allows to toggle between both variants?


Regards
Andreas

Re: nc(1), GNU netcat and FIN segments after all data has been sent

[Andreas Bartelt]

Hi Theo,

On 06/23/11 18:30, Theo de Raadt wrote:
...

I've noticed that some daemons behave
differently because of this, i.e., they won't return any data although
they are still allowed to send data.


Yes, those daemons are broken.  Their select/poll loops are unaware
that writeability and readability of a socket is independent.

One of the reasons that netcat should do be doing this, is so that
such bugs can be triggered.  It is a good thing for them to be
triggered.  The half-open socket semantics are the real world and
they happen all the time.



yes, you're right.

I've noticed that the behavior is different while doing some work 
related stuff with some server software which is proprietary and buggy 
-- and it probably will never get fixed...


The irony is that testing buggy software worked only with buggy software 
in this particular case.



I think both variants are allowed in RFC 793. Would it make sense to add
a further option to nc(1) which allows to toggle between both variants?


There is no variation.  Sockets can be half-closed.  Sure, a particular
client or server could leave it open until completely, but now you are
testing less.  You are saying it is a variation when you use less than
full functionality of a socket?  That's not a variation.  It's called a
subset.

But I think your real problem is that GNU netcat is incompatible.  Typical.



My problem was related to the server side. I needed GNU netcat in 
order to trigger (possibly even more buggy) responses from the (buggy) 
server side. My particular use case was not about right or wrong but 
about triggering some stuff on the server side.


I'm aware that the current behavior of nc(1) is the intended way to 
handle TCP sessions according to RFC 793. I was not sure if the GNU 
variant is actually non-compliant.


Regards
Andreas

Re: ifconfig(8) tunnel and address families

[Andreas Bartelt]

Hello Stuart,

On 05/16/11 12:59, Stuart Henderson wrote:

Re http://permalink.gmane.org/gmane.os.openbsd.misc/185629
To set IPv6 tunnel endpoints for gif/gre, you have to use
syntax like ifconfig gif0 inet6 tunnel 1::1 2::2 rather
than just ifconfig gif0 tunnel 1::1 2::2.

This is because settunnel provides an af hint to getaddrinfo,
so it only considers addresses of a specified family.

The code already checks that the families match, so the hint
seems to be pointless. How about this diff? Works as expected
in my tests with v4 and v6.



the patch works and makes the tunnel configuration for v4/v6 addresses 
more consistent.


Thanks,
Andreas



Index: ifconfig.c
===
RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v
retrieving revision 1.246
diff -u -p -u -7 -r1.246 ifconfig.c
--- ifconfig.c  23 Mar 2011 18:36:41 -  1.246
+++ ifconfig.c  16 May 2011 10:53:39 -
@@ -3151,27 +3151,23 @@ in6_status(int force)
  }
  #endif /*INET6*/

  #ifndef SMALL
  void
  settunnel(const char *src, const char *dst)
  {
-   struct addrinfo hints, *srcres, *dstres;
+   struct addrinfo *srcres, *dstres;
int ecode;
struct if_laddrreq req;

-   memset(hints, 0, sizeof(hints));
-   hints.ai_family = afp-af_af;
-   hints.ai_socktype = SOCK_DGRAM; /*dummy*/
-
-   if ((ecode = getaddrinfo(src, NULL,hints,srcres)) != 0)
+   if ((ecode = getaddrinfo(src, NULL, NULL,srcres)) != 0)
errx(1, error in parsing address string: %s,
gai_strerror(ecode));

-   if ((ecode = getaddrinfo(dst, NULL,hints,dstres)) != 0)
+   if ((ecode = getaddrinfo(dst, NULL, NULL,dstres)) != 0)
errx(1, error in parsing address string: %s,
gai_strerror(ecode));

if (srcres-ai_addr-sa_family != dstres-ai_addr-sa_family)
errx(1,
source and destination address families do not match);

typo in icmp6(4)

[Andreas Bartelt]

Hello,

I've noticed a typo in the icmp6(4) man page regarding icmp6 type 4 code 
2. Diff is attached.

According to the (informational) RFC 4890 this kind of icmp6 message 
must not be dropped for the correct functioning of IPv6. Is there a key 
word planned for this icmp6 code which could be used in PF?

Best regards,
Andreas
Index: share/man/man4/icmp6.4
===
RCS file: /usr/cvsync/cvs/src/share/man/man4/icmp6.4,v
retrieving revision 1.23
diff -u -r1.23 icmp6.4
--- share/man/man4/icmp6.4  8 Dec 2009 07:57:57 -   1.23
+++ share/man/man4/icmp6.4  7 May 2011 19:05:11 -
@@ -126,7 +126,7 @@
 .It 1 Ta reassemb Ta timex Ta Time exceeded in reassembly
 .It 0 Ta badhead Ta paramprob Ta Erroneous header field
 .It 1 Ta nxthdr Ta paramprob Ta Unrecognized next header
-.It 2 Ta  Ta redir Ta Unrecognized option
+.It 2 Ta  Ta paramprob Ta Unrecognized option
 .It 0 Ta redironlink Ta redir Ta Redirection to on-link node
 .It 1 Ta redirrouter Ta redir Ta Redirection to better router
 .El

Re: softraid(4) disks are of wrong size

[Andreas Bartelt]

On 12/19/10 22:28, Kenneth R Westerback wrote:
...

You should NEVER use 'c' partition. Amoung other things, it is
always set by the kernel to encompass the whole disk, everytime the
disklabel is read. If you restore to a different sized disk interesting
things might happen. I thought we also always set it to UNUSED, but
if not I will revisit that.



I've used the native disk sd4c as RAID only for testing, since this 
improved my understanding of the problem.


Is there also a problem when newfs is used on the virtual softraid(4) 
disk 'c' partition (rsd5c in my example)?


I originally discovered the problem when I tried newfs(8) on rsd5c where 
the native disk was sd4a. As I wrote in my initial mail, this results in 
a kernel panic. The kernel panics in sr_crypto_finish_io(), and before 
this, bounds_check_with_label (in kern/subr_disk.c) (which gets called 
in sd.c:572 for the softraid(4) disk sd5) returns '-1'. I didn't further 
inspect if this panic could/should be avoided like in the test where the 
native RAID disk was sd4c.

Re: softraid(4) disks are of wrong size

[Andreas Bartelt]

On 12/20/10 18:26, Kenneth R Westerback wrote:
...

Can you provide the details on the exact panic you saw? Just to make sure
when an issue is reproduced we know we are working on the same problem.



Debugger
panic
sr_crypto_finish_io
sr_crypto_intr
sdstrategy
spec_strategy
VOP_STRATEGY
sr_startwu_callback

sd.c:572 calls bounds_check_with_label (in kern/subr_disk.c) which 
returns '-1' in line 698. My assumption was that this eventually leads 
to the panic.

Re: softraid(4) disks are of wrong size

[Andreas Bartelt]

On 12/19/10 17:15, Marco Peereboom wrote:

I could swear we had the sizes right but I'll have another look at this.

What raid type did you test this with?



I've only tested CRYPTO, but sr_meta_native_probe() seems to be used by 
all disciplines.


Try newfs /dev/rsdXc where X is a virtual softraid(4) disk in order to 
trigger the test case.