Re: ftp(1): HTTP/1.1
On Mon, Nov 11 2019, Stuart Henderson wrote: > On 2019/11/11 18:07, Jeremie Courreges-Anglas wrote: >> >> More and more people seem to reject HTTP/1.0 clients, to avoid log spam, >> vulnerability scanners, etc. Some MASTER_SITES in ports started doing >> this (eg https://download.samba.org). >> >> The diff below implements HTTP/1.1 support in ftp(1). The main concern >> is the "chunked" Transfer-Encoding (mandatory). The slight code size >> increase is compensated by the recent space savings to fit on the >> install media (passed a make release). This also fared well in a few >> dpb -F runs, sites generating archives on-the-fly like github aren't >> negatively affected. >> >> ok? > > Works for me so far, I need to do a dpb -F run here soon so I'll do that > with this diff in. I'm not sure where to find a site that wants > chunked-transfer-encoding to test that though. Well I mentioned github because it directly affects ports; but there are tons of such websites really. I don't have at hand a page that *requires* HTTP/1.1 + chunked encoding support right now, but you can already see whether ftp(1) uses chunked encoding by looking at headers with ftp(1) -d. Even initial directory listings from cdn.openbsd.org will be served as chunked (the answer is then cached). > "size obj/ftp" in src/distrib/special/ftp on amd64: > > textdatabss dec hex > 407215 13352 43328 463895 71417 old > 407983 13352 43328 464663 71717 new > > Unless we have any arches that are *really* tight on bsd.rd space I think > that's fine. Yeah, also confirmed by Theo. > ok with me. If the code looks ok to others then I'd prefer it goes in > sooner than later. Thanks a lot for the quick feedback. Anyone else wants to give it a shot? -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: sysupgrade: Allow to use another directory for the sets
Renaud Allard wrote:
> +.It Fl d Ar directory
> +Choose the
> +.Ar directory
> +in which the sets will be downloaded.
> +Default is
> +.Pa /home/_sysupgrade .
...
> + d) SETSDIR=${OPTARG};;
...
> -rm -f /home/_sysupgrade/{${CLEAN}}
> +rm -f ${SETSDIR}/{${CLEAN}}
Renaud, please test it for me like this:
sysupgrade -d /
This interface is dangerously incorrect.
Re: sysupgrade: Allow to use another directory for the sets
On Tue, Nov 12, 2019 at 08:06:52AM +0100, Renaud Allard wrote:
>
>
> On 09/11/2019 12:52, Klemens Nanni wrote:
> > On Fri, Nov 08, 2019 at 11:59:20AM +, Stuart Henderson wrote:
> >>> Given the amount of people which encrypt /home directory on their servers,
> >>> it might be useful to be able to define another directory for the sets in
> >>> sysupgrade as /home_sysupgrade will not be available in that case.
> >>
> >> This (encrypted /home but not boot-loader-assisted FDE) doesn't seem
> >> like it would be all that common a thing to me, but I can think of
> >> other use cases for moving the directory.
> >>
> >> I know a similar request was rejected in earlier sysupgrade, but now
> >> that sysupgrade uses /auto_upgrade.conf rather than special code in
> >> install.sub it seems a reasonable change to make.
> >>
> >>> +.It Fl d Ar directory
> >>> +Choose the
> >>
> >> Nit: trailing whitespace, otherwise it's OK sthen@
> > I agree with sthen here, but the diff still misses an update to usage();
> >
> > SETSDIR values containing spaces will also blow up the script. Not
> > reachable due to earlier errors, but this is worth noting as we install
> > `rm -f ${SETSDIR}{${CLEAN}}` into rc.firsttime(8) which is run as root,
> > so careful with blindly rm(1)'ing user input.
> >
>
> Here a reviewed patch for the whitespace and usage() update.
>
> Maybe we can already commit this while trying to find an elegant
> solution to the path with whitespace. Any suggestions into solving the
> whitespace issue?
hi.
in both SYNOPSIS and usage() single letter options go first. so you want
to put -d after fkn. in this particular case it should probably go after
-r | -s too i.e. just before "installurl".
jmc
> Index: sysupgrade.8
> ===
> RCS file: /cvs/src/usr.sbin/sysupgrade/sysupgrade.8,v
> retrieving revision 1.10
> diff -u -p -r1.10 sysupgrade.8
> --- sysupgrade.8 3 Oct 2019 12:43:58 - 1.10
> +++ sysupgrade.8 12 Nov 2019 07:04:05 -
> @@ -22,6 +22,7 @@
> .Nd upgrade system to the next release or a new snapshot
> .Sh SYNOPSIS
> .Nm
> +.Op Fl d Ar directory
> .Op Fl fkn
> .Op Fl r | s
> .Op Ar installurl
> @@ -48,6 +49,12 @@ triggering a one-shot upgrade using the
> .Pp
> The options are as follows:
> .Bl -tag -width Ds
> +.It Fl d Ar directory
> +Choose the
> +.Ar directory
> +in which the sets will be downloaded.
> +Default is
> +.Pa /home/_sysupgrade .
> .It Fl f
> Force an already applied upgrade.
> The default is to upgrade to latest snapshot only if available.
> Index: sysupgrade.sh
> ===
> RCS file: /cvs/src/usr.sbin/sysupgrade/sysupgrade.sh,v
> retrieving revision 1.32
> diff -u -p -r1.32 sysupgrade.sh
> --- sysupgrade.sh 11 Nov 2019 18:26:52 - 1.32
> +++ sysupgrade.sh 12 Nov 2019 07:04:05 -
> @@ -25,7 +25,6 @@ umask 0022
> export PATH=/usr/bin:/bin:/usr/sbin:/sbin
>
> ARCH=$(uname -m)
> -SETSDIR=/home/_sysupgrade
>
> ug_err()
> {
> @@ -34,7 +33,7 @@ ug_err()
>
> usage()
> {
> - ug_err "usage: ${0##*/} [-fkn] [-r | -s] [installurl]"
> + ug_err "usage: ${0##*/} [-fkn] [-d directory] [-r | -s] [installurl]"
> }
>
> unpriv()
> @@ -73,14 +72,16 @@ rmel() {
> echo -n "$_c"
> }
>
> +SETSDIR=/home/_sysupgrade
> RELEASE=false
> SNAP=false
> FORCE=false
> KEEP=false
> REBOOT=true
>
> -while getopts fknrs arg; do
> +while getopts d:fknrs arg; do
> case ${arg} in
> + d) SETSDIR=${OPTARG};;
> f) FORCE=true;;
> k) KEEP=true;;
> n) REBOOT=false;;
> @@ -195,7 +196,7 @@ ${KEEP} && > keep
>
> cat <<__EOT >/auto_upgrade.conf
> Location of sets = disk
> -Pathname to the sets = /home/_sysupgrade/
> +Pathname to the sets = ${SETSDIR}
> Set name(s) = done
> Directory does not contain SHA256.sig. Continue without verification = yes
> __EOT
> @@ -203,7 +204,7 @@ __EOT
> if ! ${KEEP}; then
> CLEAN=$(echo SHA256 ${SETS} | sed -e 's/ /,/g')
> cat <<__EOT > /etc/rc.firsttime
> -rm -f /home/_sysupgrade/{${CLEAN}}
> +rm -f ${SETSDIR}/{${CLEAN}}
> __EOT
> fi
>
Re: sysupgrade: Allow to use another directory for the sets
On 09/11/2019 12:52, Klemens Nanni wrote:
On Fri, Nov 08, 2019 at 11:59:20AM +, Stuart Henderson wrote:
Given the amount of people which encrypt /home directory on their servers,
it might be useful to be able to define another directory for the sets in
sysupgrade as /home_sysupgrade will not be available in that case.
This (encrypted /home but not boot-loader-assisted FDE) doesn't seem
like it would be all that common a thing to me, but I can think of
other use cases for moving the directory.
I know a similar request was rejected in earlier sysupgrade, but now
that sysupgrade uses /auto_upgrade.conf rather than special code in
install.sub it seems a reasonable change to make.
+.It Fl d Ar directory
+Choose the
Nit: trailing whitespace, otherwise it's OK sthen@
I agree with sthen here, but the diff still misses an update to usage();
SETSDIR values containing spaces will also blow up the script. Not
reachable due to earlier errors, but this is worth noting as we install
`rm -f ${SETSDIR}{${CLEAN}}` into rc.firsttime(8) which is run as root,
so careful with blindly rm(1)'ing user input.
Here a reviewed patch for the whitespace and usage() update.
Maybe we can already commit this while trying to find an elegant
solution to the path with whitespace. Any suggestions into solving the
whitespace issue?
Index: sysupgrade.8
===
RCS file: /cvs/src/usr.sbin/sysupgrade/sysupgrade.8,v
retrieving revision 1.10
diff -u -p -r1.10 sysupgrade.8
--- sysupgrade.83 Oct 2019 12:43:58 - 1.10
+++ sysupgrade.812 Nov 2019 07:04:05 -
@@ -22,6 +22,7 @@
.Nd upgrade system to the next release or a new snapshot
.Sh SYNOPSIS
.Nm
+.Op Fl d Ar directory
.Op Fl fkn
.Op Fl r | s
.Op Ar installurl
@@ -48,6 +49,12 @@ triggering a one-shot upgrade using the
.Pp
The options are as follows:
.Bl -tag -width Ds
+.It Fl d Ar directory
+Choose the
+.Ar directory
+in which the sets will be downloaded.
+Default is
+.Pa /home/_sysupgrade .
.It Fl f
Force an already applied upgrade.
The default is to upgrade to latest snapshot only if available.
Index: sysupgrade.sh
===
RCS file: /cvs/src/usr.sbin/sysupgrade/sysupgrade.sh,v
retrieving revision 1.32
diff -u -p -r1.32 sysupgrade.sh
--- sysupgrade.sh 11 Nov 2019 18:26:52 - 1.32
+++ sysupgrade.sh 12 Nov 2019 07:04:05 -
@@ -25,7 +25,6 @@ umask 0022
export PATH=/usr/bin:/bin:/usr/sbin:/sbin
ARCH=$(uname -m)
-SETSDIR=/home/_sysupgrade
ug_err()
{
@@ -34,7 +33,7 @@ ug_err()
usage()
{
- ug_err "usage: ${0##*/} [-fkn] [-r | -s] [installurl]"
+ ug_err "usage: ${0##*/} [-fkn] [-d directory] [-r | -s] [installurl]"
}
unpriv()
@@ -73,14 +72,16 @@ rmel() {
echo -n "$_c"
}
+SETSDIR=/home/_sysupgrade
RELEASE=false
SNAP=false
FORCE=false
KEEP=false
REBOOT=true
-while getopts fknrs arg; do
+while getopts d:fknrs arg; do
case ${arg} in
+ d) SETSDIR=${OPTARG};;
f) FORCE=true;;
k) KEEP=true;;
n) REBOOT=false;;
@@ -195,7 +196,7 @@ ${KEEP} && > keep
cat <<__EOT >/auto_upgrade.conf
Location of sets = disk
-Pathname to the sets = /home/_sysupgrade/
+Pathname to the sets = ${SETSDIR}
Set name(s) = done
Directory does not contain SHA256.sig. Continue without verification = yes
__EOT
@@ -203,7 +204,7 @@ __EOT
if ! ${KEEP}; then
CLEAN=$(echo SHA256 ${SETS} | sed -e 's/ /,/g')
cat <<__EOT > /etc/rc.firsttime
-rm -f /home/_sysupgrade/{${CLEAN}}
+rm -f ${SETSDIR}/{${CLEAN}}
__EOT
fi
Re: iwm: fix support for 3168 devices
On Mon, Nov 11, 2019 at 06:33:39PM +0200, Stefan Sperling wrote: > > On Mon, Nov 11, 2019 at 10:19:12AM +0800, Kevin Lo wrote: > > On Sat, Nov 09, 2019 at 01:01:39PM +0200, Stefan Sperling wrote: > > > > > > This diff makes 3168 devices actually work with iwm(4). > > > These devices have never worked right since the driver just threw > > > errors when trying to load firmware. > > > > Indeed. The 3168 device didn't work for me (for example, ifconfig iwm0 scan > > returns empty results) until your diff is applied. > > The previous diff broke 7260/7265 devices. I made a mistake which resulted > in channel data structures not being initialized on those devices which > resulted in "panic: iwm0: bogus channel pointer" during boot. > > Problem fixed with the diff below. This diff still works on my msi Cubi 3 Silent. > ok? ok kevlo@
Re: ftp(1): HTTP/1.1
On 2019/11/11 18:07, Jeremie Courreges-Anglas wrote:
>
> More and more people seem to reject HTTP/1.0 clients, to avoid log spam,
> vulnerability scanners, etc. Some MASTER_SITES in ports started doing
> this (eg https://download.samba.org).
>
> The diff below implements HTTP/1.1 support in ftp(1). The main concern
> is the "chunked" Transfer-Encoding (mandatory). The slight code size
> increase is compensated by the recent space savings to fit on the
> install media (passed a make release). This also fared well in a few
> dpb -F runs, sites generating archives on-the-fly like github aren't
> negatively affected.
>
> ok?
Works for me so far, I need to do a dpb -F run here soon so I'll do that
with this diff in. I'm not sure where to find a site that wants
chunked-transfer-encoding to test that though.
"size obj/ftp" in src/distrib/special/ftp on amd64:
textdatabss dec hex
407215 13352 43328 463895 71417 old
407983 13352 43328 464663 71717 new
Unless we have any arches that are *really* tight on bsd.rd space I think
that's fine.
ok with me. If the code looks ok to others then I'd prefer it goes in
sooner than later.
> +++ fetch.c 11 Nov 2019 15:43:08 -
> @@ -69,6 +69,7 @@ struct tls;
> #include "cmds.h"
>
> static int url_get(const char *, const char *, const char *, int);
> +static int save_chunked(FILE *, struct tls *, int , char *, size_t);
> static void aborthttp(int);
> static void abortfile(int);
> static char hextochar(const char *);
> @@ -213,6 +214,7 @@ url_get(const char *origline, const char
> int status;
> int save_errno;
> const size_t buflen = 128 * 1024;
> + int chunked = 0;
>
> direction = "received";
>
> @@ -687,13 +689,15 @@ noslash:
>* the original URI (path).
>*/
> if (credentials)
> - fprintf(fin, "GET %s HTTP/1.0\r\n"
> + fprintf(fin, "GET %s HTTP/1.1\r\n"
> + "Connection: close\r\n"
> "Proxy-Authorization: Basic %s\r\n"
> "Host: %s\r\n%s%s\r\n\r\n",
> epath, credentials,
> proxyhost, buf ? buf : "", httpuseragent);
> else
> - fprintf(fin, "GET %s HTTP/1.0\r\n"
> + fprintf(fin, "GET %s HTTP/1.1\r\n"
> + "Connection: close\r\n"
> "Host: %s\r\n%s%s\r\n\r\n",
> epath, proxyhost, buf ? buf : "", httpuseragent);
> } else {
> @@ -712,19 +716,18 @@ noslash:
> #ifndef NOSSL
> if (credentials) {
> fprintf(fin,
> - "GET /%s %s\r\nAuthorization: Basic %s\r\nHost: ",
> - epath, restart_point ?
> - "HTTP/1.1\r\nConnection: close" : "HTTP/1.0",
> - credentials);
> + "GET /%s HTTP/1.1\r\n"
> + "Connection: close\r\n"
> + "Authorization: Basic %s\r\n"
> + "Host: ", epath, credentials);
> free(credentials);
> credentials = NULL;
> } else
> #endif /* NOSSL */
> - fprintf(fin, "GET /%s %s\r\nHost: ", epath,
> -#ifndef SMALL
> - restart_point ? "HTTP/1.1\r\nConnection: close" :
> -#endif /* !SMALL */
> - "HTTP/1.0");
> + fprintf(fin,
> + "GET /%s HTTP/1.1\r\n"
> + "Connection: close\r\n"
> + "Host: ", epath);
> if (proxyhost) {
> fprintf(fin, "%s", proxyhost);
> port = NULL;
> @@ -942,10 +945,21 @@ noslash:
> retryafter = strtonum(cp, 0, 0, &errstr);
> if (errstr != NULL)
> retryafter = -1;
> +#define TRANSFER_ENCODING "Transfer-Encoding: "
> + } else if (strncasecmp(cp, TRANSFER_ENCODING,
> + sizeof(TRANSFER_ENCODING) - 1) == 0) {
> + cp += sizeof(TRANSFER_ENCODING) - 1;
> + cp[strcspn(cp, " \t")] = '\0';
> + if (strcasecmp(cp, "chunked") == 0)
> + chunked = 1;
> }
> free(buf);
> }
>
> + /* Content-Length should be ignored for Transfer-Encoding: chunked */
> + if (chunked)
> + filesize = -1;
> +
> if (isunavail) {
> if (retried || retryafter != 0)
> warnx("Error retrieving %s: 503 Service Unavailable",
> @@ -1005,39 +1019,46 @@ noslash:
> /* Finally, suck down the file. */
> if ((buf = malloc(buflen)) == NULL)
> errx(1, "Can't allocate memory for t
Re: iked(8): add configuration option for esn
On Mon, Nov 11, 2019 at 03:34:03PM +0100, Tobias Heider wrote:
> Currently iked does not provide an option to configure extended sequence
> numbers
> (ESN) for child SAs, but always proposes/accepts both options.
> This diff adds a new optional "esn on/off" config option to explicitly enable
> or disable esn.
>
> ok?
OK bluhm@, with one remark
> @@ -2833,6 +2859,11 @@ create_ike(char *name, int af, uint8_t i
> if ((p = calloc(1, sizeof(*p))) == NULL)
> err(1, "%s", __func__);
>
> + if (ike_sa->xfs[i]->nesnxf) {
> + yyerror("cannot use ESN with ikesa.");
> + goto done;
> + }
> +
This check should be before the calloc(3). Otherwise you leak the
p in the goto done case.
bluhm
Re: HEADS UP: ntpd changing
On Sun, Nov 10, 2019 at 05:03:02PM -0700, Theo de Raadt wrote: > The ntpd options -s and -S are going to be removed soon and at startup > with print: > > -s option no longer works and will be removed soon. > Please reconfigure to use constraints or trusted servers. > > Probably after 6.7 we'll delete the warning. Maybe for 6.8 we'll remove > -s and -S from getopt, and starting with those options will fail. > > Effective immediately, the -s option stops doing what you expect. It now > does nothing. > > Big improvements have happened in ntpd recently. At startup, ntpd > aggressively tries to learn from NTP packets validated by constraints, > and set the time. > > That means a smarter variation of -s is the default, but the information > is now *VALIDATED* by constraints. > > 2 additional constraints have been added. If you have upgraded, please > review /etc/examples/ntpd.conf for modern use > > Those who cannot use https constraints, can instead tag server lines > with the keyword "trusted", which means you believe MITM attacks are not > possible on the network to those specific NTP servers. Do this only on > servers directly connected over trusted network. If someone does > "servers pool.ntp.org trusted", we're going to have a great laugh. > > We're creating something a bit complex, but our goal is for every > machine to have a close approximation of correct time. If we get > there, some good things will happen. Some serious cargo-culting > for using -s has gotten in the way (-s performs no MITM checks). > So if you are running current do the following. Likely you can stop after step 2. 1. remove -s from ntpd_flags 2. check if the default ntpd.config works for you; it most lilely will, *including setting the time on boot*. 3. if you cannot use constraints because https to the world is not possible, consider running ntpd on your local net and use that as a peer marked as trusted or if availabel use a sensor marked as trusted. 4. Still having problems? Report so we can look at you use-case and find a solution. -Otto
Re: TCP send window underflow
Hello, the change looks OK to me. thanks and regards sashan
iked(8): use msg_valid to handle duplicate fragment sequence numbers
With IKEv2 message fragmentation a message is split into several fragments,
which all have the same sequence number. In the original commit this was
handled with an explicit exception to accept the same sequence number as
before, in case the number of stored fragments is not 0.
Another recent fix introduced the msg_valid variable which is used to
determine whether a received message was valid and the sequence number
should be increased.
This diff gets rid of the exception and sets the valid flag/bumps up the
sequence number only when the final fragment was received and the
reconstructed message was succesfully handled.
ok?
diff --git a/sbin/iked/ikev2.c b/sbin/iked/ikev2.c
index 08bf1ca0a0c..f6148be352b 100644
--- a/sbin/iked/ikev2.c
+++ b/sbin/iked/ikev2.c
@@ -518,8 +518,7 @@ ikev2_recv(struct iked *env, struct iked_message *msg)
sa_free(env, sa);
}
return;
- } else if (sa->sa_msgid_set && msg->msg_msgid == sa->sa_msgid &&
- !(sa->sa_fragments.frag_count)) {
+ } else if (sa->sa_msgid_set && msg->msg_msgid == sa->sa_msgid) {
/*
* Response is being worked on, most likely we're
* waiting for the CA process to get back to us
@@ -2349,11 +2348,11 @@ ikev2_resp_recv(struct iked *env, struct iked_message
*msg,
if ((sa = msg->msg_sa) == NULL)
return;
- msg->msg_valid = 1;
-
if (sa->sa_fragments.frag_count !=0)
return;
+ msg->msg_valid = 1;
+
if (msg->msg_natt && sa->sa_natt == 0) {
log_debug("%s: NAT-T message received, updated SA", __func__);
sa->sa_natt = 1;
Re: Fix rw_assert_unlocked(9)
Hello, On Mon, Nov 11, 2019 at 04:48:43PM +0100, Martin Pieuchot wrote: > On 11/11/19(Mon) 12:07, Alexandr Nedvedicky wrote: > > Hello, > > > > > > On Sun, Nov 10, 2019 at 04:11:55PM +0100, Martin Pieuchot wrote: > > > rw_assert_unlocked(9) should check if the current thread is holding > > > the lock, not if the lock is held by anyone else. The general check > > > is racy and I cannot think of any safe way to use it. > > > > looks ok. just one nit, how about going for this: > > > > if (RWLOCK_OWNER(rwl) == (struct proc *)RW_PROC(curproc)) > > > > just to keep form consistent with stuff we have rw_assert_wrlock() > > couple lines above. would it make sense? > > The idiom in that diff is the one present in rw_status() and > rw_enter_diag(). The consistency could be fixed afterward. Thanks for > pointing that out. sure, OK then. thanks and regards sashan
Re: iwm: fix support for 3168 devices
On Mon, Nov 11, 2019 at 10:19:12AM +0800, Kevin Lo wrote:
> On Sat, Nov 09, 2019 at 01:01:39PM +0200, Stefan Sperling wrote:
> >
> > This diff makes 3168 devices actually work with iwm(4).
> > These devices have never worked right since the driver just threw
> > errors when trying to load firmware.
>
> Indeed. The 3168 device didn't work for me (for example, ifconfig iwm0 scan
> returns empty results) until your diff is applied.
The previous diff broke 7260/7265 devices. I made a mistake which resulted
in channel data structures not being initialized on those devices which
resulted in "panic: iwm0: bogus channel pointer" during boot.
Problem fixed with the diff below.
ok?
diff refs/heads/master refs/heads/nvmsdp
blob - ea6f2b9561ee5f7634fb0db5a19e466b67e8f473 (mode 644)
blob + 741617c6fb5ad4bffc00232d20c448349f1efd7e (mode 600)
--- sys/dev/pci/if_iwm.c
+++ sys/dev/pci/if_iwm.c
@@ -319,7 +319,7 @@ int iwm_nvm_read_chunk(struct iwm_softc *, uint16_t, u
intiwm_nvm_read_section(struct iwm_softc *, uint16_t, uint8_t *,
uint16_t *, size_t);
void iwm_init_channel_map(struct iwm_softc *, const uint16_t * const,
- const uint8_t *nvm_channels, size_t nchan);
+ const uint8_t *nvm_channels, int nchan);
void iwm_setup_ht_rates(struct iwm_softc *);
void iwm_htprot_task(void *);
void iwm_update_htprot(struct ieee80211com *, struct ieee80211_node *);
@@ -340,7 +340,7 @@ voidiwm_ba_task(void *);
intiwm_parse_nvm_data(struct iwm_softc *, const uint16_t *,
const uint16_t *, const uint16_t *,
const uint16_t *, const uint16_t *,
- const uint16_t *);
+ const uint16_t *, int);
void iwm_set_hw_address_8000(struct iwm_softc *, struct iwm_nvm_data *,
const uint16_t *, const uint16_t *);
intiwm_parse_nvm_sections(struct iwm_softc *, struct iwm_nvm_section *);
@@ -2374,6 +2374,7 @@ const int iwm_nvm_to_read[] = {
IWM_NVM_SECTION_TYPE_REGULATORY,
IWM_NVM_SECTION_TYPE_CALIBRATION,
IWM_NVM_SECTION_TYPE_PRODUCTION,
+ IWM_NVM_SECTION_TYPE_REGULATORY_SDP,
IWM_NVM_SECTION_TYPE_HW_8000,
IWM_NVM_SECTION_TYPE_MAC_OVERRIDE,
IWM_NVM_SECTION_TYPE_PHY_SKU,
@@ -2511,7 +2512,7 @@ iwm_fw_valid_rx_ant(struct iwm_softc *sc)
void
iwm_init_channel_map(struct iwm_softc *sc, const uint16_t * const nvm_ch_flags,
-const uint8_t *nvm_channels, size_t nchan)
+const uint8_t *nvm_channels, int nchan)
{
struct ieee80211com *ic = &sc->sc_ic;
struct iwm_nvm_data *data = &sc->sc_nvm;
@@ -2796,7 +2797,7 @@ int
iwm_parse_nvm_data(struct iwm_softc *sc, const uint16_t *nvm_hw,
const uint16_t *nvm_sw, const uint16_t *nvm_calib,
const uint16_t *mac_override, const uint16_t *phy_sku,
-const uint16_t *regulatory)
+const uint16_t *regulatory, int n_regulatory)
{
struct iwm_nvm_data *data = &sc->sc_nvm;
uint8_t hw_addr[ETHER_ADDR_LEN];
@@ -2855,12 +2856,18 @@ iwm_parse_nvm_data(struct iwm_softc *sc, const uint16_
} else
iwm_set_hw_address_8000(sc, data, mac_override, nvm_hw);
- if (sc->sc_device_family == IWM_DEVICE_FAMILY_7000)
- iwm_init_channel_map(sc, &nvm_sw[IWM_NVM_CHANNELS],
- iwm_nvm_channels, nitems(iwm_nvm_channels));
- else
+ if (sc->sc_device_family == IWM_DEVICE_FAMILY_7000) {
+ if (sc->nvm_type == IWM_NVM_SDP) {
+ iwm_init_channel_map(sc, regulatory, iwm_nvm_channels,
+ MIN(n_regulatory, nitems(iwm_nvm_channels)));
+ } else {
+ iwm_init_channel_map(sc, &nvm_sw[IWM_NVM_CHANNELS],
+ iwm_nvm_channels, nitems(iwm_nvm_channels));
+ }
+ } else
iwm_init_channel_map(sc, ®ulatory[IWM_NVM_CHANNELS_8000],
- iwm_nvm_channels_8000, nitems(iwm_nvm_channels_8000));
+ iwm_nvm_channels_8000,
+ MIN(n_regulatory, nitems(iwm_nvm_channels_8000)));
data->calib_version = 255; /* TODO:
this value will prevent some checks from
@@ -2876,6 +2883,7 @@ iwm_parse_nvm_sections(struct iwm_softc *sc, struct iw
{
const uint16_t *hw, *sw, *calib, *mac_override = NULL, *phy_sku = NULL;
const uint16_t *regulatory = NULL;
+ int n_regulatory = 0;
/* Checking for required sections */
if (sc->sc_device_family == IWM_DEVICE_FAMILY_7000) {
@@ -2885,6 +2893,15 @@ iwm_parse_nvm_sections(struct iwm_softc *sc, struct iw
}
hw = (const uint16_t *) sections[IWM_NVM_SECTION_TYPE_HW].data;
+
+ if (sc->nvm_type == IWM_NVM_SDP) {
+ if (!sections[IWM_NVM_SECTION_TYPE_REGULATORY_SDP].data)
+ return ENOENT;
+ regulatory = (const uint16_t *)
+ section
ftp(1): HTTP/1.1
More and more people seem to reject HTTP/1.0 clients, to avoid log spam,
vulnerability scanners, etc. Some MASTER_SITES in ports started doing
this (eg https://download.samba.org).
The diff below implements HTTP/1.1 support in ftp(1). The main concern
is the "chunked" Transfer-Encoding (mandatory). The slight code size
increase is compensated by the recent space savings to fit on the
install media (passed a make release). This also fared well in a few
dpb -F runs, sites generating archives on-the-fly like github aren't
negatively affected.
ok?
Index: fetch.c
===
RCS file: /cvs/src/usr.bin/ftp/fetch.c,v
retrieving revision 1.177
diff -u -p -r1.177 fetch.c
--- fetch.c 4 Nov 2019 15:36:36 - 1.177
+++ fetch.c 11 Nov 2019 15:43:08 -
@@ -69,6 +69,7 @@ struct tls;
#include "cmds.h"
static int url_get(const char *, const char *, const char *, int);
+static int save_chunked(FILE *, struct tls *, int , char *, size_t);
static voidaborthttp(int);
static voidabortfile(int);
static charhextochar(const char *);
@@ -213,6 +214,7 @@ url_get(const char *origline, const char
int status;
int save_errno;
const size_t buflen = 128 * 1024;
+ int chunked = 0;
direction = "received";
@@ -687,13 +689,15 @@ noslash:
* the original URI (path).
*/
if (credentials)
- fprintf(fin, "GET %s HTTP/1.0\r\n"
+ fprintf(fin, "GET %s HTTP/1.1\r\n"
+ "Connection: close\r\n"
"Proxy-Authorization: Basic %s\r\n"
"Host: %s\r\n%s%s\r\n\r\n",
epath, credentials,
proxyhost, buf ? buf : "", httpuseragent);
else
- fprintf(fin, "GET %s HTTP/1.0\r\n"
+ fprintf(fin, "GET %s HTTP/1.1\r\n"
+ "Connection: close\r\n"
"Host: %s\r\n%s%s\r\n\r\n",
epath, proxyhost, buf ? buf : "", httpuseragent);
} else {
@@ -712,19 +716,18 @@ noslash:
#ifndef NOSSL
if (credentials) {
fprintf(fin,
- "GET /%s %s\r\nAuthorization: Basic %s\r\nHost: ",
- epath, restart_point ?
- "HTTP/1.1\r\nConnection: close" : "HTTP/1.0",
- credentials);
+ "GET /%s HTTP/1.1\r\n"
+ "Connection: close\r\n"
+ "Authorization: Basic %s\r\n"
+ "Host: ", epath, credentials);
free(credentials);
credentials = NULL;
} else
#endif /* NOSSL */
- fprintf(fin, "GET /%s %s\r\nHost: ", epath,
-#ifndef SMALL
- restart_point ? "HTTP/1.1\r\nConnection: close" :
-#endif /* !SMALL */
- "HTTP/1.0");
+ fprintf(fin,
+ "GET /%s HTTP/1.1\r\n"
+ "Connection: close\r\n"
+ "Host: ", epath);
if (proxyhost) {
fprintf(fin, "%s", proxyhost);
port = NULL;
@@ -942,10 +945,21 @@ noslash:
retryafter = strtonum(cp, 0, 0, &errstr);
if (errstr != NULL)
retryafter = -1;
+#define TRANSFER_ENCODING "Transfer-Encoding: "
+ } else if (strncasecmp(cp, TRANSFER_ENCODING,
+ sizeof(TRANSFER_ENCODING) - 1) == 0) {
+ cp += sizeof(TRANSFER_ENCODING) - 1;
+ cp[strcspn(cp, " \t")] = '\0';
+ if (strcasecmp(cp, "chunked") == 0)
+ chunked = 1;
}
free(buf);
}
+ /* Content-Length should be ignored for Transfer-Encoding: chunked */
+ if (chunked)
+ filesize = -1;
+
if (isunavail) {
if (retried || retryafter != 0)
warnx("Error retrieving %s: 503 Service Unavailable",
@@ -1005,39 +1019,46 @@ noslash:
/* Finally, suck down the file. */
if ((buf = malloc(buflen)) == NULL)
errx(1, "Can't allocate memory for transfer buffer");
- i = 0;
- len = 1;
oldinti = signal(SIGINFO, psummary);
- while (len > 0) {
- len = fread(buf, 1, buflen, fin);
- bytes += len;
- for (cp = buf, wlen = len; wlen > 0; wlen -= i, cp += i) {
- if ((i = write(out, cp, wlen)) == -1) {
- warn("Writing %s", savefile);
-
Re: Fix rw_assert_unlocked(9)
On 11/11/19(Mon) 12:07, Alexandr Nedvedicky wrote:
> Hello,
>
>
> On Sun, Nov 10, 2019 at 04:11:55PM +0100, Martin Pieuchot wrote:
> > rw_assert_unlocked(9) should check if the current thread is holding
> > the lock, not if the lock is held by anyone else. The general check
> > is racy and I cannot think of any safe way to use it.
>
> looks ok. just one nit, how about going for this:
>
> if (RWLOCK_OWNER(rwl) == (struct proc *)RW_PROC(curproc))
>
> just to keep form consistent with stuff we have rw_assert_wrlock()
> couple lines above. would it make sense?
The idiom in that diff is the one present in rw_status() and
rw_enter_diag(). The consistency could be fixed afterward. Thanks for
pointing that out.
> thanks and
> regards
> sashan
>
> >
> > Diff below is required for the vm_map_asssert_locked() diff I sent
> > earlier.
> >
> > Index: kern/kern_rwlock.c
> > ===
> > RCS file: /cvs/src/sys/kern/kern_rwlock.c,v
> > retrieving revision 1.40
> > diff -u -p -r1.40 kern_rwlock.c
> > --- kern/kern_rwlock.c 16 Jul 2019 01:40:49 - 1.40
> > +++ kern/kern_rwlock.c 10 Nov 2019 15:06:51 -
> > @@ -400,7 +400,7 @@ rw_assert_unlocked(struct rwlock *rwl)
> > if (panicstr || db_active)
> > return;
> >
> > - if (rwl->rwl_owner != 0L)
> > + if (RW_PROC(curproc) == RW_PROC(rwl->rwl_owner))
> > panic("%s: lock held", rwl->rwl_name);
> > }
> > #endif
> >
>
Re: iked(8): add configuration option for esn
Sure, I have a crypto device that only supports SAs with ESN. For it to be used I have to force iked to only negotiate SAs with ESP support. Another one is high-speed network cards: Accepting a policy with ESN disabled can throttle my throughput because it exhausts the sequence number space forcing me to rekey more often than I would like. On Mon, Nov 11, 2019 at 04:15:32PM +0100, Mike Belopuhov wrote: > On Mon, 11 Nov 2019 at 16:08, Tobias Heider wrote: > > > Hi Mike, > > > > the default behaviour is the same as before. I ran into cases where it is > > necessary for me to enforce ESN to be enabled/disabled, which is not > > possible > > currently. > > > > Can you please describe those cases where you had to enforce it?
Re: iked(8): add configuration option for esn
On Mon, 11 Nov 2019 at 16:08, Tobias Heider wrote: > Hi Mike, > > the default behaviour is the same as before. I ran into cases where it is > necessary for me to enforce ESN to be enabled/disabled, which is not > possible > currently. > Can you please describe those cases where you had to enforce it?
Re: iked(8): add configuration option for esn
Hi Mike, the default behaviour is the same as before. I ran into cases where it is necessary for me to enforce ESN to be enabled/disabled, which is not possible currently. On Mon, Nov 11, 2019 at 04:01:32PM +0100, Mike Belopuhov wrote: > On Mon, 11 Nov 2019 at 15:47, Tobias Heider wrote: > > > Currently iked does not provide an option to configure extended sequence > > numbers > > (ESN) for child SAs, but always proposes/accepts both options. > > This diff adds a new optional "esn on/off" config option to explicitly > > enable > > or disable esn. > > > > ok? > > > > > Hi Tobias, > > What's wrong with the current behavior? Does you patch retain it? > > Regards, > Mike
Re: iked(8): add configuration option for esn
On Mon, 11 Nov 2019 at 15:47, Tobias Heider wrote: > Currently iked does not provide an option to configure extended sequence > numbers > (ESN) for child SAs, but always proposes/accepts both options. > This diff adds a new optional "esn on/off" config option to explicitly > enable > or disable esn. > > ok? > > Hi Tobias, What's wrong with the current behavior? Does you patch retain it? Regards, Mike
iked(8): add configuration option for esn
Currently iked does not provide an option to configure extended sequence numbers
(ESN) for child SAs, but always proposes/accepts both options.
This diff adds a new optional "esn on/off" config option to explicitly enable
or disable esn.
ok?
Index: iked.conf.5
===
RCS file: /mount/openbsd/cvs/src/sbin/iked/iked.conf.5,v
retrieving revision 1.57
diff -u -p -r1.57 iked.conf.5
--- iked.conf.5 24 Aug 2019 13:24:49 - 1.57
+++ iked.conf.5 11 Nov 2019 14:16:45 -
@@ -409,6 +409,7 @@ multiple crypto transforms.
.Ic auth Ar algorithm
.Ic enc Ar algorithm
.Ic group Ar group
+.Ic esn Ar esn
.Xc
These parameters define the cryptographic transforms to be used for
the Child SA negotiation, also known as phase 2.
@@ -421,6 +422,7 @@ Possible values for
.Ic auth ,
.Ic enc ,
.Ic group ,
+.Ic esn ,
and the default proposals are described below in
.Sx CRYPTO TRANSFORMS .
If omitted,
@@ -849,6 +851,15 @@ not encryption:
.It Li aes-192-gmac Ta "224 bits" Ta "[ESP only]"
.It Li aes-256-gmac Ta "288 bits" Ta "[ESP only]"
.It Li null Ta "" Ta "[ESP only]"
+.El
+.Pp
+The Extended Sequence Numbers option can be enabled or disabled with the
+.Ic esn
+keyword:
+.Bl -column "ESN" "[ESP only]" -offset indent
+.It Em ESN
+.It Li on Ta "[ESP only]"
+.It Li off Ta "[ESP only]"
.El
.Pp
Transforms followed by
Index: parse.y
===
RCS file: /mount/openbsd/cvs/src/sbin/iked/parse.y,v
retrieving revision 1.84
diff -u -p -r1.84 parse.y
--- parse.y 26 Sep 2019 07:33:36 - 1.84
+++ parse.y 11 Nov 2019 14:21:48 -
@@ -127,6 +127,8 @@ struct ipsec_transforms {
unsigned int nencxf;
const struct ipsec_xf **groupxf;
unsigned int ngroupxf;
+ const struct ipsec_xf **esnxf;
+ unsigned int nesnxf;
};
struct ipsec_mode {
@@ -259,6 +261,12 @@ const struct ipsec_xf groupxfs[] = {
{ NULL }
};
+const struct ipsec_xf esnxfs[] = {
+ { "on", IKEV2_XFORMESN_ESN },
+ { "off",IKEV2_XFORMESN_NONE },
+ { NULL }
+};
+
const struct ipsec_xf methodxfs[] = {
{ "none", IKEV2_AUTH_NONE },
{ "rsa",IKEV2_AUTH_RSA_SIG },
@@ -395,7 +403,7 @@ typedef struct {
%}
%token FROM ESP AH IN PEER ON OUT TO SRCID DSTID PSK PORT
-%token FILENAME AUTHXF PRFXF ENCXF ERROR IKEV2 IKESA CHILDSA
+%token FILENAME AUTHXF PRFXF ENCXF ERROR IKEV2 IKESA CHILDSA ESN
%token PASSIVE ACTIVE ANY TAG TAP PROTO LOCAL GROUP NAME CONFIG EAP USER
%token IKEV1 FLOW SA TCPMD5 TUNNEL TRANSPORT COUPLE DECOUPLE SET
%token INCLUDE LIFETIME BYTES INET INET6 QUICK SKIP DEFAULT
@@ -802,6 +810,19 @@ transform : AUTHXF STRING {
ipsec_transforms->groupxf = xfs;
ipsec_transforms->ngroupxf++;
}
+ | ESN STRING{
+ const struct ipsec_xf **xfs = ipsec_transforms->esnxf;
+ size_t nxfs = ipsec_transforms->nesnxf;
+ xfs = recallocarray(xfs, nxfs, nxfs + 1,
+ sizeof(struct ipsec_xf *));
+ if ((xfs[nxfs] = parse_xf($2, 0, esnxfs)) == NULL) {
+ yyerror("%s not a valid transform", $2);
+ YYERROR;
+ }
+ free($2);
+ ipsec_transforms->esnxf = xfs;
+ ipsec_transforms->nesnxf++;
+ }
;
ike_sas: {
@@ -1180,6 +1201,7 @@ lookup(char *s)
{ "dstid", DSTID },
{ "eap",EAP },
{ "enc",ENCXF },
+ { "esn",ESN },
{ "esp",ESP },
{ "file", FILENAME },
{ "flow", FLOW },
@@ -2578,6 +2600,10 @@ print_policy(struct iked_policy *pol)
print_verbose(" group ");
xfs = groupxfs;
break;
+ case IKEV2_XFORMTYPE_ESN:
+ print_verbose(" esn ");
+ xfs = esnxfs;
+ break;
default:
continue;
}
@@ -2833,6 +2859,11 @@ create_ike(char *name, int af, uint8_t i
if ((p = calloc(1, sizeof(*p))) == NULL)
err(1, "%s", __func__);
+
Re: OpenBSD on IBM Power.
Hi Ben, To my best awareness, Power9 support is underway. No idea about date. Maybe usable in 4-12mo? Joseph On Wednesday, 6 November 2019 12:49, Ben Crowhurst wrote: > I've seen a few threads discussing OpenBSD on IBM Power Systems. > http://openbsd-archive.7691.n7.nabble.com/What-about-the-IBM-POWER7-and-POWER8-platforms-did-anyone-ever-think-about-porting-these-to-OpenBSD-td290583.html > > Does anyone have an update/status report on the progress? > > Regards, > Ben Crowhurst | Corvusoft > www.corvusoft.co.uk
Re: Fix rw_assert_unlocked(9)
Hello,
On Sun, Nov 10, 2019 at 04:11:55PM +0100, Martin Pieuchot wrote:
> rw_assert_unlocked(9) should check if the current thread is holding
> the lock, not if the lock is held by anyone else. The general check
> is racy and I cannot think of any safe way to use it.
looks ok. just one nit, how about going for this:
if (RWLOCK_OWNER(rwl) == (struct proc *)RW_PROC(curproc))
just to keep form consistent with stuff we have rw_assert_wrlock()
couple lines above. would it make sense?
thanks and
regards
sashan
>
> Diff below is required for the vm_map_asssert_locked() diff I sent
> earlier.
>
> Index: kern/kern_rwlock.c
> ===
> RCS file: /cvs/src/sys/kern/kern_rwlock.c,v
> retrieving revision 1.40
> diff -u -p -r1.40 kern_rwlock.c
> --- kern/kern_rwlock.c16 Jul 2019 01:40:49 - 1.40
> +++ kern/kern_rwlock.c10 Nov 2019 15:06:51 -
> @@ -400,7 +400,7 @@ rw_assert_unlocked(struct rwlock *rwl)
> if (panicstr || db_active)
> return;
>
> - if (rwl->rwl_owner != 0L)
> + if (RW_PROC(curproc) == RW_PROC(rwl->rwl_owner))
> panic("%s: lock held", rwl->rwl_name);
> }
> #endif
>
Re: OpenBSD on IBM Power.
Since that time various people tried various things -- for reference see ppc@ but personally most closest thing of running OpenBSD on POWER I've seen so far was OpenBSD in amd64/qemu which was kind of PITA performance wise. OpenBSD/macppc is not working in qemu at all and although netbsd/macppc goes way far, it's still not able to be installed properly. On the other hand this all was with quite old (2.12) qemu supported in ubuntu 18.04 since so far I've not found a time/energy to deal with linux kernel compile + new qemu and testing various combinations of openbsd/netbsd install configurations... On 2019-11-06 05:49, Ben Crowhurst wrote: I've seen a few threads discussing OpenBSD on IBM Power Systems. http://openbsd-archive.7691.n7.nabble.com/What-about-the-IBM-POWER7-and-POWER8-platforms-did-anyone-ever-think-about-porting-these-to-OpenBSD-td290583.html Does anyone have an update/status report on the progress? Regards, Ben Crowhurst | Corvusoft www.corvusoft.co.uk
