Re: ftp(1): add SOCKS proxy support
Hi Steffen,
On 11/27/20 05:59 AM, Steffen Nurpmeso wrote:
> Nick Gasson wrote in
> <87im9srza8@bertha.nickg.me.uk>:
> |Hi,
> |
> |I often need to go through a SOCKS proxy to access certain sites. The
> |diff below adds SOCKS5 support to ftp(1) for HTTP transfers, similar to
> |curl(1). Enabled when http_proxy is set to a socks5:// URL.
> |
> |Also fixes two existing memory leaks: proxyurl (set to NULL on line 646
> |before freeing) and sslpath (never freed).
> |
> |Tested with ssh -D and a few other SOCKS5 proxies. Also verified the
> |existing HTTP proxy feature still works with squid(8).
>
> By the way, the $SOCKS5_PROXY environment variable becomes used
> for automatic selection of SOCKS5. (Some things on FreeBSD,
> lynx(1), and, hm, the MUA i maintain, s-nail; maybe more.)
>
(Sorry for the late reply.)
Yes I see FreeBSD fetch added SOCKS5_PROXY recently. I've updated the
diff below to support that too. Anyone interested?
--
Thanks,
Nick
Index: usr.bin/ftp/fetch.c
===
RCS file: /cvs/src/usr.bin/ftp/fetch.c,v
retrieving revision 1.199
diff -u -p -u -r1.199 fetch.c
--- usr.bin/ftp/fetch.c 1 Jan 2021 17:39:54 - 1.199
+++ usr.bin/ftp/fetch.c 2 Jan 2021 12:02:39 -
@@ -88,13 +88,18 @@ static int proxy_connect(int, char *, ch
static int stdio_tls_write_wrapper(void *, const char *, int);
static int stdio_tls_read_wrapper(void *, char *, int);
#endif /* !NOSSL */
+static int read_fully(int, void *, size_t);
+static int write_fully(int, const void *, size_t);
+static int socks5_connect(int, const char *, const char *);
#defineFTP_URL "ftp://;/* ftp URL prefix */
#defineHTTP_URL"http://; /* http URL prefix */
#defineHTTPS_URL "https://; /* https URL prefix */
+#defineSOCKS5_URL "socks5://" /* socks5 URL prefix */
#defineFILE_URL"file:" /* file URL prefix */
#define FTP_PROXY "ftp_proxy" /* env var with ftp proxy location */
#define HTTP_PROXY "http_proxy"/* env var with http proxy location */
+#define SOCKS5_PROXY "SOCKS5_PROXY" /* env var with socks5 proxy location */
#define EMPTYSTRING(x) ((x) == NULL || (*(x) == '\0'))
@@ -345,6 +350,7 @@ url_get(const char *origline, const char
int save_errno;
const size_t buflen = 128 * 1024;
int chunked = 0;
+ enum proxy_scheme proxy = PROXY_NONE;
direction = "received";
@@ -455,11 +461,16 @@ noslash:
proxyurl = strdup(proxyenv);
if (proxyurl == NULL)
errx(1, "Can't allocate memory for proxy URL.");
- if (strncasecmp(proxyurl, HTTP_URL, sizeof(HTTP_URL) - 1) == 0)
+ if (strncasecmp(proxyurl, HTTP_URL, sizeof(HTTP_URL) - 1) == 0)
{
host = proxyurl + sizeof(HTTP_URL) - 1;
- else if (strncasecmp(proxyurl, FTP_URL, sizeof(FTP_URL) - 1) ==
0)
+ proxy = PROXY_HTTP;
+ } else if (strncasecmp(proxyurl, FTP_URL, sizeof(FTP_URL) - 1)
== 0) {
host = proxyurl + sizeof(FTP_URL) - 1;
- else {
+ proxy = PROXY_HTTP; /* Treat ftp:// as a HTTP proxy */
+ } else if (strncasecmp(proxyurl, SOCKS5_URL, sizeof(SOCKS5_URL)
- 1) == 0) {
+ host = proxyurl + sizeof(SOCKS5_URL) - 1;
+ proxy = PROXY_SOCKS5;
+ } else {
warnx("Malformed proxy URL: %s", proxyenv);
goto cleanup_url_get;
}
@@ -467,11 +478,14 @@ noslash:
warnx("Malformed proxy URL: %s", proxyenv);
goto cleanup_url_get;
}
+ }
+
+ if (proxy == PROXY_HTTP) {
if (*--path == '\0')
*path = '/';/* add / back to real path */
path = strchr(host, '/'); /* remove trailing / on host */
if (!EMPTYSTRING(path))
- *path++ = '\0'; /* i guess this ++ is useless */
+ *path = '\0';
path = strchr(host, '@'); /* look for credentials in
proxy */
if (!EMPTYSTRING(path)) {
@@ -623,9 +637,25 @@ noslash:
port = NULL;
#ifndef NOSSL
- if (proxyenv && sslhost)
+ if (proxy == PROXY_HTTP && sslhost)
proxy_connect(fd, sslhost, proxy_credentials);
#endif /* !NOSSL */
+
+ if (proxy == PROXY_SOCKS5) {
+ portnum = strrchr(proxyhost, ':');
+ if (portnum != NULL)
+ *portnum++ = '\0';
+ else
+ portnum = ishttpsurl ? httpsport : httpport;
+
+
Re: Make kernel recognize more Lynloong models
On Sat, Jan 02, 2021 at 12:06:57PM +, Yifei ZHAN wrote:
> Hi,
>
> The following patch will make kernel recognize Lynloong LM9002/9003 and
> LM9013. I think LM9002/9003 is very similar to LM9001 since it works just
> fine on my LM9002 with the codebase for LM9001. (Maybe they are just a
> different batch of LM9001 for education market)
>
> LM9013 on the other hand is fairly different from LM9001 and is more like
> Yeeloong 8089 when it comes to hardware design. I might need to make a few
> drivers for its IDE/USB interfaces in future for it to be fully
> functional.
I have committed your patch. Thank you.
> Index: sys/arch/loongson/loongson/machdep.c
> ===
> RCS file: /cvs/src/sys/arch/loongson/loongson/machdep.c,v
> retrieving revision 1.93
> diff -u -r1.93 machdep.c
> --- sys/arch/loongson/loongson/machdep.c 17 Nov 2020 16:38:10 -
> 1.93
> +++ sys/arch/loongson/loongson/machdep.c 1 Jan 2021 11:43:42 -
> @@ -207,6 +207,10 @@
> { "LM8101", _platform },
> /* Lemote Lynloong all-in-one computer */
> { "LM9001", _platform },
> + { "LM9002", _platform },
> + { "LM9003", _platform },
> + /* Lemote Lynloong all-in-one computer, Xueloong edition */
> + { "LM9013", _platform },
> #endif
> #ifdef CPU_LOONGSON3
> /* Laptops */
>
Make kernel recognize more Lynloong models
Hi,
The following patch will make kernel recognize Lynloong LM9002/9003 and
LM9013. I think LM9002/9003 is very similar to LM9001 since it works just
fine on my LM9002 with the codebase for LM9001. (Maybe they are just a
different batch of LM9001 for education market)
LM9013 on the other hand is fairly different from LM9001 and is more like
Yeeloong 8089 when it comes to hardware design. I might need to make a few
drivers for its IDE/USB interfaces in future for it to be fully
functional.
Index: sys/arch/loongson/loongson/machdep.c
===
RCS file: /cvs/src/sys/arch/loongson/loongson/machdep.c,v
retrieving revision 1.93
diff -u -r1.93 machdep.c
--- sys/arch/loongson/loongson/machdep.c17 Nov 2020 16:38:10 -
1.93
+++ sys/arch/loongson/loongson/machdep.c1 Jan 2021 11:43:42 -
@@ -207,6 +207,10 @@
{ "LM8101", _platform },
/* Lemote Lynloong all-in-one computer */
{ "LM9001", _platform },
+ { "LM9002", _platform },
+ { "LM9003", _platform },
+ /* Lemote Lynloong all-in-one computer, Xueloong edition */
+ { "LM9013", _platform },
#endif
#ifdef CPU_LOONGSON3
/* Laptops */
Fix display resolution for Lynloong machines
Hi, The following patch will set the display resolution to 1368x768 for Lynloong all-in-one computers, which is their native resolution. Currently their resolution is being set to 1024x600 which prevents the screen from working properly. Tested on my LM9002. (maybe I should update all the docs as well?) Index: sys/arch/loongson/dev/smfb.c === RCS file: /cvs/src/sys/arch/loongson/dev/smfb.c,v retrieving revision 1.19 diff -u -r1.19 smfb.c --- sys/arch/loongson/dev/smfb.c25 May 2020 09:55:48 - 1.19 +++ sys/arch/loongson/dev/smfb.c1 Jan 2021 11:44:20 - @@ -20,7 +20,8 @@ * SiliconMotion SM502 and SM712 frame buffer driver. * * Assumes its video output is an LCD panel, in 5:6:5 mode, and fixed - * 1024x600 or 800x480 resolution, depending on the system model. + * 1024x600(Yeeloong) or 1368x768(Lynloong) or 800x480(EBT700) resolution + * depending on the system model. */ #include @@ -389,9 +390,12 @@ ri->ri_width = 800; ri->ri_height = 480; break; + case LOONGSON_LYNLOONG: + ri->ri_width = 1368; + ri->ri_height = 768; + break; default: case LOONGSON_GDIUM: - case LOONGSON_LYNLOONG: case LOONGSON_YEELOONG: ri->ri_width = 1024; ri->ri_height = 600;
Re: Fix display resolution for Lynloong machines
> Hi, > > The following patch will set the display resolution to 1368x768 for > Lynloong all-in-one computers, which is their native resolution. Currently > their resolution is being set to 1024x600 which prevents the screen from > working properly. > > Tested on my LM9002. (maybe I should update all the docs as well?) > here is a better version with space before parenthesis. Index: sys/arch/loongson/dev/smfb.c === RCS file: /cvs/src/sys/arch/loongson/dev/smfb.c,v retrieving revision 1.19 diff -u -r1.19 smfb.c --- sys/arch/loongson/dev/smfb.c25 May 2020 09:55:48 - 1.19 +++ sys/arch/loongson/dev/smfb.c2 Jan 2021 12:26:49 - @@ -20,7 +20,8 @@ * SiliconMotion SM502 and SM712 frame buffer driver. * * Assumes its video output is an LCD panel, in 5:6:5 mode, and fixed - * 1024x600 or 800x480 resolution, depending on the system model. + * 1024x600 (Yeeloong) or 1368x768 (Lynloong) or 800x480 (EBT700) + * resolution depending on the system model. */ #include @@ -389,9 +390,12 @@ ri->ri_width = 800; ri->ri_height = 480; break; + case LOONGSON_LYNLOONG: + ri->ri_width = 1368; + ri->ri_height = 768; + break; default: case LOONGSON_GDIUM: - case LOONGSON_LYNLOONG: case LOONGSON_YEELOONG: ri->ri_width = 1024; ri->ri_height = 600;
Re: Fix display resolution for Lynloong machines
On Sat, Jan 02, 2021 at 12:39:49PM +, Yifei ZHAN wrote: > > Hi, > > > > The following patch will set the display resolution to 1368x768 for > > Lynloong all-in-one computers, which is their native resolution. Currently > > their resolution is being set to 1024x600 which prevents the screen from > > working properly. > > > > Tested on my LM9002. (maybe I should update all the docs as well?) Updates to documentation are welcome. > here is a better version with space before parenthesis. Committed. Thank you. > Index: sys/arch/loongson/dev/smfb.c > === > RCS file: /cvs/src/sys/arch/loongson/dev/smfb.c,v > retrieving revision 1.19 > diff -u -r1.19 smfb.c > --- sys/arch/loongson/dev/smfb.c 25 May 2020 09:55:48 - 1.19 > +++ sys/arch/loongson/dev/smfb.c 2 Jan 2021 12:26:49 - > @@ -20,7 +20,8 @@ > * SiliconMotion SM502 and SM712 frame buffer driver. > * > * Assumes its video output is an LCD panel, in 5:6:5 mode, and fixed > - * 1024x600 or 800x480 resolution, depending on the system model. > + * 1024x600 (Yeeloong) or 1368x768 (Lynloong) or 800x480 (EBT700) > + * resolution depending on the system model. > */ > > #include > @@ -389,9 +390,12 @@ > ri->ri_width = 800; > ri->ri_height = 480; > break; > + case LOONGSON_LYNLOONG: > + ri->ri_width = 1368; > + ri->ri_height = 768; > + break; > default: > case LOONGSON_GDIUM: > - case LOONGSON_LYNLOONG: > case LOONGSON_YEELOONG: > ri->ri_width = 1024; > ri->ri_height = 600; >
acme-client(1): backup certs
Create .1 backup files when acme-client is going to overwrite a
certificate file.
This files are not terribly big and it's convenient to keep one
previous file around for example if one adds or removes domains to the
certificate and then wants to revoke the previous one.
(Note that it's kinda difficult to revoke the old certificate with
acme-client currently. The whole revoke machinery needs to be
overhauled. I have ideas...)
Comments, OKs?
diff --git acme-client.conf.5 acme-client.conf.5
index 3c5fd1c2362..3fdd40a5eb0 100644
--- acme-client.conf.5
+++ acme-client.conf.5
@@ -149,6 +149,11 @@ The filename of the certificate that will be issued.
This is optional if
.Ar domain full chain certificate
is specified.
+A backup with name
+.Ar file.1
+is created if
+.Ar file
+exists.
.It Ic domain chain certificate Ar file
The filename in which to store the certificate chain
that will be returned by the certificate authority.
@@ -156,6 +161,11 @@ It needs to be in the same directory as the
.Ar domain certificate
(or in a subdirectory) and can be specified as a relative or absolute path.
This setting is optional.
+A backup with name
+.Ar file.1
+is created if
+.Ar file
+exists.
.It Ic domain full chain certificate Ar file
The filename in which to store the full certificate chain
that will be returned by the certificate authority.
@@ -170,6 +180,11 @@ in one file, and is required by most browsers.
This is optional if
.Ar domain certificate
is specified.
+A backup with name
+.Ar file.1
+is created if
+.Ar file
+exists.
.It Ic sign with Ar authority
The certificate authority (as declared above in the
.Sx AUTHORITIES
diff --git fileproc.c fileproc.c
index b7cdff5525d..cc3aa293712 100644
--- fileproc.c
+++ fileproc.c
@@ -34,6 +34,19 @@ serialise(const char *real, const char *v, size_t vsz, const
char *v2, size_t v2
int fd;
char *tmp;
+ /* create backup hardlink */
+ if (asprintf(, "%s.1", real) == -1) {
+ warn("asprintf");
+ return 0;
+ }
+ (void) unlink(tmp);
+ if (link(real, tmp) == -1 && errno != ENOENT) {
+ warn("link");
+ free(tmp);
+ return 0;
+ }
+ free(tmp);
+
/*
* Write into backup location, overwriting.
* Then atomically do the rename.
--
I'm not entirely sure you are real.
Re: convert vga POST uvm_km_vallocs
> Date: Sat, 2 Jan 2021 18:39:03 +1000
> From: Jonathan Matthew
>
> This code is now only here for some unfortunate Intel graphics chips
> based on PowerVR, and I don't have a machine with one of those.
> vga_post_init() gets called from vga_attach() in any case, and
> vga_post_free() doesn't seem to be called at all. I've booted this on
> amd64 (real) and i386 (virtualized) with no problems.
>
> ok?
ok kettenis@
> diff --git sys/arch/amd64/pci/vga_post.c sys/arch/amd64/pci/vga_post.c
> index 32876649ddd..36596490d35 100644
> --- sys/arch/amd64/pci/vga_post.c
> +++ sys/arch/amd64/pci/vga_post.c
> @@ -125,13 +125,15 @@ vga_post_init(int bus, int device, int function)
> vaddr_t sys_image, sys_bios_data;
> int err;
>
> - sys_bios_data = uvm_km_valloc(kernel_map, PAGE_SIZE);
> + sys_bios_data = (vaddr_t)km_alloc(PAGE_SIZE, _any, _none,
> + _nowait);
> if (sys_bios_data == 0)
> return NULL;
>
> - sys_image = uvm_km_valloc(kernel_map, 1024 * 1024);
> + sys_image = (vaddr_t)km_alloc(1024 * 1024, _any, _none,
> + _nowait);
> if (sys_image == 0) {
> - uvm_km_free(kernel_map, sys_bios_data, PAGE_SIZE);
> + km_free((void *)sys_bios_data, PAGE_SIZE, _any, _none);
> return NULL;
> }
> sc = malloc(sizeof(*sc), M_DEVBUF, M_WAITOK|M_ZERO);
> @@ -140,7 +142,7 @@ vga_post_init(int bus, int device, int function)
> err = uvm_pglistalloc(BASE_MEMORY, 0, (paddr_t)-1, 0, 0,
> >ram_backing, BASE_MEMORY/PAGE_SIZE, UVM_PLA_WAITOK);
> if (err) {
> - uvm_km_free(kernel_map, sc->sys_image, 1024 * 1024);
> + km_free((void *)sc->sys_image, 1024 * 1024, _any, _none);
> free(sc, M_DEVBUF, sizeof(*sc));
> return NULL;
> }
> @@ -152,7 +154,7 @@ vga_post_init(int bus, int device, int function)
> pmap_update(pmap_kernel());
> memcpy((void *)sc->bios_data, (void *)sys_bios_data, PAGE_SIZE);
> pmap_kremove(sys_bios_data, PAGE_SIZE);
> - uvm_km_free(kernel_map, sys_bios_data, PAGE_SIZE);
> + km_free((void *)sys_bios_data, PAGE_SIZE, _any, _none);
>
> iter = 0;
> TAILQ_FOREACH(pg, >ram_backing, pageq) {
> @@ -209,7 +211,7 @@ vga_post_free(struct vga_post *sc)
> {
> uvm_pglistfree(>ram_backing);
> pmap_kremove(sc->sys_image, 1024 * 1024);
> - uvm_km_free(kernel_map, sc->sys_image, 1024 * 1024);
> + km_free((void *)sc->sys_image, 1024 * 1024, _any, _none)
> pmap_update(pmap_kernel());
> free(sc, M_DEVBUF, sizeof(*sc));
> }
> diff --git sys/arch/i386/pci/vga_post.c sys/arch/i386/pci/vga_post.c
> index c85ee05dcdb..2464fd6019c 100644
> --- sys/arch/i386/pci/vga_post.c
> +++ sys/arch/i386/pci/vga_post.c
> @@ -126,13 +126,15 @@ vga_post_init(int bus, int device, int function)
> vaddr_t sys_image, sys_bios_data;
> int err;
>
> - sys_bios_data = uvm_km_valloc(kernel_map, PAGE_SIZE);
> + sys_bios_data = (vaddr_t)km_alloc(PAGE_SIZE, _any, _none,
> + _nowait);
> if (sys_bios_data == 0)
> return NULL;
>
> - sys_image = uvm_km_valloc(kernel_map, 1024 * 1024);
> + sys_image = (vaddr_t)km_alloc(1024 * 1024, _any, _none,
> + _nowait);
> if (sys_image == 0) {
> - uvm_km_free(kernel_map, sys_bios_data, PAGE_SIZE);
> + km_free((void *)sys_bios_data, PAGE_SIZE, _any, _none);
> return NULL;
> }
> sc = malloc(sizeof(*sc), M_DEVBUF, M_WAITOK|M_ZERO);
> @@ -141,7 +143,7 @@ vga_post_init(int bus, int device, int function)
> err = uvm_pglistalloc(BASE_MEMORY, 0, (paddr_t)-1, 0, 0,
> >ram_backing, BASE_MEMORY/PAGE_SIZE, UVM_PLA_WAITOK);
> if (err) {
> - uvm_km_free(kernel_map, sc->sys_image, 1024 * 1024);
> + km_free((void *)sc->sys_image, 1024 * 1024, _any, _none);
> free(sc, M_DEVBUF, sizeof *sc);
> return NULL;
> }
> @@ -153,7 +155,7 @@ vga_post_init(int bus, int device, int function)
> pmap_update(pmap_kernel());
> memcpy((void *)sc->bios_data, (void *)sys_bios_data, PAGE_SIZE);
> pmap_kremove(sys_bios_data, PAGE_SIZE);
> - uvm_km_free(kernel_map, sys_bios_data, PAGE_SIZE);
> + km_free((void *)sys_bios_data, PAGE_SIZE, _any, _none);
>
> iter = 0;
> TAILQ_FOREACH(pg, >ram_backing, pageq) {
> @@ -211,7 +213,7 @@ vga_post_free(struct vga_post *sc)
> uvm_pglistfree(>ram_backing);
> pmap_kremove(sc->sys_image, 1024 * 1024);
>
> - uvm_km_free(kernel_map, sc->sys_image, 1024 * 1024);
> + km_free((void *)sc->sys_image, 1024 * 1024, _any, _none);
> pmap_update(pmap_kernel());
> free(sc, M_DEVBUF, sizeof *sc);
> }
>
>
convert vga POST uvm_km_vallocs
This code is now only here for some unfortunate Intel graphics chips
based on PowerVR, and I don't have a machine with one of those.
vga_post_init() gets called from vga_attach() in any case, and
vga_post_free() doesn't seem to be called at all. I've booted this on
amd64 (real) and i386 (virtualized) with no problems.
ok?
diff --git sys/arch/amd64/pci/vga_post.c sys/arch/amd64/pci/vga_post.c
index 32876649ddd..36596490d35 100644
--- sys/arch/amd64/pci/vga_post.c
+++ sys/arch/amd64/pci/vga_post.c
@@ -125,13 +125,15 @@ vga_post_init(int bus, int device, int function)
vaddr_t sys_image, sys_bios_data;
int err;
- sys_bios_data = uvm_km_valloc(kernel_map, PAGE_SIZE);
+ sys_bios_data = (vaddr_t)km_alloc(PAGE_SIZE, _any, _none,
+ _nowait);
if (sys_bios_data == 0)
return NULL;
- sys_image = uvm_km_valloc(kernel_map, 1024 * 1024);
+ sys_image = (vaddr_t)km_alloc(1024 * 1024, _any, _none,
+ _nowait);
if (sys_image == 0) {
- uvm_km_free(kernel_map, sys_bios_data, PAGE_SIZE);
+ km_free((void *)sys_bios_data, PAGE_SIZE, _any, _none);
return NULL;
}
sc = malloc(sizeof(*sc), M_DEVBUF, M_WAITOK|M_ZERO);
@@ -140,7 +142,7 @@ vga_post_init(int bus, int device, int function)
err = uvm_pglistalloc(BASE_MEMORY, 0, (paddr_t)-1, 0, 0,
>ram_backing, BASE_MEMORY/PAGE_SIZE, UVM_PLA_WAITOK);
if (err) {
- uvm_km_free(kernel_map, sc->sys_image, 1024 * 1024);
+ km_free((void *)sc->sys_image, 1024 * 1024, _any, _none);
free(sc, M_DEVBUF, sizeof(*sc));
return NULL;
}
@@ -152,7 +154,7 @@ vga_post_init(int bus, int device, int function)
pmap_update(pmap_kernel());
memcpy((void *)sc->bios_data, (void *)sys_bios_data, PAGE_SIZE);
pmap_kremove(sys_bios_data, PAGE_SIZE);
- uvm_km_free(kernel_map, sys_bios_data, PAGE_SIZE);
+ km_free((void *)sys_bios_data, PAGE_SIZE, _any, _none);
iter = 0;
TAILQ_FOREACH(pg, >ram_backing, pageq) {
@@ -209,7 +211,7 @@ vga_post_free(struct vga_post *sc)
{
uvm_pglistfree(>ram_backing);
pmap_kremove(sc->sys_image, 1024 * 1024);
- uvm_km_free(kernel_map, sc->sys_image, 1024 * 1024);
+ km_free((void *)sc->sys_image, 1024 * 1024, _any, _none)
pmap_update(pmap_kernel());
free(sc, M_DEVBUF, sizeof(*sc));
}
diff --git sys/arch/i386/pci/vga_post.c sys/arch/i386/pci/vga_post.c
index c85ee05dcdb..2464fd6019c 100644
--- sys/arch/i386/pci/vga_post.c
+++ sys/arch/i386/pci/vga_post.c
@@ -126,13 +126,15 @@ vga_post_init(int bus, int device, int function)
vaddr_t sys_image, sys_bios_data;
int err;
- sys_bios_data = uvm_km_valloc(kernel_map, PAGE_SIZE);
+ sys_bios_data = (vaddr_t)km_alloc(PAGE_SIZE, _any, _none,
+ _nowait);
if (sys_bios_data == 0)
return NULL;
- sys_image = uvm_km_valloc(kernel_map, 1024 * 1024);
+ sys_image = (vaddr_t)km_alloc(1024 * 1024, _any, _none,
+ _nowait);
if (sys_image == 0) {
- uvm_km_free(kernel_map, sys_bios_data, PAGE_SIZE);
+ km_free((void *)sys_bios_data, PAGE_SIZE, _any, _none);
return NULL;
}
sc = malloc(sizeof(*sc), M_DEVBUF, M_WAITOK|M_ZERO);
@@ -141,7 +143,7 @@ vga_post_init(int bus, int device, int function)
err = uvm_pglistalloc(BASE_MEMORY, 0, (paddr_t)-1, 0, 0,
>ram_backing, BASE_MEMORY/PAGE_SIZE, UVM_PLA_WAITOK);
if (err) {
- uvm_km_free(kernel_map, sc->sys_image, 1024 * 1024);
+ km_free((void *)sc->sys_image, 1024 * 1024, _any, _none);
free(sc, M_DEVBUF, sizeof *sc);
return NULL;
}
@@ -153,7 +155,7 @@ vga_post_init(int bus, int device, int function)
pmap_update(pmap_kernel());
memcpy((void *)sc->bios_data, (void *)sys_bios_data, PAGE_SIZE);
pmap_kremove(sys_bios_data, PAGE_SIZE);
- uvm_km_free(kernel_map, sys_bios_data, PAGE_SIZE);
+ km_free((void *)sys_bios_data, PAGE_SIZE, _any, _none);
iter = 0;
TAILQ_FOREACH(pg, >ram_backing, pageq) {
@@ -211,7 +213,7 @@ vga_post_free(struct vga_post *sc)
uvm_pglistfree(>ram_backing);
pmap_kremove(sc->sys_image, 1024 * 1024);
- uvm_km_free(kernel_map, sc->sys_image, 1024 * 1024);
+ km_free((void *)sc->sys_image, 1024 * 1024, _any, _none);
pmap_update(pmap_kernel());
free(sc, M_DEVBUF, sizeof *sc);
}
Re: pipex(4)/npppd(8): remove dummy PIPEX{G,S}MODE ioctl(2) calls
Yes,
ok yasuoka
On Wed, 30 Dec 2020 03:02:55 +0300
Vitaliy Makkoveev wrote:
> This time pipex(4) related ioctl(2) calls PIPEX{S,G}MODE are pretty
> dummy and were kept for backward compatibility reasons. The diff below
> removes them.
>
> ok?
>
> Index: share/man/man4/pipex.4
> ===
> RCS file: /cvs/src/share/man/man4/pipex.4,v
> retrieving revision 1.13
> diff -u -p -r1.13 pipex.4
> --- share/man/man4/pipex.49 Aug 2020 14:35:31 - 1.13
> +++ share/man/man4/pipex.429 Dec 2020 23:51:57 -
> @@ -57,20 +57,6 @@ or
> devices.
> The added requests are as follows:
> .Bl -tag -width Ds
> -.It Dv PIPEXGMODEFa "int *"
> -Get the devices's
> -.Nm
> -operation mode.
> -1 to enable
> -.Nm
> -on this device; 0 to disable.
> -.It Dv PIPEXSMODEFa "int *"
> -Set the device's
> -.Nm
> -operation mode.
> -1 to enable
> -.Nm
> -on this device; 0 to disable.
> .It Dv PIPEXASESSION Fa "struct pipex_session_req *"
> Add a new PPP session to be handled by
> .Nm .
> Index: sys/net/pipex.c
> ===
> RCS file: /cvs/src/sys/net/pipex.c,v
> retrieving revision 1.127
> diff -u -p -r1.127 pipex.c
> --- sys/net/pipex.c 30 Aug 2020 19:48:16 - 1.127
> +++ sys/net/pipex.c 29 Dec 2020 23:51:59 -
> @@ -163,13 +163,6 @@ pipex_ioctl(void *ownersc, u_long cmd, c
>
> NET_ASSERT_LOCKED();
> switch (cmd) {
> - case PIPEXSMODE:
> - break;
> -
> - case PIPEXGMODE:
> - *(int *)data = 1;
> - break;
> -
> case PIPEXCSESSION:
> ret = pipex_config_session(
> (struct pipex_session_config_req *)data, ownersc);
> Index: sys/net/pipex.h
> ===
> RCS file: /cvs/src/sys/net/pipex.h,v
> retrieving revision 1.28
> diff -u -p -r1.28 pipex.h
> --- sys/net/pipex.h 27 Aug 2020 10:47:52 - 1.28
> +++ sys/net/pipex.h 29 Dec 2020 23:51:59 -
> @@ -165,8 +165,6 @@ struct pipex_session_descr_req {
>
>
> /* PIPEX ioctls */
> -#define PIPEXSMODE _IOW ('p', 1, int)
> -#define PIPEXGMODE _IOR ('p', 2, int)
> #define PIPEXASESSION_IOW ('p', 3, struct pipex_session_req)
> #define PIPEXDSESSION_IOWR('p', 4, struct pipex_session_close_req)
> #define PIPEXCSESSION_IOW ('p', 5, struct pipex_session_config_req)
> Index: usr.sbin/npppd/npppd/npppd_iface.c
> ===
> RCS file: /cvs/src/usr.sbin/npppd/npppd/npppd_iface.c,v
> retrieving revision 1.13
> diff -u -p -r1.13 npppd_iface.c
> --- usr.sbin/npppd/npppd/npppd_iface.c5 Dec 2015 16:10:31 -
> 1.13
> +++ usr.sbin/npppd/npppd/npppd_iface.c29 Dec 2020 23:52:00 -
> @@ -96,11 +96,6 @@ static void npppd_iface_io_event_handle
> static int npppd_iface_log (npppd_iface *, int, const char *, ...)
> __printflike(3,4);
>
> -#ifdef USE_NPPPD_PIPEX
> -static int npppd_iface_pipex_enable(npppd_iface *_this);
> -static int npppd_iface_pipex_disable(npppd_iface *_this);
> -#endif /* USE_NPPPD_PIPEX */
> -
>
> /** initialize npppd_iface */
> void
> @@ -311,12 +306,7 @@ npppd_iface_start(npppd_iface *_this)
> goto fail;
> }
>
> -#ifdef USE_NPPPD_PIPEX
> - if (npppd_iface_pipex_enable(_this) != 0) {
> - log_printf(LOG_WARNING,
> - "npppd_iface_pipex_enable() failed: %m");
> - }
> -#else
> +#ifndef USE_NPPPD_PIPEX
> if (_this->using_pppx) {
> npppd_iface_log(_this, LOG_ERR,
> "pipex is required when using pppx interface");
> @@ -358,13 +348,6 @@ npppd_iface_stop(npppd_iface *_this)
> in_host_route_delete(&_this->ip4addr, );
> }
> if (_this->devf >= 0) {
> -#ifdef USE_NPPPD_PIPEX
> - if (npppd_iface_pipex_disable(_this) != 0) {
> - log_printf(LOG_CRIT,
> - "npppd_iface_pipex_disable() failed: %m");
> - }
> -#endif /* USE_NPPPD_PIPEX */
> -
> event_del(&_this->ev);
> close(_this->devf);
> npppd_iface_log(_this, LOG_INFO, "Stopped");
> @@ -381,32 +364,6 @@ npppd_iface_fini(npppd_iface *_this)
> NPPPD_IFACE_ASSERT(_this != NULL);
> _this->initialized = 0;
> }
> -
> -
> -/***
> - * PIPEX related functions
> - ***/
> -#ifdef USE_NPPPD_PIPEX
> -
> -/** enable PIPEX on PPPAC interface */
> -int
> -npppd_iface_pipex_enable(npppd_iface *_this)
> -{
> - int enable = 1;
> -
> - return ioctl(_this->devf, PIPEXSMODE, );
> -}
> -
> -/** disable PIPEX on PPPAC interface */
> -int
> -npppd_iface_pipex_disable(npppd_iface *_this)
> -{
> - int disable = 0;
> -
> -
Cache parent's pid as `ps_ppid' and use it instead of `ps_pptr->ps_pid'.
This allows us to unlock getppid(2). Also NetBSD, DragonflyBSD and OSX
do the same.
Index: kern/exec_elf.c
===
RCS file: /cvs/src/sys/kern/exec_elf.c,v
retrieving revision 1.156
diff -u -p -r1.156 exec_elf.c
--- kern/exec_elf.c 7 Dec 2020 16:55:28 - 1.156
+++ kern/exec_elf.c 2 Jan 2021 15:47:46 -
@@ -1257,7 +1257,7 @@ coredump_notes_elf(struct proc *p, void
cpi.cpi_sigcatch = pr->ps_sigacts->ps_sigcatch;
cpi.cpi_pid = pr->ps_pid;
- cpi.cpi_ppid = pr->ps_pptr->ps_pid;
+ cpi.cpi_ppid = pr->ps_ppid;
cpi.cpi_pgrp = pr->ps_pgid;
if (pr->ps_session->s_leader)
cpi.cpi_sid = pr->ps_session->s_leader->ps_pid;
Index: kern/kern_exit.c
===
RCS file: /cvs/src/sys/kern/kern_exit.c,v
retrieving revision 1.193
diff -u -p -r1.193 kern_exit.c
--- kern/kern_exit.c9 Dec 2020 18:58:19 - 1.193
+++ kern/kern_exit.c2 Jan 2021 15:47:46 -
@@ -694,6 +694,7 @@ process_reparent(struct process *child,
}
child->ps_pptr = parent;
+ child->ps_ppid = parent->ps_pid;
}
void
Index: kern/kern_fork.c
===
RCS file: /cvs/src/sys/kern/kern_fork.c,v
retrieving revision 1.230
diff -u -p -r1.230 kern_fork.c
--- kern/kern_fork.c7 Dec 2020 16:55:28 - 1.230
+++ kern/kern_fork.c2 Jan 2021 15:47:46 -
@@ -231,6 +231,7 @@ process_new(struct proc *p, struct proce
/* post-copy fixups */
pr->ps_pptr = parent;
+ pr->ps_ppid = parent->ps_pid;
/* bump references to the text vnode (for sysctl) */
pr->ps_textvp = parent->ps_textvp;
Index: kern/kern_prot.c
===
RCS file: /cvs/src/sys/kern/kern_prot.c,v
retrieving revision 1.76
diff -u -p -r1.76 kern_prot.c
--- kern/kern_prot.c9 Jul 2019 12:23:25 - 1.76
+++ kern/kern_prot.c2 Jan 2021 15:47:46 -
@@ -84,7 +84,7 @@ int
sys_getppid(struct proc *p, void *v, register_t *retval)
{
- *retval = p->p_p->ps_pptr->ps_pid;
+ *retval = p->p_p->ps_ppid;
return (0);
}
Index: kern/kern_sysctl.c
===
RCS file: /cvs/src/sys/kern/kern_sysctl.c,v
retrieving revision 1.385
diff -u -p -r1.385 kern_sysctl.c
--- kern/kern_sysctl.c 28 Dec 2020 18:28:11 - 1.385
+++ kern/kern_sysctl.c 2 Jan 2021 15:47:46 -
@@ -1666,7 +1666,7 @@ fill_kproc(struct process *pr, struct ki
/* stuff that's too painful to generalize into the macros */
if (pr->ps_pptr)
- ki->p_ppid = pr->ps_pptr->ps_pid;
+ ki->p_ppid = pr->ps_ppid;
if (s->s_leader)
ki->p_sid = s->s_leader->ps_pid;
Index: sys/proc.h
===
RCS file: /cvs/src/sys/sys/proc.h,v
retrieving revision 1.303
diff -u -p -r1.303 proc.h
--- sys/proc.h 9 Dec 2020 18:58:19 - 1.303
+++ sys/proc.h 2 Jan 2021 15:47:47 -
@@ -216,6 +216,7 @@ struct process {
u_int ps_xexit; /* Exit status for wait */
int ps_xsig;/* Stopping or killing signal */
+ pid_t ps_ppid;/* Cached parent pid */
pid_t ps_oppid; /* Save parent pid during ptrace. */
int ps_ptmask; /* Ptrace event mask */
struct ptrace_state *ps_ptstat;/* Ptrace state */
Re: ftp(1): add SOCKS proxy support
Nick Gasson wrote in <877dovsfjk@bertha.nickg.me.uk>: |On 11/27/20 05:59 AM, Steffen Nurpmeso wrote: |> Nick Gasson wrote in |> <87im9srza8@bertha.nickg.me.uk>: |>|Hi, |>| |>|I often need to go through a SOCKS proxy to access certain sites. The |>|diff below adds SOCKS5 support to ftp(1) for HTTP transfers, similar to |>|curl(1). Enabled when http_proxy is set to a socks5:// URL. |>| |>|Also fixes two existing memory leaks: proxyurl (set to NULL on line 646 |>|before freeing) and sslpath (never freed). |>| |>|Tested with ssh -D and a few other SOCKS5 proxies. Also verified the |>|existing HTTP proxy feature still works with squid(8). |> |> By the way, the $SOCKS5_PROXY environment variable becomes used |> for automatic selection of SOCKS5. (Some things on FreeBSD, |> lynx(1), and, hm, the MUA i maintain, s-nail; maybe more.) |> | |(Sorry for the late reply.) For me - no problem. | |Yes I see FreeBSD fetch added SOCKS5_PROXY recently. I've updated the |diff below to support that too. Anyone interested? Fine. That looks good to me as socks code in general, i do not use named constants because RFC 1928 CONNECT request is the reference, and all SOCKS code is in one function. I also output the errors as strings, for the codes you have to read RFC 1928 yourself, which is pain :) Btw. i see lots of problems with SOCKS5 proxy support of ssh on Linux, i proxy also firefox and we go over wireless on a bad link, and due to the massive parallelization this reaches a hundred concurrent sockets very fast when browsing German/Austrian/English newspapers .. and when ssh gets stuck then we hang 'till the muxer dies. Happens almost every day. 100 should not hit any Linux limit here. But that has nothing to do with OpenBSD and fetch. And you. A nice weekend and Ciao from Germany, --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: compress sparc64 bsd.rd
Miod Vallat wrote:
> Up until 6.5, sparc64 bsd.rd were gzipped kernels. This got lost during
> the Great Installation Media Unification of the 6.6 release cycle, and
> since then bsd.rd are uncompressed.
>
> The following diff ought to fix this and bring back sparc64 netboot
> times down to acceptable times.
Other architectures can use some tweaking also. This is now in snaps,
to see if anyone runs into a problem.
I've tried to be conservative, I believe all the remaining architectures
have at least one non-gzip boot-methods.
Index: distrib/alpha/miniroot/Makefile
===
RCS file: /cvs/src/distrib/alpha/miniroot/Makefile,v
retrieving revision 1.17
diff -u -p -u -r1.17 Makefile
--- distrib/alpha/miniroot/Makefile 18 May 2020 06:20:43 - 1.17
+++ distrib/alpha/miniroot/Makefile 31 Dec 2020 07:42:06 -
@@ -104,7 +104,7 @@ unconfig:
.ifdef RELEASEDIR
install:
- cp bsd.rd ${RELEASEDIR}/bsd.rd
+ cp bsd.gz ${RELEASEDIR}/bsd.rd
chmod a+r ${RELEASEDIR}/bsd.rd
cp ${FS} ${RELEASEDIR}
cp ${CDROM} ${RELEASEDIR}
Index: distrib/amd64/iso/Makefile
===
RCS file: /cvs/src/distrib/amd64/iso/Makefile,v
retrieving revision 1.39
diff -u -p -u -r1.39 Makefile
--- distrib/amd64/iso/Makefile 5 Aug 2020 04:23:30 - 1.39
+++ distrib/amd64/iso/Makefile 31 Dec 2020 22:52:06 -
@@ -25,7 +25,7 @@ TEMPLATE= ${.CURDIR}/template
all: ${FS} ${CDROM}
-${FS}: ${BASE} ${XBASE} bsd.gz
+${FS}: ${BASE} ${XBASE} bsd.rd
dd if=/dev/zero of=${FS} bs=512 count=${TOTALSIZE}
vnconfig -v ${FS} > vnd
fdisk -yi -l ${FSSIZE} -b ${MSDOSSIZE} -f ${DESTDIR}/usr/mdec/mbr `cat
vnd`
@@ -49,7 +49,7 @@ ${FS}: ${BASE} ${XBASE} bsd.gz
mkdir -p ${MOUNT_POINT}/${OSREV}/${MACHINE}
mkdir -p ${MOUNT_POINT}/etc
echo "set image /${OSREV}/${MACHINE}/bsd.rd" >
${MOUNT_POINT}/etc/boot.conf
- install -c -m 555 -o root -g wheel bsd.gz ${MOUNT_POINT}/bsd
+ install -c -m 555 -o root -g wheel bsd.rd ${MOUNT_POINT}/bsd
ln ${MOUNT_POINT}/bsd ${MOUNT_POINT}/bsd.rd
cp -p ${BASE} ${MOUNT_POINT}/${OSREV}/${MACHINE}
@@ -93,12 +93,6 @@ install:
clean cleandir:
rm -f ${CDROM} ${FS}
rm -rf cd-dir
-
-bsd.gz: bsd.rd
- cp bsd.rd bsd.strip
- strip bsd.strip
- strip -R .comment -R .SUNW_ctf bsd.strip
- gzip -9cn bsd.strip > bsd.gz
bsd.rd: ${BSDRD}
cp ${BSDRD} bsd.rd
Index: distrib/amd64/ramdisk_cd/Makefile
===
RCS file: /cvs/src/distrib/amd64/ramdisk_cd/Makefile,v
retrieving revision 1.23
diff -u -p -u -r1.23 Makefile
--- distrib/amd64/ramdisk_cd/Makefile 15 Sep 2020 11:44:51 - 1.23
+++ distrib/amd64/ramdisk_cd/Makefile 31 Dec 2020 22:52:13 -
@@ -99,7 +99,7 @@ unconfig:
.ifdef RELEASEDIR
install:
- cp bsd.rd ${RELEASEDIR}/bsd.rd
+ cp bsd.gz ${RELEASEDIR}/bsd.rd
chmod a+r ${RELEASEDIR}/bsd.rd
cp ${FS} ${RELEASEDIR}
cp ${CDROM} ${RELEASEDIR}
Index: distrib/i386/iso/Makefile
===
RCS file: /cvs/src/distrib/i386/iso/Makefile,v
retrieving revision 1.29
diff -u -p -u -r1.29 Makefile
--- distrib/i386/iso/Makefile 5 Aug 2020 04:23:30 - 1.29
+++ distrib/i386/iso/Makefile 31 Dec 2020 22:52:43 -
@@ -20,7 +20,7 @@ XBASE=${RELXDIR}/xbase${OSrev}.tgz ${R
all: ${FS} ${CDROM}
-${FS}: ${BASE} ${XBASE} bsd.gz
+${FS}: ${BASE} ${XBASE} bsd.rd
dd if=/dev/zero of=${FS} bs=512 count=${FSSIZE}
vnconfig -v ${FS} > vnd
fdisk -yi -l ${FSSIZE} -f ${DESTDIR}/usr/mdec/mbr `cat vnd`
@@ -31,7 +31,7 @@ ${FS}: ${BASE} ${XBASE} bsd.gz
strip -R .comment -R .SUNW_ctf ${MOUNT_POINT}/boot
installboot -v -r ${MOUNT_POINT} `cat vnd` \
${DESTDIR}/usr/mdec/biosboot ${MOUNT_POINT}/boot
- install -c -m 555 -o root -g wheel bsd.gz ${MOUNT_POINT}/bsd
+ install -c -m 555 -o root -g wheel bsd.rd ${MOUNT_POINT}/bsd
ln ${MOUNT_POINT}/bsd ${MOUNT_POINT}/bsd.rd
mkdir -p ${MOUNT_POINT}/${OSREV}/${MACHINE}
mkdir -p ${MOUNT_POINT}/etc
@@ -72,12 +72,6 @@ ${CDROM}: ${BASE} ${XBASE}
-V "OpenBSD/${MACHINE}${OSREV} Install CD" \
-b ${OSREV}/${MACHINE}/cdbr -c ${OSREV}/${MACHINE}/boot.catalog \
${.OBJDIR}/cd-dir
-
-bsd.gz: bsd.rd
- cp bsd.rd bsd.strip
- strip bsd.strip
- strip -R .comment -R .SUNW_ctf bsd.strip
- gzip -9cn bsd.strip > bsd.gz
bsd.rd: ${BSDRD}
cp ${BSDRD} bsd.rd
Index: distrib/i386/ramdisk_cd/Makefile
===
RCS file: /cvs/src/distrib/i386/ramdisk_cd/Makefile,v
retrieving revision 1.17
diff -u -p -u -r1.17 Makefile
--- distrib/i386/ramdisk_cd/Makefile18 May
libc/regex: turn unsafe macros to inline functions
That code was written before inline functions were supported by
compilers; now that they are even part of the language standard, turn
macros into inline functions so that there is no need to document in
comments that they will evaluate their arguments multiple times.
(one may consider switching their names to lowercase now that these are
no longer macros.)
Index: regex2.h
===
RCS file: /OpenBSD/src/lib/libc/regex/regex2.h,v
retrieving revision 1.10
diff -u -p -r1.10 regex2.h
--- regex2.h31 Dec 2020 17:20:19 - 1.10
+++ regex2.h2 Jan 2021 15:59:51 -
@@ -107,10 +107,24 @@ typedef struct {
uch mask; /* bit within array */
uch hash; /* hash code */
} cset;
-/* note that CHadd and CHsub are unsafe, and CHIN doesn't yield 0/1 */
-#defineCHadd(cs, c)((cs)->ptr[(uch)(c)] |= (cs)->mask, (cs)->hash
+= (c))
-#defineCHsub(cs, c)((cs)->ptr[(uch)(c)] &= ~(cs)->mask, (cs)->hash
-= (c))
-#defineCHIN(cs, c) ((cs)->ptr[(uch)(c)] & (cs)->mask)
+
+static inline void
+CHadd(cset *cs, char c)
+{
+ cs->ptr[(uch)c] |= cs->mask;
+ cs->hash += c;
+}
+static inline void
+CHsub(cset *cs, char c)
+{
+ cs->ptr[(uch)c] &= ~cs->mask;
+ cs->hash -= c;
+}
+static inline uch
+CHIN(const cset *cs, char c)
+{
+ return cs->ptr[(uch)c] & cs->mask;
+}
/*
* main compiled-expression structure
libc/regex: more dead code
The removal of the categories code made these two functions unused, so
remove them as well.
Index: regcomp.c
===
RCS file: /OpenBSD/src/lib/libc/regex/regcomp.c,v
retrieving revision 1.41
diff -u -p -r1.41 regcomp.c
--- regcomp.c 31 Dec 2020 17:24:05 - 1.41
+++ regcomp.c 2 Jan 2021 15:59:51 -
@@ -90,8 +90,6 @@ static void freeset(struct parse *, cset
static int freezeset(struct parse *, cset *);
static int firstch(struct parse *, cset *);
static int nch(struct parse *, cset *);
-static int isinsets(struct re_guts *, int);
-static int samesets(struct re_guts *, int, int);
static sopno dupl(struct parse *, sopno, sopno);
static void doemit(struct parse *, sop, size_t);
static void doinsert(struct parse *, sop, size_t, sopno);
@@ -1148,41 +1146,6 @@ nch(struct parse *p, cset *cs)
}
/*
- - isinsets - is this character in any sets?
- */
-static int /* predicate */
-isinsets(struct re_guts *g, int c)
-{
- uch *col;
- int i;
- int ncols = (g->ncsets+(CHAR_BIT-1)) / CHAR_BIT;
- unsigned uc = (uch)c;
-
- for (i = 0, col = g->setbits; i < ncols; i++, col += g->csetsize)
- if (col[uc] != 0)
- return(1);
- return(0);
-}
-
-/*
- - samesets - are these two characters in exactly the same sets?
- */
-static int /* predicate */
-samesets(struct re_guts *g, int c1, int c2)
-{
- uch *col;
- int i;
- int ncols = (g->ncsets+(CHAR_BIT-1)) / CHAR_BIT;
- unsigned uc1 = (uch)c1;
- unsigned uc2 = (uch)c2;
-
- for (i = 0, col = g->setbits; i < ncols; i++, col += g->csetsize)
- if (col[uc1] != col[uc2])
- return(0);
- return(1);
-}
-
-/*
- dupl - emit a duplicate of a bunch of sops
*/
static sopno /* start of duplicate */
@@ -1394,7 +1357,7 @@ findmust(struct parse *p, struct re_guts
*cp++ = (char)OPND(s);
}
assert(cp == g->must + g->mlen);
- *cp++ = '\0'; /* just on general principles */
+ *cp = '\0'; /* just on general principles */
}
/*
Re: libc/regex: more dead code
On Sat, Jan 02, 2021 at 08:31:39PM +, Miod Vallat wrote: > The removal of the categories code made these two functions unused, so > remove them as well. ok tb
Re: libc/regex: turn unsafe macros to inline functions
On Sat, 02 Jan 2021 20:33:51 +, Miod Vallat wrote: > That code was written before inline functions were supported by > compilers; now that they are even part of the language standard, turn > macros into inline functions so that there is no need to document in > comments that they will evaluate their arguments multiple times. OK millert@ > (one may consider switching their names to lowercase now that these are > no longer macros.) I don't think the churn is worth it and it would result in an unnecesary difference from FreeBSD. - todd
Re: libc/regex: turn unsafe macros to inline functions
On Sat, Jan 02, 2021 at 08:33:51PM +, Miod Vallat wrote:
> That code was written before inline functions were supported by
> compilers; now that they are even part of the language standard, turn
> macros into inline functions so that there is no need to document in
> comments that they will evaluate their arguments multiple times.
>
ok tb
Minor comments inline
> (one may consider switching their names to lowercase now that these are
> no longer macros.)
No opinion.
>
> Index: regex2.h
> ===
> RCS file: /OpenBSD/src/lib/libc/regex/regex2.h,v
> retrieving revision 1.10
> diff -u -p -r1.10 regex2.h
> --- regex2.h 31 Dec 2020 17:20:19 - 1.10
> +++ regex2.h 2 Jan 2021 15:59:51 -
> @@ -107,10 +107,24 @@ typedef struct {
> uch mask; /* bit within array */
> uch hash; /* hash code */
> } cset;
> -/* note that CHadd and CHsub are unsafe, and CHIN doesn't yield 0/1 */
> -#define CHadd(cs, c)((cs)->ptr[(uch)(c)] |= (cs)->mask, (cs)->hash
> += (c))
> -#define CHsub(cs, c)((cs)->ptr[(uch)(c)] &= ~(cs)->mask, (cs)->hash
> -= (c))
> -#define CHIN(cs, c) ((cs)->ptr[(uch)(c)] & (cs)->mask)
> +
> +static inline void
> +CHadd(cset *cs, char c)
> +{
> + cs->ptr[(uch)c] |= cs->mask;
> + cs->hash += c;
> +}
I would put a blank line here
> +static inline void
> +CHsub(cset *cs, char c)
> +{
> + cs->ptr[(uch)c] &= ~cs->mask;
> + cs->hash -= c;
> +}
and here.
> +static inline uch
> +CHIN(const cset *cs, char c)
> +{
> + return cs->ptr[(uch)c] & cs->mask;
Is there a reason not to do
return (cs->ptr[(uch)c] & cs->mask) != 0;
This would allow us to get rid of the !! construct in regcomp.c
> +}
>
> /*
> * main compiled-expression structure
>
Re: pf route-to issues
On Tue, Oct 20, 2020 at 09:27:09AM +1000, David Gwynne wrote:
>
> i am feeling very warm and fuzzy about this diff at the moment.
We've been running this diff in production for the last couple of
months, and it's been solid for us so far. Ignoring the fixes for
crashes, I personally find it a lot more usable than the current
route-to rules too.
Can I commit it?
Index: sbin/pfctl/parse.y
===
RCS file: /cvs/src/sbin/pfctl/parse.y,v
retrieving revision 1.707
diff -u -p -r1.707 parse.y
--- sbin/pfctl/parse.y 16 Dec 2020 18:01:16 - 1.707
+++ sbin/pfctl/parse.y 3 Jan 2021 03:53:02 -
@@ -276,6 +276,7 @@ struct filter_opts {
struct redirspec nat;
struct redirspec rdr;
struct redirspec rroute;
+ u_int8_t rt;
/* scrub opts */
int nodf;
@@ -284,15 +285,6 @@ struct filter_opts {
int randomid;
int max_mss;
- /* route opts */
- struct {
- struct node_host*host;
- u_int8_t rt;
- u_int8_t pool_opts;
- sa_family_t af;
- struct pf_poolhashkey *key;
- }route;
-
struct {
u_int32_t limit;
u_int32_t seconds;
@@ -518,7 +510,6 @@ int parseport(char *, struct range *r, i
%type ipspec xhost host dynaddr host_list
%type table_host_list tablespec
%type redir_host_list redirspec
-%type route_host route_host_list routespec
%typeos xos os_list
%type portspec port_list port_item
%type uids uid_list uid_item
@@ -975,7 +966,7 @@ anchorrule : ANCHOR anchorname dir quick
YYERROR;
}
- if ($9.route.rt) {
+ if ($9.rt) {
yyerror("cannot specify route handling "
"on anchors");
YYERROR;
@@ -1843,37 +1834,13 @@ pfrule : action dir logquick interface
decide_address_family($7.src.host, );
decide_address_family($7.dst.host, );
- if ($8.route.rt) {
- if (!r.direction) {
+ if ($8.rt) {
+ if ($8.rt != PF_DUPTO && !r.direction) {
yyerror("direction must be explicit "
"with rules that specify routing");
YYERROR;
}
- r.rt = $8.route.rt;
- r.route.opts = $8.route.pool_opts;
- if ($8.route.key != NULL)
- memcpy(, $8.route.key,
- sizeof(struct pf_poolhashkey));
- }
- if (r.rt) {
- decide_address_family($8.route.host, );
- if ((r.route.opts & PF_POOL_TYPEMASK) ==
- PF_POOL_NONE && ($8.route.host->next !=
NULL ||
- $8.route.host->addr.type == PF_ADDR_TABLE ||
- DYNIF_MULTIADDR($8.route.host->addr)))
- r.route.opts |= PF_POOL_ROUNDROBIN;
- if ($8.route.host->next != NULL) {
- if (!PF_POOL_DYNTYPE(r.route.opts)) {
- yyerror("address pool option "
- "not supported by type");
- YYERROR;
- }
- }
- /* fake redirspec */
- if (($8.rroute.rdr = calloc(1,
- sizeof(*$8.rroute.rdr))) == NULL)
- err(1, "$8.rroute.rdr");
- $8.rroute.rdr->host = $8.route.host;
+ r.rt = $8.rt;
}
if (expand_divertspec(, &$8.divert))
@@ -2137,30 +2104,14 @@ filter_opt : USER uids {
sizeof(filter_opts.nat.pool_opts));
filter_opts.nat.pool_opts.staticport = 1;
}
- | ROUTETO routespec pool_opts {
- filter_opts.route.host = $2;
- filter_opts.route.rt =
Re: acme-client(1): backup certs
On Sat, Jan 02, 2021 at 05:23:11PM +0100, Florian Obser wrote: > > Create .1 backup files when acme-client is going to overwrite a > certificate file. > > This files are not terribly big and it's convenient to keep one > previous file around for example if one adds or removes domains to the > certificate and then wants to revoke the previous one. > > (Note that it's kinda difficult to revoke the old certificate with > acme-client currently. The whole revoke machinery needs to be > overhauled. I have ideas...) > > Comments, OKs? > Wait, I can have multiple, active certificates? One's that are in fact different, such as domain.xxx and then add www.domain.xxx in another certificate? If that's the case, then couldn't someone steal the old or new one and use that to cause problems? Especially since DNS servers can take up to 48 hours to propagate changes So getting rid of www.domain.xxx might not show up quickly enough. And if I change IP addresses and they don't get propagated soon enough, wouldn't someone be able to briefly spoof my site? DNS servers in some places I have been to, do in fact have failures. If I understand this correctly (perhaps not), this seems like a major security problem with DNS. Especially if my spoofed site sends people to another site that they then bookmark. Chris Bennett
use stoeplitz to set flowids on tcp connections
if stoeplitz is enabled by a driver (eg, ix, mcx, etc), this uses it in
the tcp code to set the flowid on packets. this encourages both the tx
and rx side of a tcp connection to get processed in the same places.
ok?
Index: netinet/in_pcb.c
===
RCS file: /cvs/src/sys/netinet/in_pcb.c,v
retrieving revision 1.252
diff -u -p -r1.252 in_pcb.c
--- netinet/in_pcb.c7 Nov 2020 09:51:40 - 1.252
+++ netinet/in_pcb.c3 Jan 2021 02:12:45 -
@@ -95,6 +95,11 @@
#include
#endif /* IPSEC */
+#include "stoeplitz.h"
+#if NSTOEPLITZ > 0
+#include
+#endif
+
const struct in_addr zeroin_addr;
union {
@@ -516,6 +521,10 @@ in_pcbconnect(struct inpcb *inp, struct
inp->inp_faddr = sin->sin_addr;
inp->inp_fport = sin->sin_port;
in_pcbrehash(inp);
+#if NSTOEPLITZ > 0
+ inp->inp_flowid = stoeplitz_ip4port(inp->inp_laddr.s_addr,
+ inp->inp_faddr.s_addr, inp->inp_lport, inp->inp_fport);
+#endif
#ifdef IPSEC
{
/* Cause an IPsec SA to be established. */
@@ -549,6 +558,7 @@ in_pcbdisconnect(struct inpcb *inp)
}
inp->inp_fport = 0;
+ inp->inp_flowid = 0;
in_pcbrehash(inp);
if (inp->inp_socket->so_state & SS_NOFDREF)
in_pcbdetach(inp);
Index: netinet/in_pcb.h
===
RCS file: /cvs/src/sys/netinet/in_pcb.h,v
retrieving revision 1.120
diff -u -p -r1.120 in_pcb.h
--- netinet/in_pcb.h21 Jun 2020 05:14:04 - 1.120
+++ netinet/in_pcb.h3 Jan 2021 02:12:45 -
@@ -148,6 +148,7 @@ struct inpcb {
void*inp_upcall_arg;
u_int inp_rtableid;
int inp_pipex; /* pipex indication */
+ uint16_t inp_flowid;
};
LIST_HEAD(inpcbhead, inpcb);
Index: netinet/tcp_output.c
===
RCS file: /cvs/src/sys/netinet/tcp_output.c,v
retrieving revision 1.128
diff -u -p -r1.128 tcp_output.c
--- netinet/tcp_output.c10 Nov 2018 18:40:34 - 1.128
+++ netinet/tcp_output.c3 Jan 2021 02:12:45 -
@@ -69,6 +69,7 @@
*/
#include "pf.h"
+#include "stoeplitz.h"
#include
#include
@@ -1037,6 +1038,10 @@ send:
ip->ip_tos |= IPTOS_ECN_ECT0;
#endif
}
+#if NSTOEPLITZ > 0
+ m->m_pkthdr.ph_flowid = tp->t_inpcb->inp_flowid;
+ SET(m->m_pkthdr.csum_flags, M_FLOWID);
+#endif
error = ip_output(m, tp->t_inpcb->inp_options,
>t_inpcb->inp_route,
(ip_mtudisc ? IP_MTUDISC : 0), NULL, tp->t_inpcb, 0);
Index: netinet6/in6_pcb.c
===
RCS file: /cvs/src/sys/netinet6/in6_pcb.c,v
retrieving revision 1.110
diff -u -p -r1.110 in6_pcb.c
--- netinet6/in6_pcb.c 29 Nov 2019 16:41:01 - 1.110
+++ netinet6/in6_pcb.c 3 Jan 2021 02:12:45 -
@@ -100,6 +100,7 @@
*/
#include "pf.h"
+#include "stoeplitz.h"
#include
#include
@@ -119,6 +120,10 @@
#include
+#if NSTOEPLITZ > 0
+#include
+#endif
+
const struct in6_addr zeroin6_addr;
struct inpcbhead *
@@ -297,6 +302,10 @@ in6_pcbconnect(struct inpcb *inp, struct
if (ip6_auto_flowlabel)
inp->inp_flowinfo |=
(htonl(ip6_randomflowlabel()) & IPV6_FLOWLABEL_MASK);
+#if NSTOEPLITZ > 0
+ inp->inp_flowid = stoeplitz_ip6port(>inp_laddr6,
+ >inp_faddr6, inp->inp_lport, inp->inp_fport);
+#endif
in_pcbrehash(inp);
return (0);
}
Re: acme-client(1): backup certs
On Sat, Jan 02, 2021 at 05:10:01PM -0600, Chris Bennett wrote: > On Sat, Jan 02, 2021 at 05:23:11PM +0100, Florian Obser wrote: > > > > Create .1 backup files when acme-client is going to overwrite a > > certificate file. > > > > This files are not terribly big and it's convenient to keep one > > previous file around for example if one adds or removes domains to the > > certificate and then wants to revoke the previous one. > > > > (Note that it's kinda difficult to revoke the old certificate with > > acme-client currently. The whole revoke machinery needs to be > > overhauled. I have ideas...) > > > > Comments, OKs? > > > > Wait, I can have multiple, active certificates? One's that are in fact > different, such as domain.xxx and then add www.domain.xxx in another > certificate? > > If that's the case, then couldn't someone steal the old or new one and > use that to cause problems? > Especially since DNS servers can take up to 48 hours to propagate changes > So getting rid of www.domain.xxx might not show up quickly enough. > And if I change IP addresses and they don't get propagated soon enough, > wouldn't someone be able to briefly spoof my site? > DNS servers in some places I have been to, do in fact have failures. > > If I understand this correctly (perhaps not), this seems like a major > security problem with DNS. Especially if my spoofed site sends people to > another site that they then bookmark. Hi, Yes you can have multiple certs, I have a few. The spoofing couldn't happen if you used DNSSEC. However if you used DNSSEC that means you have to keep your keys on the DNS Server, in order to sign the domain with acme-client info, which you have to be comfortable with. If they get stolen, then you have to change the keys and your domains will be temporarely insecure and subject to spoofing again. Regarding to the "propagation time" you should keep your TTL's low in that case, I think. That is not always wanted. Luckily you have the choice to use the DNS vs. the HTTP method. I think it's good you went into a deep thought about this, as it makes everyone think how to refine the process of getting let's encrypt certs. > Chris Bennett Best Regards, -peter
