Fix busy-looping in netcat's TLS handshaking

[Shuo Chen]

When doing TLS handshaking, netcat does it in a busy-looping way,
because the socket fd is set to non-blocking.

do {
if ((i = tls_handshake(tls_ctx)) == -1)
errx(1, "tls handshake failed (%s)",
tls_error(tls_ctx));
} while (i == TLS_WANT_POLLIN || i == TLS_WANT_POLLOUT);

strace(1) shows many lines like this:

04:20:25.566148 read(4, 0x15cae23, 5)   = -1 EAGAIN (Resource
temporarily unavailable)
04:20:25.566214 read(4, 0x15cae23, 5)   = -1 EAGAIN (Resource
temporarily unavailable)
04:20:25.566280 read(4, 0x15cae23, 5)   = -1 EAGAIN (Resource
temporarily unavailable)
04:20:25.566343 read(4, 0x15cae23, 5)   = -1 EAGAIN (Resource
temporarily unavailable)
04:20:25.566409 read(4, 0x15cae23, 5)   = -1 EAGAIN (Resource
temporarily unavailable)
04:20:25.566475 read(4, 0x15cae23, 5)   = -1 EAGAIN (Resource
temporarily unavailable)

I added a handshake() function and replaced busy-looping with poll()ing.

Regards,
Shuo Chen



diff --git a/src/usr.bin/nc/netcat.c b/src/usr.bin/nc/netcat.c
--- a/src/usr.bin/nc/netcat.c
+++ b/src/usr.bin/nc/netcat.c
@@ -713,21 +713,41 @@ unix_bind(char *path, int flags)
return (s);
 }
 
+int
+handshake(int sockfd, struct tls *tls_ctx)
+{
+   struct pollfd pfd;
+   int ret;
+
+   bzero(, sizeof(pfd));
+   pfd.fd = sockfd;
+   while ((ret = tls_handshake(tls_ctx)) != 0) {
+   if (ret == -1)
+   break;
+   pfd.events = 0;
+   if (ret == TLS_WANT_POLLIN)
+   pfd.events = POLLIN;
+   else if (ret == TLS_WANT_POLLOUT)
+   pfd.events = POLLOUT;
+   if (pfd.events == 0)
+   err(1, "no events");
+   else if (poll(, 1, -1) == -1)
+   err(1, "poll");
+   }
+   return (ret);
+}
+
 void
 tls_setup_client(struct tls *tls_ctx, int s, char *host)
 {
-   int i;
-
if (tls_connect_socket(tls_ctx, s,
tls_expectname ? tls_expectname : host) == -1) {
errx(1, "tls connection failed (%s)",
tls_error(tls_ctx));
}
-   do {
-   if ((i = tls_handshake(tls_ctx)) == -1)
-   errx(1, "tls handshake failed (%s)",
-   tls_error(tls_ctx));
-   } while (i == TLS_WANT_POLLIN || i == TLS_WANT_POLLOUT);
+   if (handshake(s, tls_ctx) == -1)
+   errx(1, "tls handshake failed (%s)",
+   tls_error(tls_ctx));
if (vflag)
report_tls(tls_ctx, host, tls_expectname);
if (tls_expecthash && tls_peer_cert_hash(tls_ctx) &&
@@ -745,14 +765,9 @@ tls_setup_server(struct tls *tls_ctx, int
warnx("tls accept failed (%s)",
tls_error(tls_ctx));
tls_cctx = NULL;
-   } else {
-   int i;
-
-   do {
-   if ((i = tls_handshake(tls_cctx)) == -1)
-   warnx("tls handshake failed (%s)",
-   tls_error(tls_cctx));
-   } while(i == TLS_WANT_POLLIN || i == TLS_WANT_POLLOUT);
+   } else if (handshake(connfd, tls_cctx) == -1) {
+   warnx("tls handshake failed (%s)",
+   tls_error(tls_cctx));
}
if (tls_cctx) {
int gotcert = tls_peer_cert_provided(tls_cctx);

Move auth_approval in su.c before fork is lost due to pledge?

[Andy Bradford]

Hello,

I noticed that my locate.database wasn't being updated:

Rebuilding locate database:
Abort trap 
Not installing locate database; zero size

>From the following:

echo "${UPDATEDB} --fcodes=- --tmpdir=${TMPDIR:-/tmp}" | \
nice -5 su -m nobody 2>/dev/null 1>$TMP

As  it   turns  out,  it  is   because  I  have  an   approve  entry  in
/etc/login.conf  and this  requires  the ability  to  fork the  approval
program. When su tries to run approve  it fails and I find the following
in dmesg:

su(77960): syscall 2 "proc"

ktrace also  shows that pledge shut  it down. So is  the following patch
correct? I  don't see any downsides,  but perhaps there reasons  for why
auth_approval happens last?

Index: su.c
===
RCS file: /home/cvs/src/usr.bin/su/su.c,v
retrieving revision 1.70
diff -u -p -r1.70 su.c
--- su.c30 Oct 2015 19:45:03 -  1.70
+++ su.c8 Jan 2017 04:07:14 -
@@ -215,6 +215,9 @@ main(int argc, char **argv)
fprintf(stderr, "Login incorrect\n");
}
 
+   if (pwd->pw_uid && auth_approval(as, lc, pwd->pw_name, "su") <= 0)
+   auth_err(as, 1, "approval failure");
+
if (pledge("stdio rpath getpw exec id", NULL) == -1)
err(1, "pledge");
 
@@ -332,9 +335,6 @@ main(int argc, char **argv)
 
if (pledge("stdio rpath exec", NULL) == -1)
err(1, "pledge");
-
-   if (pwd->pw_uid && auth_approval(as, lc, pwd->pw_name, "su") <= 0)
-   auth_err(as, 1, "approval failure");
auth_close(as);
 
execv(shell, np);


Thanks,

Andy
-- 
TAI64 timestamp: 40005871bcbe

Re: E5v4 pciids

[Mike Larkin]

On Thu, Dec 15, 2016 at 10:46:39AM +0100, Hrvoje Popovski wrote:
> Hi all,
> 
> patch in attachment adds some E5v4 pciids that i'm seeing in supermicro
> 1018R-WR box with E5-1650 v4.
> 

Thanks, committed.

Re: Allow install from https server w/ self signed cert

[Theo de Raadt]

> On Sat, Jan 07, 2017 at 03:52:04PM -0700, Theo de Raadt wrote:
> > > What workarounds would be reasonable and approriate? and does it
> > > make sense for OpenBSD to support such scenarios out-of-the-box to
> > > promote wider adoption of better software?
> > 
> > If you want buy the OpenBSD-installer-for-drones, contact me offline.
> > That featureset didn't make it into the free software version.
> 
> 
> But out GeoLocation shit in the installer will just find that it's
> located on a netblock that is registered 5000 feet over Pakistan and
> direct it to a local public mirror!  Definately have to disable
> that feature from the free software version.

https://en.wikipedia.org/wiki/Iran%E2%80%93U.S._RQ-170_incident

Re: Allow install from https server w/ self signed cert

[Bob Beck]

On Sat, Jan 07, 2017 at 03:52:04PM -0700, Theo de Raadt wrote:
> > What workarounds would be reasonable and approriate? and does it
> > make sense for OpenBSD to support such scenarios out-of-the-box to
> > promote wider adoption of better software?
> 
> If you want buy the OpenBSD-installer-for-drones, contact me offline.
> That featureset didn't make it into the free software version.


But out GeoLocation shit in the installer will just find that it's
located on a netblock that is registered 5000 feet over Pakistan and
direct it to a local public mirror!  Definately have to disable
that feature from the free software version.

Re: Allow install from https server w/ self signed cert

[Theo de Raadt]

> What workarounds would be reasonable and approriate? and does it
> make sense for OpenBSD to support such scenarios out-of-the-box to
> promote wider adoption of better software?

If you want buy the OpenBSD-installer-for-drones, contact me offline.
That featureset didn't make it into the free software version.

Re: Allow install from https server w/ self signed cert

[Theo de Raadt]

> > And we should also ask a firmware question?
> > 
> > Nope.  I don't think we should bend over backwards for people doing
> > strange things.  They are on their own.
> > 
> 
> Most of the time I agree with this particular attitude and it is indeed 
> appropriate for the OP case. However, there some major networks such as 
> various governments (or for example .mil) that do not participate in 
> the public PKI but run their own PKI infrastructure. What effect will 
> the installer's checks have in that environment? What workarounds would 
> be reasonable and approriate? and does it make sense for OpenBSD to 
> support such scenarios out-of-the-box to promote wider adoption of 
> better software?

The installer falls back to http.

Just like it worked in 6.0 and all previous releases.

So there is no problem.  If you don't participate in the publically
available cert model for https, it asks for a question and you fall
back to http and continue on.

We are following the same roadmap the browsers followed.

Let me point out that our install script caters poorly to the Zulu
speaking population.  Also to the french.

Not all minority featuresets can be supported.  Please stop dismissing
20 years of effort to create an install media which supports so many
many usage cases -- by insisting on the addition of more usage cases.
It is amazing so much good and complex behaviours come out of such a
small package; those who have dug into the guts of the install media
understand.

Essentially, you are making an enemy of good argument.

And frankly, you say .mil?  Good grief, that's unacceptable, our stuff
is post-FIPS.

Re: Allow install from https server w/ self signed cert

[Bob Beck]

On Sat, Jan 07, 2017 at 05:42:24PM -0500, Jacob L. Leifman wrote:

> Most of the time I agree with this particular attitude and it is indeed 
> appropriate for the OP case. However, there some major networks such as 
> various governments (or for example .mil) that do not participate in 
> the public PKI but run their own PKI infrastructure. What effect will 
> the installer's checks have in that environment? What workarounds would 
> be reasonable and approriate? and does it make sense for OpenBSD to 
> support such scenarios out-of-the-box to promote wider adoption of 
> better software?

That's not a good reason, since in the case of what I am describing they
would *still be depending on the public PKI infrastrucure* to publish
their own list of signers..  No.. they aren't going to do that.. Sorry, 
Unless you're mailing me from a .mil address I think you might
be imagining this usage case. 

they're probably building from source, or have the wherewithall to roll
their own bsd.rd if they care about doing this. 

Re: Allow install from https server w/ self signed cert

[Jacob L. Leifman]

On 7 Jan 2017 at 15:28, Theo de Raadt wrote:

> > On Fri, Jan 06, 2017 at 10:48:37AM -0500, RD Thrush wrote:
> > > On 01/06/17 06:28, Stuart Henderson wrote:
> > > > Related to this (and particularly thinking about autoinstalls),
> > > > would it make sense to allow explicit protocols in the hostname?
> > > > 
> > > > some.host -> https with http fallback
> > > > http://some.host/ -> http only
> > > > https://some.host/ -> https only, no fallback
> > > 
> > > That would totally work for my install problem.
> > > 
> > > FWIW, instead of running a patched install.sub, "rm
> > > /etc/ssl/cert.pem" makes the install bypass the https attempt.
> > > 
> > 
> > Note, if you're upgrading or otherwise have a way to et a cert.pem
> > bundle onto there to *replace* the default, you could always drop the
> > signer for your private self-signed server into the cert.pem bundle,
> > at which point it would be accepted as trusted. 
> > 
> > of course if you're just installing you have an interesting chicken
> > and egg problem, unless you put it somewhere on an https site that
> > does have a real certificate, drop out of the installer and do
> > 
> > ftp -o /tmp/mysigner.pem https://my.secure.site/mysigner.pem
> > cat /tmp/mysigner.pem >> /etc/ssl/cert.pem
> > 
> > then continue the install, and you're good. 
> > 
> > Almost wonder if it's worth an extra question in the installer to ask
> > for an https address to retrieve a certficiate bundle to be appended
> > to cert.pem for the install...
> 
> And we should also ask a firmware question?
> 
> Nope.  I don't think we should bend over backwards for people doing
> strange things.  They are on their own.
> 

Most of the time I agree with this particular attitude and it is indeed 
appropriate for the OP case. However, there some major networks such as 
various governments (or for example .mil) that do not participate in 
the public PKI but run their own PKI infrastructure. What effect will 
the installer's checks have in that environment? What workarounds would 
be reasonable and approriate? and does it make sense for OpenBSD to 
support such scenarios out-of-the-box to promote wider adoption of 
better software?

Re: Allow install from https server w/ self signed cert

[Theo de Raadt]

> On Fri, Jan 06, 2017 at 10:48:37AM -0500, RD Thrush wrote:
> > On 01/06/17 06:28, Stuart Henderson wrote:
> > > Related to this (and particularly thinking about autoinstalls),
> > > would it make sense to allow explicit protocols in the hostname?
> > > 
> > > some.host -> https with http fallback
> > > http://some.host/ -> http only
> > > https://some.host/ -> https only, no fallback
> > 
> > That would totally work for my install problem.
> > 
> > FWIW, instead of running a patched install.sub, "rm /etc/ssl/cert.pem" 
> > makes the install bypass the https attempt.
> > 
> 
> Note, if you're upgrading or otherwise have a way to et a cert.pem bundle 
> onto there to *replace*
> the default, you could always drop the signer for your private self-signed 
> server into the cert.pem
> bundle, at which point it would be accepted as trusted. 
> 
> of course if you're just installing you have an interesting chicken and egg 
> problem, unless
> you put it somewhere on an https site that does have a real certificate, drop 
> out of the
> installer and do
> 
> ftp -o /tmp/mysigner.pem https://my.secure.site/mysigner.pem
> cat /tmp/mysigner.pem >> /etc/ssl/cert.pem
> 
> then continue the install, and you're good. 
> 
> Almost wonder if it's worth an extra question in the installer to ask
> for an https address to retrieve a certficiate bundle to be appended to 
> cert.pem
> for the install...

And we should also ask a firmware question?

Nope.  I don't think we should bend over backwards for people doing strange
things.  They are on their own.

Re: Allow install from https server w/ self signed cert

[RD Thrush]

On 01/07/17 16:13, Bob Beck wrote:
> 
> On Fri, Jan 06, 2017 at 10:48:37AM -0500, RD Thrush wrote:
>> On 01/06/17 06:28, Stuart Henderson wrote:
>>> Related to this (and particularly thinking about autoinstalls),
>>> would it make sense to allow explicit protocols in the hostname?
>>>
>>> some.host -> https with http fallback
>>> http://some.host/ -> http only
>>> https://some.host/ -> https only, no fallback
>>
>> That would totally work for my install problem.
>>
>> FWIW, instead of running a patched install.sub, "rm /etc/ssl/cert.pem" makes 
>> the install bypass the https attempt.
>>
> 
> Note, if you're upgrading or otherwise have a way to et a cert.pem bundle 
> onto there to *replace*
> the default, you could always drop the signer for your private self-signed 
> server into the cert.pem
> bundle, at which point it would be accepted as trusted.

In an ideal world, I'd have a valid certificate for this local nas server...


> of course if you're just installing you have an interesting chicken and egg 
> problem, unless
> you put it somewhere on an https site that does have a real certificate, drop 
> out of the
> installer and do
> 
> ftp -o /tmp/mysigner.pem https://my.secure.site/mysigner.pem
> cat /tmp/mysigner.pem >> /etc/ssl/cert.pem
> 
> then continue the install, and you're good.

Thanks.  Unfortunately, I've been spoiled by the continually improving snapshot 
install methods and want to preserve typing "a" once for a new -current.


> Almost wonder if it's worth an extra question in the installer to ask
> for an https address to retrieve a certficiate bundle to be appended to 
> cert.pem
> for the install...

That would also solve the self signed cert problem.  Since the install 
/etc/ssl/cert.pem is transient, your method wouldn't trigger any /etc/daily 
alarm about a chang in cert.pem.

I hacked a bit on sthen's suggestion but ran into problems testing the https 
part w/ the OpenBSD servers.  I'm currently unable to do a snapshot autoinstall 
from ftp[35] via the latest bsd.rd.

FWIW, here's my weak attempt at sthen's suggestion:
Index: install.sub
===
RCS file: /cvs/src/distrib/miniroot/install.sub,v
retrieving revision 1.942
diff -u -p -u -p -r1.942 install.sub
--- install.sub 4 Jan 2017 13:47:29 -   1.942
+++ install.sub 7 Jan 2017 22:02:52 -
@@ -1502,9 +1502,11 @@ install_files() {
 
 # Get several parameters from the user, and xfer files from the http server.
 install_http() {
+   local _proto=$1
local _file_list _prompt _mirror _url_base _err _idx=/tmp/i/index.txt
local _idx_url _rc
 
+   HTTP_PROTO=$_proto
# N.B.: 'http_proxy' is an environment variable used by ftp(1). DON'T
# change the name or case!
ask "HTTP proxy URL? (e.g. 'http://proxy:8080', or 'none')" \
@@ -1568,8 +1570,9 @@ install_http() {
# Get list of files from the server.
# Assumes index file is "index.txt" for http (or proxy).
# We can't use index.html since the format is server-dependent.
-   # If ftp(1) has tls, fetch index.txt via https. If that fails
-   # tell the user about it and switch to http.
+   # If ftp(1) has tls and doesn't explicitly request http,
+   # fetch index.txt via https. If https fails tell the user about
+   # it and switch to http.
rm -f $_idx
if $FTP_TLS; then
_idx_url=$_url_base/index.txt
@@ -2310,7 +2313,7 @@ feed_random() {
 # selects from that location. Repeat as many times as the user needs to get all
 # desired sets.
 install_sets() {
-   local _cddevs=$(get_cddevs) _d=$CGI_METHOD _im _locs="disk http" _src
+   local _cddevs=$(get_cddevs) _d=$CGI_METHOD _im _locs="disk http https" 
_src
 
echo
 
@@ -2343,7 +2346,9 @@ install_sets() {
;;
[dD]*)  install_disk && INSTALL_METHOD=disk
;;
-   [hH]*)  isin http $_locs && install_http && INSTALL_METHOD=http
+   [hH]*s) isin https $_locs && install_http https && 
INSTALL_METHOD=https
+   ;;
+   [hH]*)  isin http $_locs && install_http http && 
INSTALL_METHOD=http
;;
[nN]*)  isin nfs $_locs && install_nfs && INSTALL_METHOD=nfs
;;

Re: rasops(9): Use proper RGB values for the ANSI color palette

[Mark Kettenis]

> Date: Sat, 7 Jan 2017 12:20:06 +
> From: Visa Hankala 
> 
> On Sat, Jan 07, 2017 at 12:23:31AM +0100, Frederic Cambus wrote:
> > Hi tech@,
> > 
> > Here is a diff to use proper RGB values for the ANSI color palette in
> > rasops(9).
> > 
> > Comments? OK?
> 
> I prefer the old palette because its contrast is higher.

Right.  I don't see why we should change this.  On top of that, on
sparc64 the colors are carefully matched to what OpenFirmware uses for
the console.  So changing white will make things look ugly.

> > Index: sys/dev/rasops/rasops.c
> > ===
> > RCS file: /cvs/src/sys/dev/rasops/rasops.c,v
> > retrieving revision 1.44
> > diff -u -p -r1.44 rasops.c
> > --- sys/dev/rasops/rasops.c 15 Dec 2016 19:18:41 -  1.44
> > +++ sys/dev/rasops/rasops.c 6 Jan 2017 22:11:02 -
> > @@ -48,21 +48,21 @@
> >  /* ANSI colormap (R,G,B) */
> >  
> >  #defineNORMAL_BLACK0x00
> > -#defineNORMAL_RED  0x7f
> > -#defineNORMAL_GREEN0x007f00
> > -#defineNORMAL_BROWN0x7f7f00
> > -#defineNORMAL_BLUE 0x7f
> > -#defineNORMAL_MAGENTA  0x7f007f
> > -#defineNORMAL_CYAN 0x007f7f
> > -#defineNORMAL_WHITE0xc7c7c7/* XXX too dim? */
> > +#defineNORMAL_RED  0xaa
> > +#defineNORMAL_GREEN0x00aa00
> > +#defineNORMAL_BROWN0xaa5500
> > +#defineNORMAL_BLUE 0xaa
> > +#defineNORMAL_MAGENTA  0xaa00aa
> > +#defineNORMAL_CYAN 0x00
> > +#defineNORMAL_WHITE0xaa
> >  
> > -#defineHILITE_BLACK0x7f7f7f
> > -#defineHILITE_RED  0xff
> > -#defineHILITE_GREEN0x00ff00
> > -#defineHILITE_BROWN0x00
> > -#defineHILITE_BLUE 0xff
> > -#defineHILITE_MAGENTA  0xff00ff
> > -#defineHILITE_CYAN 0x00
> > +#defineHILITE_BLACK0x55
> > +#defineHILITE_RED  0xff
> > +#defineHILITE_GREEN0x55ff55
> > +#defineHILITE_BROWN0x55
> > +#defineHILITE_BLUE 0xff
> > +#defineHILITE_MAGENTA  0xff55ff
> > +#defineHILITE_CYAN 0x55
> >  #defineHILITE_WHITE0xff
> >  
> >  const u_char rasops_cmap[256 * 3] = {
> > 
> 
> 

Re: Display color depth when attaching inteldrm and radeondrm

[Mark Kettenis]

> Date: Fri, 6 Jan 2017 12:42:13 +0100
> From: Frederic Cambus 
> 
> Hi tech@,
> 
> Here's a diff to display color depth alongside resolution when attaching
> inteldrm and radeondrm, using the same scheme as efifb(4). This is the
> first step in trying to have all frame buffer drivers display resolution
> and depth the same way.
> 
> Tested only with inteldrm.
> 
> On this machine, it now displays: inteldrm0: 1600x900, 32bpp
> 
> Comments? OK?

ok kettenis@

> Index: sys/dev/pci/drm/i915/i915_drv.c
> ===
> RCS file: /cvs/src/sys/dev/pci/drm/i915/i915_drv.c,v
> retrieving revision 1.100
> diff -u -p -r1.100 i915_drv.c
> --- sys/dev/pci/drm/i915/i915_drv.c   8 Apr 2016 08:27:53 -   1.100
> +++ sys/dev/pci/drm/i915/i915_drv.c   5 Jan 2017 21:45:13 -
> @@ -1508,8 +1508,8 @@ inteldrm_attach(struct device *parent, s
>   efifb_cndetach();
>  #endif
>  
> - printf("%s: %dx%d\n", dev_priv->sc_dev.dv_xname,
> - ri->ri_width, ri->ri_height);
> + printf("%s: %dx%d, %dbpp\n", dev_priv->sc_dev.dv_xname,
> + ri->ri_width, ri->ri_height, ri->ri_depth);
>  
>   intel_fbdev_restore_mode(dev);
>  
> Index: sys/dev/pci/drm/radeon/radeon_kms.c
> ===
> RCS file: /cvs/src/sys/dev/pci/drm/radeon/radeon_kms.c,v
> retrieving revision 1.48
> diff -u -p -r1.48 radeon_kms.c
> --- sys/dev/pci/drm/radeon/radeon_kms.c   8 Apr 2016 08:27:53 -   
> 1.48
> +++ sys/dev/pci/drm/radeon/radeon_kms.c   5 Jan 2017 21:45:13 -
> @@ -769,7 +769,8 @@ radeondrm_attachhook(struct device *self
>   radeon_vga_set_state(rdev, false);
>   pci_disable_legacy_vga(>dev);
>  
> - printf("%s: %dx%d\n", rdev->dev.dv_xname, ri->ri_width, ri->ri_height);
> + printf("%s: %dx%d, %dbpp\n", rdev->dev.dv_xname,
> + ri->ri_width, ri->ri_height, ri->ri_depth);
>  
>   config_found_sm(>dev, , wsemuldisplaydevprint,
>   wsemuldisplaydevsubmatch);
> 

Re: Allow install from https server w/ self signed cert

[Bob Beck]

On Fri, Jan 06, 2017 at 10:48:37AM -0500, RD Thrush wrote:
> On 01/06/17 06:28, Stuart Henderson wrote:
> > Related to this (and particularly thinking about autoinstalls),
> > would it make sense to allow explicit protocols in the hostname?
> > 
> > some.host -> https with http fallback
> > http://some.host/ -> http only
> > https://some.host/ -> https only, no fallback
> 
> That would totally work for my install problem.
> 
> FWIW, instead of running a patched install.sub, "rm /etc/ssl/cert.pem" makes 
> the install bypass the https attempt.
> 

Note, if you're upgrading or otherwise have a way to et a cert.pem bundle onto 
there to *replace*
the default, you could always drop the signer for your private self-signed 
server into the cert.pem
bundle, at which point it would be accepted as trusted. 

of course if you're just installing you have an interesting chicken and egg 
problem, unless
you put it somewhere on an https site that does have a real certificate, drop 
out of the
installer and do

ftp -o /tmp/mysigner.pem https://my.secure.site/mysigner.pem
cat /tmp/mysigner.pem >> /etc/ssl/cert.pem

then continue the install, and you're good. 

Almost wonder if it's worth an extra question in the installer to ask
for an https address to retrieve a certficiate bundle to be appended to cert.pem
for the install...

OpenBSD kernel L1 to L4 transmission and Qemu debug problem

[Behzat Erte]

Hello everyone,

I've just started investigating OpenBSD kernel and I'm interested in
networking stuff.

Actually I'm not sure this mail group is a correct place or not but I've
to need some information about L1 to L4 packet transmission
(incoming/outgoing). I've created debug environment for OpenBSD and
currently I'm using qemu+eclipse+gdb that works enough for debugging
(stepping via breakpoints) kernel sources.

However when I attached the bsd.gdb elf file with using gdb remote
connection than qemu goes to hang state which can not be reachable until
releasing the gdb connection.

How can I handle this problem, do you have any suggestion?

p.s. any reply/feedback would be great :-)

Cheers,
-berte.  



0x49677FA3.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

gzip keep input files patch

[frantisek holop]

hello,

here is a simple patch to add -k (keep) flag to
gzip/compress.  freebsd has it, netbsd has it (although
omitted from the manpages), linux has it.

my use case is automating gzip compression for nginx's
ngx_http_gzip_static_module that can serve
precompressed files from the same directory, but
i also need to keep the input files.

i am aware that
$ gzip -c file > file.gz
does the same, but -k could make certain things easier:

$ find . -name "*.html" -exec gzip -k {} \;

-f
-- 
Index: compress.1
===
RCS file: /cvs/src/usr.bin/compress/compress.1,v
retrieving revision 1.48
diff -u -p -r1.48 compress.1
--- compress.1  17 Mar 2014 14:23:50 -  1.48
+++ compress.1  7 Jan 2017 19:10:58 -
@@ -44,7 +44,7 @@
 .Nd compress and expand data (compress mode)
 .Sh SYNOPSIS
 .Nm compress
-.Op Fl 123456789cdfghlNnOqrtv
+.Op Fl 123456789cdfghklNnOqrtv
 .Op Fl b Ar bits
 .Op Fl o Ar filename
 .Op Fl S Ar suffix
@@ -192,6 +192,8 @@ Use the deflate scheme, which reportedly
 mode).
 .It Fl h
 Print a short help message.
+.It Fl k
+Keep (do not delete) input files during compression or decompression.
 .It Fl l
 List information for the specified compressed files.
 The following information is listed:
Index: gzip.1
===
RCS file: /cvs/src/usr.bin/compress/gzip.1,v
retrieving revision 1.14
diff -u -p -r1.14 gzip.1
--- gzip.1  7 Oct 2014 21:06:30 -   1.14
+++ gzip.1  7 Jan 2017 19:10:58 -
@@ -183,6 +183,8 @@ behave as
 .Xr cat 1 .
 .It Fl h
 Print a short help message.
+.It Fl k
+Keep (do not delete) input files during compression or decompression.
 .It Fl L
 A no-op which exists for compatibility only.
 On GNU gzip, it displays the program's license.
Index: main.c
===
RCS file: /cvs/src/usr.bin/compress/main.c,v
retrieving revision 1.94
diff -u -p -r1.94 main.c
--- main.c  3 Sep 2016 13:26:50 -   1.94
+++ main.c  7 Jan 2017 19:10:58 -
@@ -51,6 +51,7 @@
 #define min(a,b) ((a) < (b)? (a) : (b))
 
 int cat, decomp, pipin, force, verbose, testmode, list, recurse, storename;
+int keep;
 extern char *__progname;
 
 const struct compressor {
@@ -73,7 +74,7 @@ const struct compressor {
"deflate",
".gz",
"\037\213",
-   "123456789ab:cdfhLlNnOo:qrS:tVv",
+   "123456789ab:cdfhkLlNnOo:qrS:tVv",
"cfhLlNno:qrtVv",
"fhqr",
gz_ropen,
@@ -90,7 +91,7 @@ const struct compressor {
"compress",
".Z",
"\037\235",
-   "123456789ab:cdfghlNnOo:qrS:tv",
+   "123456789ab:cdfghklNnOo:qrS:tv",
"cfhlNno:qrtv",
"fghqr",
z_ropen,
@@ -108,7 +109,7 @@ const struct compressor null_method = {
"null",
".nul",
"XX",
-   "123456789ab:cdfghlNnOo:qrS:tv",
+   "123456789ab:cdfghklNnOo:qrS:tv",
"cfhlNno:qrtv",
"fghqr",
null_ropen,
@@ -139,6 +140,7 @@ const struct option longopts[] = {
{ "uncompress", no_argument,0, 'd' },
{ "force",  no_argument,0, 'f' },
{ "help",   no_argument,0, 'h' },
+   { "keep",   no_argument,0, 'k' },
{ "list",   no_argument,0, 'l' },
{ "license",no_argument,0, 'L' },
{ "no-name",no_argument,0, 'n' },
@@ -274,6 +276,9 @@ main(int argc, char *argv[])
strlcpy(suffix, method->suffix, sizeof(suffix));
bits = 6;
break;
+   case 'k':
+   keep++;
+   break;
case 'l':
list++;
testmode = 1;
@@ -456,7 +461,7 @@ main(int argc, char *argv[])
 
switch (error) {
case SUCCESS:
-   if (!cat && !testmode) {
+   if (!cat && !testmode && !keep) {
if (!pipin && unlink(infile) && verbose >= 0)
warn("input: %s", infile);
}
@@ -939,7 +944,7 @@ usage(int status)
 
switch (pmode) {
case MODE_COMP:
-   fprintf(stderr, "usage: %s [-123456789cdf%sh%slNnOqrt%sv] "
+   fprintf(stderr, "usage: %s [-123456789cdf%shk%slNnOqrt%sv] "
"[-b bits] [-o filename] [-S suffix]\n"
"   %*s [file ...]\n", __progname,
!gzip ? "g" : "", gzip ? "L" : "", gzip ? "V" : "",

Re: find -delete

[Mark Kettenis]

> Date: Sat, 7 Jan 2017 13:15:05 +
> From: Stuart Henderson 
> 
> On 2017/01/07 11:32, Marc Espie wrote:
> > On Tue, Jan 03, 2017 at 11:15:39PM +0100, Mark Kettenis wrote:
> > > > From: "Ted Unangst" 
> > > > Date: Tue, 03 Jan 2017 16:39:48 -0500
> > > > 
> > > > I copied this straight from freebsd. Not fixed, but feel free to 
> > > > correct as
> > > > desired.
> > > > 
> > > > This adds a third example showing -delete, mentioning that it's not 
> > > > standard,
> > > > but also hinting that it may work better than "rm -r" when you want to 
> > > > delete
> > > > directories.
> > > 
> > > I really think we should not encourage unportable code like that by
> > > giving an example in our manual page.
> > > 
> > > I'm even tempted to say that you should leave the "-exec rm {} \;"
> > > example alone.  The + here only works because rm(1) accepts multiple
> > > file arguments.
> > 
> > Huh ? of course rm accepts multiple file arguments. All "good" unix commands
> > accept multiple file arguments, fortunately. That's what makes +exec (or
> > xargs for that matter) work.
> 
> I think the reason the example uses ; is probably because we only
> added + relatively recently (2012), and adding an example using it
> back then would make it harder for people writing scripts that
> work on newer and older OpenBSD. Enough time has passed that this
> isn't really an issue any more. But I would very much like to keep
> an example using ; to demonstrate the shell quoting needed when
> people have to use a bad command that only takes one file argument.

Right.  That was more or less my point.  The man page is there to
explain how find(1) works, not to show the most efficient way to
delete a bunch of files.

Not that a clear and concise discussion of the various trade-offs of
\; vs. + vs. -delete would hurt.

Re: find -delete

[Stuart Henderson]

On 2017/01/07 11:32, Marc Espie wrote:
> On Tue, Jan 03, 2017 at 11:15:39PM +0100, Mark Kettenis wrote:
> > > From: "Ted Unangst" 
> > > Date: Tue, 03 Jan 2017 16:39:48 -0500
> > > 
> > > I copied this straight from freebsd. Not fixed, but feel free to correct 
> > > as
> > > desired.
> > > 
> > > This adds a third example showing -delete, mentioning that it's not 
> > > standard,
> > > but also hinting that it may work better than "rm -r" when you want to 
> > > delete
> > > directories.
> > 
> > I really think we should not encourage unportable code like that by
> > giving an example in our manual page.
> > 
> > I'm even tempted to say that you should leave the "-exec rm {} \;"
> > example alone.  The + here only works because rm(1) accepts multiple
> > file arguments.
> 
> Huh ? of course rm accepts multiple file arguments. All "good" unix commands
> accept multiple file arguments, fortunately. That's what makes +exec (or
> xargs for that matter) work.

I think the reason the example uses ; is probably because we only
added + relatively recently (2012), and adding an example using it
back then would make it harder for people writing scripts that
work on newer and older OpenBSD. Enough time has passed that this
isn't really an issue any more. But I would very much like to keep
an example using ; to demonstrate the shell quoting needed when
people have to use a bad command that only takes one file argument.

OpenBGPd: expand rib list

[Denis Fondras]

Hello,

Here is a patch to expand RIB names in rules. When playing with multi-RIBs, it
allows to simplify ruleset.

 Ex :
# cat /etc/bgpd.conf
[...]
peer_ribs = "{ m1, m2, m3 }"
deny rib m2 from any
allow rib $peer_ribs from any prefix { 2001:db8:1::/48, 2001:db8:2::/48 }

# bgpd -dnv
[...]
deny rib m2 from any 
allow rib m3 from any prefix 2001:db8:2::/48 
allow rib m3 from any prefix 2001:db8:1::/48 
allow rib m2 from any prefix 2001:db8:2::/48 
allow rib m2 from any prefix 2001:db8:1::/48 
allow rib m1 from any prefix 2001:db8:2::/48 
allow rib m1 from any prefix 2001:db8:1::/48 


Index: parse.y
===
RCS file: /cvs/src/usr.sbin/bgpd/parse.y,v
retrieving revision 1.293
diff -u -p -r1.293 parse.y
--- parse.y 5 Jan 2017 13:53:09 -   1.293
+++ parse.y 7 Jan 2017 12:34:08 -
@@ -91,6 +91,11 @@ static struct filter_rule*curpeer_filte
 static struct filter_rule  *curgroup_filter[2];
 static u_int32_tid;
 
+struct filter_rib_l {
+   struct filter_rib_l *next;
+   char name[PEER_DESCR_LEN];
+};
+
 struct filter_peers_l {
struct filter_peers_l   *next;
struct filter_peers  p;
@@ -128,8 +133,9 @@ struct rde_rib  *find_rib(char *);
 int get_id(struct peer *);
 int merge_prefixspec(struct filter_prefix_l *,
struct filter_prefixlen *);
-int expand_rule(struct filter_rule *, struct filter_peers_l *,
-   struct filter_match_l *, struct filter_set_head *);
+int expand_rule(struct filter_rule *, struct filter_rib_l *,
+   struct filter_peers_l *, struct filter_match_l *,
+   struct filter_set_head *);
 int str2key(char *, char *, size_t);
 int neighbor_consistent(struct peer *);
 int merge_filterset(struct filter_set_head *, struct filter_set *);
@@ -153,6 +159,7 @@ typedef struct {
char*string;
struct bgpd_addr addr;
u_int8_t u8;
+   struct filter_rib_l *filter_rib;
struct filter_peers_l   *filter_peers;
struct filter_match_lfilter_match;
struct filter_prefix_l  *filter_prefix;
@@ -203,10 +210,11 @@ typedef struct {
 %typeasnumber as4number as4number_any optnumber
 %typeespah family restart origincode nettype
 %typeyesno inout restricted
-%typestring filter_rib
+%typestring
 %type  address
 %typeprefix addrspec
 %typeaction quick direction delete
+%typefilter_rib_h filter_rib_l filter_rib
 %type  filter_peer filter_peer_l filter_peer_h
 %type  filter_match filter_elm filter_match_h
 %type filter_as filter_as_l filter_as_h
@@ -1458,9 +1466,10 @@ encspec  : /* nada */{
}
;
 
-filterrule : action quick filter_rib direction filter_peer_h 
filter_match_h filter_set
+filterrule : action quick filter_rib_h direction filter_peer_h 
filter_match_h filter_set
{
struct filter_rule   r;
+   struct filter_rib_l  *rb, *rbnext;
 
bzero(, sizeof(r));
r.action = $1;
@@ -1470,25 +1479,15 @@ filterrule  : action quick filter_rib dir
if (r.dir != DIR_IN) {
yyerror("rib only allowed on \"from\" "
"rules.");
-   free($3);
-   YYERROR;
-   }
-   if (!find_rib($3)) {
-   yyerror("rib \"%s\" does not exist.",
-   $3);
-   free($3);
-   YYERROR;
-   }
-   if (strlcpy(r.rib, $3, sizeof(r.rib)) >=
-   sizeof(r.rib)) {
-   yyerror("rib name \"%s\" too long: "
-   "max %zu", $3, sizeof(r.rib) - 1);
-   free($3);
+
+   for (rb = $3; rb != NULL; rb = rbnext) {
+   rbnext = rb->next;
+   free(rb);
+   }
YYERROR;
}
-   free($3);
}
-   if (expand_rule(, $5, &$6, $7) == 

Re: rasops(9): Use proper RGB values for the ANSI color palette

[Visa Hankala]

On Sat, Jan 07, 2017 at 12:23:31AM +0100, Frederic Cambus wrote:
> Hi tech@,
> 
> Here is a diff to use proper RGB values for the ANSI color palette in
> rasops(9).
> 
> Comments? OK?

I prefer the old palette because its contrast is higher.

> Index: sys/dev/rasops/rasops.c
> ===
> RCS file: /cvs/src/sys/dev/rasops/rasops.c,v
> retrieving revision 1.44
> diff -u -p -r1.44 rasops.c
> --- sys/dev/rasops/rasops.c   15 Dec 2016 19:18:41 -  1.44
> +++ sys/dev/rasops/rasops.c   6 Jan 2017 22:11:02 -
> @@ -48,21 +48,21 @@
>  /* ANSI colormap (R,G,B) */
>  
>  #define  NORMAL_BLACK0x00
> -#define  NORMAL_RED  0x7f
> -#define  NORMAL_GREEN0x007f00
> -#define  NORMAL_BROWN0x7f7f00
> -#define  NORMAL_BLUE 0x7f
> -#define  NORMAL_MAGENTA  0x7f007f
> -#define  NORMAL_CYAN 0x007f7f
> -#define  NORMAL_WHITE0xc7c7c7/* XXX too dim? */
> +#define  NORMAL_RED  0xaa
> +#define  NORMAL_GREEN0x00aa00
> +#define  NORMAL_BROWN0xaa5500
> +#define  NORMAL_BLUE 0xaa
> +#define  NORMAL_MAGENTA  0xaa00aa
> +#define  NORMAL_CYAN 0x00
> +#define  NORMAL_WHITE0xaa
>  
> -#define  HILITE_BLACK0x7f7f7f
> -#define  HILITE_RED  0xff
> -#define  HILITE_GREEN0x00ff00
> -#define  HILITE_BROWN0x00
> -#define  HILITE_BLUE 0xff
> -#define  HILITE_MAGENTA  0xff00ff
> -#define  HILITE_CYAN 0x00
> +#define  HILITE_BLACK0x55
> +#define  HILITE_RED  0xff
> +#define  HILITE_GREEN0x55ff55
> +#define  HILITE_BROWN0x55
> +#define  HILITE_BLUE 0xff
> +#define  HILITE_MAGENTA  0xff55ff
> +#define  HILITE_CYAN 0x55
>  #define  HILITE_WHITE0xff
>  
>  const u_char rasops_cmap[256 * 3] = {
> 

tcpdump: decode BGP Administrative Shutdown Communication

[Job Snijders]

This patch adds support to tcpdump(8) to decode BGP Administrative
Shutdown Communications in human readable form.

The draft-ietf-idr-shutdown 
(https://tools.ietf.org/html/draft-ietf-idr-shutdown)
specification documents a mechanism to transmit a short freeform UTF-8
message as part of a BGP Cease NOTIFICATION message to inform the
neighbor why the BGP session is being shutdown.

This modified tcpdump(8) is used in the development of the
draft-ietf-idr-shutdown feature for OpenBGPD.

example, snipped from 'tcpdump -t -n -v -s 1500 host 165.254.255.17 and port 
179':

BGP (NOTIFICATION: error Cease, subcode #2, Shutdown Communication
(len 124): "NTT will perform maintenance on this router. This is
tracked in TICKET-1-24824294. Contact n...@ntt.net for more
information.")

UTF-8 stuff like 濾 is printed like this:

BGP (NOTIFICATION: error Cease, subcode #2, Shutdown Communication
(len 26): "and here is a unicorn \360\237\246\204")

Index: usr.sbin/tcpdump/print-bgp.c
===
RCS file: /cvs/src/usr.sbin/tcpdump/print-bgp.c,v
retrieving revision 1.20
diff -u -p -r1.20 print-bgp.c
--- usr.sbin/tcpdump/print-bgp.c27 Oct 2016 08:21:58 -  1.20
+++ usr.sbin/tcpdump/print-bgp.c7 Jan 2017 11:15:01 -
@@ -228,6 +228,9 @@ static const char *bgpnotify_minor_updat
 
 /* RFC 4486 */
 #define BGP_NOTIFY_MINOR_CEASE_MAXPRFX  1
+/* draft-ietf-idr-shutdown */
+#define BGP_NOTIFY_MINOR_CEASE_ADMIN   2
+#define BGP_NOTIFY_MINOR_CEASE_ADMIN_SHUTDOWN_LEN  128
 static const char *bgpnotify_minor_cease[] = {
NULL, "Maximum Number of Prefixes Reached", "Administratively Shutdown",
"Peer De-configured", "Administratively Reset", "Connection Rejected",
@@ -302,6 +305,13 @@ static const char *afnumber[] = AFNUM_NA
sizeof(afnumber)/sizeof(afnumber[0]), (x)))
 
 
+static void
+print_hex(const u_char *p, u_int len)
+{
+   while (len--)
+   printf("%02x", *p++);
+}
+
 static const char *
 num_or_str(const char **table, size_t siz, int value)
 {
@@ -996,6 +1006,9 @@ bgp_notification_print(const u_char *dat
u_int16_t af;
u_int8_t safi;
const u_char *p;
+   uint8_t shutdown_comm_length;
+   uint8_t remainder_offset;
+   char string[128];
 
TCHECK2(dat[0], BGP_NOTIFICATION_SIZE);
memcpy(, dat, BGP_NOTIFICATION_SIZE);
@@ -1026,9 +1039,57 @@ bgp_notification_print(const u_char *dat
 
printf(" Max Prefixes: %u", EXTRACT_32BITS(p+3));
}
+
+   /*
+* draft-ietf-idr-shutdown describes a method to send a
+* message intended for human consumption regarding the
+* Administrative Shutdown event. This is called the
+* "Administrative Shutdown Communication". The message
+* is UTF-8 encoded and may be no longer than 128 bytes.
+*/
+
+   if (bgpn.bgpn_minor == BGP_NOTIFY_MINOR_CEASE_ADMIN &&
+   length >= 1) {
+   p = dat + BGP_NOTIFICATION_SIZE;
+   TCHECK2(*p, 1);
+   shutdown_comm_length = *(p);
+   remainder_offset = 0;
+   /* seems we received garbage, hexdump it all */
+   if (shutdown_comm_length >
+   BGP_NOTIFY_MINOR_CEASE_ADMIN_SHUTDOWN_LEN)
+   printf(", invalid Shutdown Communication (len 
%i > %i)",
+   shutdown_comm_length,
+   BGP_NOTIFY_MINOR_CEASE_ADMIN_SHUTDOWN_LEN);
+   else if (shutdown_comm_length == 0) {
+   printf(", empty Shutdown Communication");
+   remainder_offset += 1;
+   }
+   /* a proper shutdown communication */
+   else if (shutdown_comm_length <=
+   BGP_NOTIFY_MINOR_CEASE_ADMIN_SHUTDOWN_LEN) {
+   TCHECK2(*p, shutdown_comm_length);
+   printf(", Shutdown Communication (len %u): \"",
+   shutdown_comm_length);
+   memset(string, 0, 128);
+   memcpy(string, p+1, shutdown_comm_length);
+   safeputs(string);
+   printf("\"");
+   remainder_offset += shutdown_comm_length + 1;
+   }
+   /* if there is trailing data, hexdump it */
+   if (length -
+   (remainder_offset + BGP_NOTIFICATION_SIZE) > 0) {
+   printf(", Data: (len %u) ",
+   length - (remainder_offset +
+ 

Re: find -delete

[Marc Espie]

On Tue, Jan 03, 2017 at 11:15:39PM +0100, Mark Kettenis wrote:
> > From: "Ted Unangst" 
> > Date: Tue, 03 Jan 2017 16:39:48 -0500
> > 
> > I copied this straight from freebsd. Not fixed, but feel free to correct as
> > desired.
> > 
> > This adds a third example showing -delete, mentioning that it's not 
> > standard,
> > but also hinting that it may work better than "rm -r" when you want to 
> > delete
> > directories.
> 
> I really think we should not encourage unportable code like that by
> giving an example in our manual page.
> 
> I'm even tempted to say that you should leave the "-exec rm {} \;"
> example alone.  The + here only works because rm(1) accepts multiple
> file arguments.

Huh ? of course rm accepts multiple file arguments. All "good" unix commands
accept multiple file arguments, fortunately. That's what makes +exec (or
xargs for that matter) work.