Re: Transferring ownership of SSH connection from process A to B, letting A quit nicely?

2021-08-11 Thread Philip Guenther
On Tue, Aug 10, 2021 at 12:13 PM mid  wrote:

> On Monday, August 9th, 2021 at 5:36 AM, Philip Guenther <
> guent...@gmail.com> wrote:
>
> > If you're 100% sure you have it right, then it should be easy to provide
> a
> > program that demonstrates
> > 1.  passing an fd between processes
> > 2.  using it successfully in the receiving process
> > 3.  the sending process exiting
> > 4.  attempts to us it failing the receiving process
>
> Not 100%, but I'm out of ideas, so here goes nothing.
>
> client.c (process A):
>
...

> Compiled with:
>   cc -std=c99 -o server server.c
>   cc -std=c99 -o client client.c
>
> `client` is also the shell of the user, but the results are the same if
> I call it from within a "real" shell, too.
>
> The server receives the correct FDs, and prints
> "Hello from the Server\n" correctly, too. But as soon as `client`
> exits, the SSH connection goes with it, instead of staying (as in,
> I get "Connection to localhost closed").
>

Your problems have nothing to do with fd passing but rather are around not
understanding how session management works.
The client is passing its stdin/stdout, which are either pipes or a
pseudo-tty connected to the ssh server and NOT the actual TCP socket
carrying the ssh connection.  When the session leader process exits the
kernel will perform various cleanup operations (block tty access, send some
signals).

If you _really_ want to hack around in this area, you need to do a bunch of
reading and research.  I recommend buying/borrowing a copy of
_Advanced_Programming_in_the_UNIX_Environment_ by W. Richard Stevens.


Philip Guenther


Re: Transferring ownership of SSH connection from process A to B, letting A quit nicely?

2021-08-08 Thread Philip Guenther
On Sun, Aug 8, 2021 at 10:13 AM mid  wrote:
...

> I have tried sending the file descriptors associated with the connection
> to process B via sendmsg, thinking that maybe the
> file descriptors are reference-counted. It's a logical
> assumption, but it didn't work - the connection closed with
> process A.
>

File descriptors sent via sendmsg() on a unix domain socket of SCM_RIGHTS
control messages *are* reference-counted.

If you think you've done that and it's not behaving as expected, then first
check and report errors on *all* the system calls, and that the returned
data fields on things like recvmsg() have the values you expect.  If
sendmsg() is failing or you're accidentally discarding the fds in the
recvmsg() by not providing the space needed then yeah, the fds will be
closed because the last reference is gone.

If you're 100% sure you have it right, then it should be easy to provide a
program that demonstrates
1) passing an fd between processes
2) using it *successfully* in the receiving process
3) the sending process exiting
3) attempts to us it failing the receiving process

No?


Philip

(Replies not on the list will be deleted)


Re: /var/log/failedlogin is a binary file with a lot of null bytes?!

2021-07-17 Thread Philip Guenther
On Fri, Jul 16, 2021 at 11:49 PM podolica  wrote:

> On my OpenBSD installation (6.9) one of the log files created by login(1)
> seems to be a binary file:
> $ less /var/log/failedlogin
> "failedlogin" may be a binary file. See it anyway?
>
...

> What can I learn from this logfile?
> A lot of repeating null bytes and "ttyC2" and "ttyC3" does not seems
> to be very informative.
>
> Is this an error?
>

No, it's not an error.  That file is specific to the 'login' command,
specifically the source file /usr/src/usr.bin/login/failedlogin.c and
consists of an array of the 'badlogin' structure specified there.  If you
want to dump its contents in a more readable format then you should write a
small program to do so in C or some other language which can easily handle
binary files.


Philip Guenther


Re: udp sendto performance

2021-07-06 Thread Philip Guenther
On Mon, Jul 5, 2021 at 3:56 PM Brian Empson  wrote:
...

> I'm running 6.5, is there any significant performance improvements in
> the newer versions of OpenBSD that would improve sendto()'s performance?
>

Yes.

I'll suggest that before you do any serious perf measurement or try to
"squeeze more performance out of" *any* codebase you update to a current
release and not measure a two year / four version old release.

There are people for whom tracking performance of a set up over time is
important and for them measuring obsolete versions is useful.  However, if
you have a target and are trying to figure out whether a setup can _reach_
that target then measuring an older release tells you nothing, because you
would never deploy an out of date release.  I Would Dearly Hope.


Philip Guenther


Re: EACCES of UDP packet

2021-06-22 Thread Philip Guenther
On Mon, Jun 21, 2021 at 9:07 PM Siegfried Levin 
wrote:

> Thanks a lot for the hint. Unfortunately I’m still not able to see why
> sendto failed with 13 Permission denied. The AF_INET address masked is the
> correct one of my server, not a broadcast address. A sendto before this one
> to the same address just worked.
>
>   3058 myapp  CALL
> sendto(5,0x1689f5f6500,0x5d,0x400,0x7f7f1144,0x10)
>   3058 myapp  STRU  struct sockaddr { AF_INET, xxx.xxx.xxx.xxx: }
>

Why have you chosen to hide information that may be useful in debugging
your problem?

"Hi, I'm asking for help but I have to hide addresses because...this
application is insecure if anyone else has its IP+port?  Because I've never
heard of shodan and don't believe that people are constantly scanning the
Internet?  And while I don't know why it's failing I'm 1000% sure that
there's no information to be gained from seeing the IP, so if it later
turns out my understanding of 'broadcast address' is incorrect, the time
I've wasted for myself and others will be...a total loss?"


  3058 myapp  RET   sendto -1 errno 13 Permission denied
>   3058 myapp  CALL  close(5)
>   3058 myapp  RET   close 0
>
The dump file is like 600MB. I can provide more trace log if it is
> necessary for locating the root cause.
>

Use the scientific method:
 * make a testable hypothesis
 * devise a test for that
 * perform the test
 * determine whether the hypothesis has been ruled out or confirmed

So, since the manpage mentions blocking pf, I suggest the hypothesis "it
returns EACCES because pf is blocking your packets".  I can think of
several ways to test that; what testing have you performed to confirm or
rule out that possibility?  "doas pfctl -d; run test; doas pfctl -e"?


Alternatively: what's different about *that* call?  Does every sento() call
on that socket fail?  What is special about that socket?  If other sendto()
calls succeed, what is different about that call?  Earlier setsockopt()
calls?


You say "I can confirm the packet was not sent to a broadcast address":
*how* have you confirmed that your understanding of 'broadcast address'
matches the kernel's understanding?  It ain't just 255.255.255.255


Philip Guenther



>
>
> Siegfried
> siegfried.le...@gmail.com
>
>
>
>
> > On Jun 15, 2021, at 8:50 PM, Theo de Raadt  wrote:
> >
> > use ktrace
> >
> > Siegfried Levin  wrote:
> >
> >> Hi,
> >>
> >> I have a application run by a normal user communicating with the server
> with UDP. It crashes very occasionally, like once per week, due to EACCES
> when sending a UDP packet. According to the manpage (
> https://man.openbsd.org/OpenBSD-6.9/sendmsg.2#EACCES), the reason might
> be either being blocked by PF or sending to a broadcast address. I can
> confirm the packet was not sent to a broadcast address. However, I cannot
> figure out what rule could block the connection occasionally either. The
> application can be brought back online without changing any configuration.
> Does anyone know what might fix this? I can also rewrite the code to make
> it ignore the error and keep trying but that might not be a proper
> solution. Running it as root might not be a good idea, too.
> >>
> >> It happens since OpenBSD 6.8. Now I’m running it on 6.9. The
> application is written in Rust.
> >>
> >> Siegfried
> >> siegfried.le...@gmail.com
> >>
> >>
> >>
> >>
>
>


Re: Usage of .note.openbsd.ident

2021-05-26 Thread Philip Guenther
On Fri, May 21, 2021 at 5:28 AM George Brown <321.geo...@gmail.com> wrote:

> It seems this ELF note was used for the now dead compat_linux feature.
> Aside from compat systems in other operating systems that may wish to
> identify OpenBSD binaries does this note have any other active uses?
>

The point of the note (and/or the OS/ABI field in the ELF header) is to
permit portable ELF tools to identify how to interpret OS-specific values,
those in the OS-ranges for types, for example.  Not inserting _some_
identifying factor is basically doing an embrace-and-extend on ELF and
actively hostile to portability of tooling.

If you find that ELF note obnoxious, just fix the linkers to instead set
the ELF ABI field correctly.  As I understand it, the 'go' tool chain has
done that for years.  It's really the better choice for this, would take
less space and be faster to process.


Philip Guenther


Re: Fwd: umm_map returns unaligned address?

2021-04-23 Thread Philip Guenther
On Fri, Apr 23, 2021 at 4:50 PM Alessandro Pistocchi 
wrote:
...

> What I was flagging is just that sometimes uvm_map returns an address that
> is not
> aligned to PAGE_SIZE ( I printed it out and it has 0x004 in the lower 12
> bits).On the
>
other hand uvm_unmap has an assertion that panics if the address passed to
> it is not
> page aligned. I believe that there could be a bug somewhere.
>

You apparently didn't print out the value directly after return from
uvm_map() but rather later after a bunch of your other code had run.  Yes,
there's a bug, in your game_mode_start_audio_thread(), where you advance
the pointer from uvm_map() by four.


Philip Guenther


Re: umm_map returns unaligned address?

2021-04-23 Thread Philip Guenther
On Fri, Apr 23, 2021 at 3:13 PM Alessandro Pistocchi 
wrote:

> -- Forwarded message -
> From: Alessandro Pistocchi 
> Date: Fri, Apr 23, 2021 at 1:55 PM
> Subject: umm_map returns unaligned address?
> To: 
>
>
> Hi all,
>
> I am fairly new to openbsd so if this is something obvious that I missed
> please be understanding.
>
> I am adding a syscall to openbsd 6.8. I am working on a raspberry pi.
>
> During the syscall I allocate some memory that I want to share between the
> kernel
> and the calling process.
>
> When it's time to wrap up and unmap the memory, I unmap it both from the
> kernel
> map and from the process map.
>
> The unmapping from the process map goes fine, the unmapping from the kernel
> map
> fails by saying that the virtual address in kernel map is not aligned to
> the page size
> ( it's actually 4 bytes off ).
>
> What have I missed? I assumed that umm_map would return a page aligned
> virtual
> address for the kernel mapping as well.
>
> Here is my code for creating the shared memory chunk:
>

Stop sending summaries and just send diffs that compile: you don't know
everything that is relevant and keep leaving out stuff that is.  I'm the
third person to say this.


>
> 
> // memory_size is a multiple of page size
> uvm_object = uao_create(memory_size, 0);
> if(!uvm_object) return;
>
> // TODO(ale): make sure that this memory cannot be swapped out
>
> uao_reference(uvm_object)
> if(uvm_map(kernel_map, (vaddr_t *), round_page(memory_size),
> uvm_object,
>0, 0, UVM_MAPFLAG(PROT_READ | PROT_WRITE, PROT_READ | PROT_WRITE,
>MAP_INHERIT_SHARED, MADV_NORMAL, 0))) {
>

The cast of  is wrong: it's either unnecessary (if memory is of the
correct type) or totally broken (if it isn't).  Why did you think it was
unnecessary to show how you declared your variables?

You also fail to show your initialization of 'memory'.  If you didn't then
that's ABSOLUTELY wrong and not in line with the existing uses of uvm_map()
in the kernel.  Please consult the uvm_map(9) manpage for what the incoming
value means.

...

> uao_reference(uvm_object);
> if(uvm_map(>p_vmspace->vm_map, _in_proc_space,
> round_page(memory_size), uvm_object,
>0, 0, UVM_MAPFLAG(PROT_READ | PROT_WRITE, PROT_READ | PROT_WRITE,
>MAP_INHERIT_NONE, MADV_NORMAL, 0))) {
> memory = 0;
>

This error handling is incomplete, lacking an unmap.


Philip Guenther


Re: Unable to listen properly on UDP port 4500

2020-12-08 Thread Philip Guenther
: bleys; grep 4500 /etc/services
ipsec-nat-t 4500/tcpipsec-msft  # IPsec NAT-Traversal
ipsec-nat-t 4500/udpipsec-msft  # IPsec NAT-Traversal
: bleys; sysctl net.inet.esp.udpencap
net.inet.esp.udpencap=1
: bleys

You're trying to use the ipsec ESP encapsulation port, which is enabled by
default.  If you're a masochist and likes making your life more difficult,
you can use that port for your own purposes by disabling that sysctl.  If
you're not a masochist, use a different port.


Philip Guenther


On Tue, Dec 8, 2020 at 4:13 PM Chris Johnson 
wrote:

> Hello All,
>
> I am unable to set up a localhost netcat listener on UDP port 4500 that
> responds to a client on that same host. I encountered this issue
> attempting to test whether UDP 4500 was open on our departmental firewall.
>
> Simple test case: Fresh build of OpenBSD 6.8. No local network, no
> packet filter, no iked running.
>
> # netstat -na -f inet | grep 4500
> [empty]
> # fstat | grep 4500
> [empty]
>
> $ nc -ul localhost 4501 &
> [1] 72638
> $ nc -u localhost 4501
> Z
> Z
> ^C
> $ pkill nc
>
> [1]+  Stopped nc -ul localhost 4501
> $ nc -ul localhost 4500 &
> [2] 70181
> $ nc -u localhost 4500
> Z
> ^C
> $ pkill nc
> [2]-  Terminated  nc -ul localhost 4500
>
> The server running on port 4500 does not echo. Why not? Is there
> something obvious that I'm missing?
>
> I've tried this on three different OpenBSD 6.8 systems (all amd64). Is
> UDP 4500 reserved in some way? Other ports I've tried work fine. Linux
> and MacOS systems work fine on this port.
>
> Cheers,
>
> Chris
>
>


Re: Potential ksh bug?

2020-11-17 Thread Philip Guenther
On Mon, Nov 16, 2020 at 11:04 PM Bodie  wrote:

> On 17.11.2020 05:04, Jordan Geoghegan wrote:
> > Hello,
> >
> > I'm not sure if this is a bug, or if it's just a pdksh thing, but I
> > stumbled upon some interesting behaviour when I was tinkering around
> > with quoting and using a poor mans array:
> >
> > test=$(cat <<'__EOT'
> > # I'll choose not to close this quote
> > other_stuff
> > __EOT
> > )
> >
> > echo "$test"
> >
> >
> > When I run this command on ash, dash, yash, bash, zsh or ksh93 I get
> > the following output:
> >
> > # I'll choose not to close this quote
> > other_stuff
> >
> > But when I run it on ksh from base or any pdksh derivative it throws
> > an error about an unclosed quote:
> >
> > test.sh[8]: no closing quote
> >
> > This snippet works on every POSIX-y shell in the ports tree, and fails
> > on every pdksh variant I tried, including on NetBSD and DragonflyBSD
> > as well.  I don't have the requisite esoteric knowledge regarding
> > pdksh's internal quoting logic, so I'm hoping one of the gurus here
> > can determine whether this is a bug or if I'm just doing something
> > annoying.
> >
> > Any insight that can be provided would be much appreciated.
> >
>
> What exactly are you trying to achieve?
>
> If you will look in sh(1) for 'Command expansion' then there are defined
> rules and your form is not between them.
>

I disagree.  I believe this:

cat <<'__EOT'
# I'll choose not to close this quote
other_stuff
__EOT

matches the syntax for 'command'...once you take into account redirections,
including 'here-docs'.  Or do you believe that's not a valid command on
it's own?  To put another way, I agree with halex@ that this is a (known,
not yet fixed) bug.


So error message about missing closing quote is actually proper
> behavior.
>

Nope.  This is a bug in OpenBSD ksh.



> As well it is good idea to avoid reserved words as a names for variables
> ;-)
> (test)


Hmm?

* 'test' is not a reserved word in the shell
* shell variable names are a completely different namespace than shell
reserved words or commands
* code written to check whether something is a bug is 1000% out-of-bounds
for style comments: either there's a bug or there isn't


Philip Guenther


Re: OpenBSD 6.8 (release) guest (qemu/kvm) on Linux 5.9 host (amd64) fails with protection fault trap

2020-11-16 Thread Philip Guenther
On Sun, Nov 15, 2020 at 10:24 AM Gabriel Garcia  wrote:

> I would like to run OpenBSD as stated on the subject - I have been able,
> however, to run it successfully with "-cpu Opteron_G2-v1", but I would
> rather use "-cpu host" instead. Also note that on an Intel host, OpenBSD
> appears to work successfully on the same Linux base.
>
> qemu invocation that yields a trap:
>
...

Lots of looking everywhere but the error going on here.  Let's look at the
trap/ddb output:


>   kernel: protection fault trap, code=0
>   Stopped at  amd64_errata_setmsr+0x4e:   wrmsr
>
> Contents of CPU registers:
> ddb> show registers
>   rdi   0x9c5a203a
>   rsi   0x820ff920errata+0xe0
>   rbp   0x824c5740end+0x2c5740
>   rbx 0x18
>   rdx0
>   rcx   0xc0011029
>   rax  0x3
>   r80x824c55a8end+0x2c55a8
>   r9 0
>   r10   0xbdf7dabff85d847b
>   r11   0x51e076fef1dcfa7b
>   r120
>   r130
>   r14   0x820ff940acpihid_ca
>   r15   0x820ff920errata+0xe0
>   rip   0x81bc6edeamd64_errata_setmsr+0x4e
>   cs   0x8
>   rflags   0x10256__ALIGN_SIZE+0xf256
>   rsp   0x824c5730end+0x2c5730
>   ss  0x10
>   amd64_errata_setmsr+0x4e:   wrmsr


Oh hey, it says RIGHT THERE that a wrmsr instruction faulted.  Which one?
Well, it's in the function amd64_errata_setmsr().  Furthermore, we just
have to remember that wrmsr takes the MSR to write in the %ecx register
(something the qemu people surely know) and so it's the 0xc0011029 MSR.
Let's grep for that in the amd64 kernel source:

: bleys; cd /usr/src/sys/arch/amd64/
: bleys; grep -rw 0xc0011029  *
include/specialreg.h:#define MSR_DE_CFG 0xc0011029  /* Decode
Configuration */
: bleys; grep -rwl MSR_DE_CFG *
amd64/identcpu.c
amd64/vmm.c
amd64/amd64errata.c
include/specialreg.h
: bleys; grep -rwl ^amd64_errata_setmsr *
amd64/amd64errata.c
: bleys; less +/MSR_DE_CFG amd64/amd64errata.c
<...>
/*
 * 721: Processor May Incorrectly Update Stack Pointer
 */
{
721, 0, MSR_DE_CFG, amd64_errata_set9,
amd64_errata_setmsr, DE_CFG_721
},


Looks like qemu fails to behave like a real AMD CPU by failing to handle
the wrmsr() for that errata.  Also the kernel you're running it on is
failing to apply the errata itself (because otherwise OpenBSD won't be
trying to flip the bit itself).  Go shake an AMD errata document at the
qemu people and figure out why your host kernel isn't applying a documented
fix.

Paying attention to what the kernel tells you is a Good Thing.  Honestly,
what you showed above, that it trapped on wrmsr with those registers should
have been enough for the qemu people to figure out what wasn't working.


Philip Guenther


Re: time_t

2020-10-05 Thread Philip Guenther
On Mon, Oct 5, 2020 at 12:27 PM Roderick  wrote:
...

> Back to tar files: there is place for 11 octal digits, that is
> only twice the time you can count with 32 bits, in years:
>
> 2^33/(60*60*24*365.25*2)=136.09930083403047126524
>
> Also not too much. Is it not a better solution to begin a new epoch
> every 68.05 years? We can do a big celebration at the beginning of
> each new epoch.
>

The pax file format (which is supported by many 'tar' binaries) supports
expressing the time as a decimal string with sub-integer part, bounded only
by the block size, solving both the field size limit problem and the lack
of subsecond resolution.


Philip Guenther


Re: i386, parallel port permission error?

2020-08-19 Thread Philip Guenther
On Wed, Aug 19, 2020 at 3:09 AM Doug Moss  wrote:

> On 2020-08-17, Stuart Henderson wrote:
> >On 2020-08-17, Doug Moss  wrote:
> >>
> >> Did something change at OpenBSD i386 between 5.9 and 6.0
> >> related to parallel port / lpt hardware permissions?
> >>
> >> Up to OpenBSD i386 5.9,
> >> I used to be able to have a working case-LCD-screen
> >> with lcdproc-0.5.7, driver=hd44780, winamp wiring, with 'allowaperture'.
> >> At OpenBSD i386 6.0 and after, it fails.
> >
> >I think this is due to kernel memory access restrictions that were added.
> >Setting sysctl kern.allowkmem=1 before securelevel is raised bypasses them
> >but of course weakens protections.
>
> I think the problem in lcdproc is in the code from this file (port.h)
> https://github.com/lcdproc/lcdproc/blob/master/server/drivers/port.h
>
> I am out of my depth with this code. I have never even seen these
> calls 'outb' and 'inb'
> The code looks like it was begun in 1995.
> Is that what you are talking about 'kernel memory access'?
>

Those are direct CPU instructions for I/O.  To use them, the code must use
i386_iopl(2) from libarch.a to enable it, which in turn requires the
machdep.allowaperture sysctl to a non-zero value (per the manpage).



> Any advice about this? Is this code amenable to being 'modernized'?
>
> If can't modernize the lcdproc code, can you give me specifics about:
> Do I just put a line in /etc/rc.securelevel
> kern.allowkmem=1
>

Try machdep.allowaperture=1 instead.


Philip Guenther


Re: sysctl and panic

2020-08-04 Thread Philip Guenther
On Tue, Aug 4, 2020 at 12:23 PM Sven F.  wrote:
...

> # sysctl -w  ddb.panic=1
> sysctl: ddb.panic: Operation not permitted

...

> Is this expected and can be set only early in boot ?
>

Yes, exactly.  Read the securelevel(7) or sysctl(2) manpages for details.



> is ddb.panic=0 still supported ?
>

Yes.

Philip Guenther


Re: perl hex possible bug

2020-07-21 Thread Philip Guenther
On Tue, Jul 21, 2020 at 3:12 PM Edgar Pettijohn 
wrote:

> I was playing around with the hex function in perl. So naturally I
> started with:
>
> perldoc -f hex
>
> Which showed me a few examples namely the following:
>
> print hex '0xAf'; # prints '175'
> print hex 'aF';   # same
> $valid_input =~ /\A(?:0?[xX])?(?:_?[0-9a-fA-F])*\z/
>
> However, I get the following output: (newlines added for clarity)
>
> laptop$ perl -e 'print hex '0xAf';'
> 373
>

You used the same quotes on the inside and out, so the "inner"
quotes actually never get to the perl!  The shell parses the argument to
perl to
print hex 0xAf

0xAf is a numeric literal whose value is 175.  The hex() function then
takes its argument (175) converts it to a string ("175") and interpretats
that string per its rules...as if you passed it "0x175" which equals 373.

If you use distinct quotes, you get the value you expect:

$ perl -le 'print hex "0xAf";'
175
$


> laptop$ perl -e 'print hex 'aF';'
> 175
>

That relies on the so-called poetry extension, where a bare word like aF is
treated as a string.  Turn on strict...

$ perl -Mstrict -le 'print hex Af;'
Bareword "Af" not allowed while "strict subs" in use at -e line 1.
Execution of -e aborted due to compilation errors.
$



> I'm guessing there is a bug here but not sure if its software or
> documentation.
>

No bug, just shell quoting traps.


Philip Guenther


Re: Potential grep bug?

2020-06-24 Thread Philip Guenther
Nope.  This is a grep of a single file, so procfile() must be overflowing
and this only 'fixes' it by relying on signed overflow, which is undefined
behavior, being handled in a particular way by the compiler.  So, luck
(which fails when the compiler decides to hate you).  There are more places
that need to change for the reported problem to be handled safely.

Philip Guenther


On Tue, Jun 23, 2020 at 9:58 PM Martijn van Duren <
open...@list.imperialat.at> wrote:

> This seems to fix the issue for me.
>
> OK?
>
> martijn@
>
> On Tue, 2020-06-23 at 19:29 -0700, Jordan Geoghegan wrote:
> > Hello,
> >
> > I was working on a couple POSIX regular expressions to search for and
> > validate IPv4 and IPv6 addresses with optional CIDR blocks, and
> > encountered some strange behaviour from the base system grep.
> >
> > I wanted to validate my regex against a list of every valid IPv4
> > address, so I generated a list with a zsh 1 liner:
> >
> >   for i in {0..255}; do; echo $i.{0..255}.{0..255}.{0..255} ; done |
> > tr '[:space:]' '\n' > IPv4.txt
> >
> > My intentions were to test the regex by running it with 'grep -c' to
> > confirm there was indeed 2^32 addresses matched, and I also wanted to
> > benchmark and compare performance between BSD grep, GNU grep and
> > ripgrep. The command I used:
> >
> > grep -Eoc
> >
> "((25[0-5]|(2[0-4]|1{0,1}[[:digit:]]){0,1}[[:digit:]])\.){3,3}(25[0-5]|(2[0-4]|1{0,1}[[:digit:]]){0,1}[[:digit:]])(/[1-9]|/[1-2][[:digit:]]|/3[0-2])?"
> >
> > My findings were surprising. Both GNU grep and ripgrep were able get
> > through the file in roughly 10 and 20 minutes respectively, whereas the
> > base system grep took over 20 hours! What interested me the most was
> > that the base system grep when run with '-c' returned '0' for match
> > count. It seems that 'grep -c' will have its counter overflow if there
> > are more than 2^32-1 matches (4294967295) and then the counter will
> > start counting from zero again for further matches.
> >
> >  ryzen$ time zcat IPv4.txt.gz | grep -Eoc
> "((25[0-5]|(2[0-4]|1{0,1}...
> >  0
> >  1222m09.32s real  1224m28.02s user 1m16.17s system
> >
> >  ryzen$ time zcat allip.txt.gz | ggrep -Eoc
> "((25[0-5]|(2[0-4]|1{0,1}...
> >  4294967296
> >  10m00.38s real11m40.57s user 0m30.55s system
> >
> >  ryzen$ time rg -zoc "((25[0-5]|(2[0-4]|1{0,1}...
> >  4294967296
> >  21m06.36s real27m06.04s user 0m50.08s system
> >
> > # See the counter overflow/reset:
> >  jot 4294967350 | grep -c "^[[:digit:]]"
> >  54
> >
> > All testing was done on a Ryzen desktop machine running 6.7 stable.
> >
> > The grep counting bug can be reproduced with this command:
> > jot 4294967296 | nice grep -c "^[[:digit:]]"
> >
> > Regards,
> >
> > Jordan
> >
> Index: util.c
> ===
> RCS file: /cvs/src/usr.bin/grep/util.c,v
> retrieving revision 1.62
> diff -u -p -r1.62 util.c
> --- util.c  3 Dec 2019 09:14:37 -   1.62
> +++ util.c  24 Jun 2020 06:46:52 -
> @@ -106,7 +106,8 @@ procfile(char *fn)
>  {
> str_t ln;
> file_t *f;
> -   int c, t, z, nottext;
> +   int t, z, nottext;
> +   unsigned long long c;
>
> mcount = mlimit;
>
> @@ -169,7 +170,7 @@ procfile(char *fn)
> if (cflag) {
> if (!hflag)
> printf("%s:", ln.file);
> -   printf("%u\n", c);
> +   printf("%llu\n", c);
> }
> if (lflag && c != 0)
> printf("%s\n", fn);
>
>


Re: Potential awk bug?

2020-06-06 Thread Philip Guenther
On Sat, Jun 6, 2020 at 5:08 PM Zé Loff  wrote:

> On Sat, Jun 06, 2020 at 03:51:58PM -0700, Jordan Geoghegan wrote:
> > I'm working on a simple awk snippet to convert the IP range data listed
> in
> > the Extended Delegation Statistics data from ARIN [1] and convert it into
> > CIDR blocks. I have a snippet that works perfectly fine on mawk and gawk,
> > but not on the base system awk. I'm 99% sure I'm not using any GNUisms,
> as
> > when I break the command up into two parts, it works perfectly.
> >
> > The snippet below does not work with base awk, but does work with gawk
> and
> > mawk: (Running on 6.6 -stable system)
> >
> >   awk -F '|' '{ if ( $3 == "ipv4" && $2 == "US") printf("%s/%d\n", $4,
> > 32-log($5)/log(2))}' delegated-arin-extended-latest.txt
> >
> >
> > The command does output data, but it also throws errors for certain
> lines:
> >
> >   awk: log result out of range
> >   input record number 94027, file delegated-arin-extended-latest.txt
> >   source line number 1
> >
> > Most CIDR blocks are calculated correctly, but about 10% of them have
> errors
> > (ie something that should calculated to be a /24 is instead calculated
> to be
> > a /30).
>
...

> I have no idea about what is going on, but FWIW I can reproduce this on
> i386 6.7-stable and amd64 6.7-current (well, current-ish, #232).
> Truncating the file to a single offending line produces the same result:
> log($5) is out of range.
>
> It appears to have something to do with the last field.  Removing it or
> changing some of its characters seems to work, e.g.:
>
>
> arin|US|ipv4|216.250.144.0|4096|20050503|allocated|5e58386636aa775c2106140445cf2c30
>
> arin|US|ipv4|216.250.144.0|4096|20050503|allocated|5a58386636aa775c2106140445cf2c30
> ^
> Fails on the first line but works on the second.
>

Hah!  Nice observation!

The last field of the first line looks kinda like a number in scientific
notation, but when awk internally tries to set up the fields it generates
an ERANGE error...and the global errno variable is left with that value.
Several builtins in awk, including log(), perform operations and then check
whether errno is set to EDOM or ERANGE but fail to clear errno beforehand.

The fix is to zero errno before all the code sequences that use the
errcheck() function, ala:

--- run.c   13 Aug 2019 10:45:56 -  1.44
+++ run.c   7 Jun 2020 03:14:38 -
@@ -26,6 +26,7 @@ THIS SOFTWARE.
 #define DEBUG
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1041,8 +1042,10 @@ Cell *arith(Node **a, int n) /* a[0] + a
case POWER:
if (j >= 0 && modf(j, ) == 0.0)   /* pos integer
exponent */
i = ipow(i, (int) j);
-   else
+   else {
+   errno = 0;
i = errcheck(pow(i, j), "pow");
+   }
break;
default:/* can't happen */
FATAL("illegal arithmetic operator %d", n);
@@ -1135,8 +1138,10 @@ Cell *assign(Node **a, int n)/* a[0] =
case POWEQ:
if (yf >= 0 && modf(yf, ) == 0.0) /* pos integer
exponent */
xf = ipow(xf, (int) yf);
-   else
+   else {
+   errno = 0;
xf = errcheck(pow(xf, yf), "pow");
+   }
break;
default:
FATAL("illegal assignment operator %d", n);
@@ -1499,12 +1504,15 @@ Cell *bltin(Node **a, int n)/* builtin
u = strlen(getsval(x));
break;
case FLOG:
+   errno = 0;
u = errcheck(log(getfval(x)), "log"); break;
case FINT:
modf(getfval(x), ); break;
case FEXP:
+   errno = 0;
    u = errcheck(exp(getfval(x)), "exp"); break;
case FSQRT:
+   errno = 0;
u = errcheck(sqrt(getfval(x)), "sqrt"); break;
case FSIN:
u = sin(getfval(x)); break;


Todd, are we up to date with upstream, or is this latent there too?


Philip Guenther


Re: Convert ffs1 to ffs2?

2020-05-20 Thread Philip Guenther
On Tue, May 19, 2020 at 10:50 PM Christer Solskogen <
christer.solsko...@gmail.com> wrote:

> Is that possible?
>

"Possible" is irrelevant.  Lots of things are _possible_ but not done.
"Has anyone actually written a tool to do this, and would you *trust* it?"
are the proper question...and the answer appears to be *no*.


Philip Guenther


Re: OpenBSD insecurity rumors from isopenbsdsecu.re

2020-05-11 Thread Philip Guenther
On Mon, May 11, 2020 at 6:09 PM  wrote:
...

> > And why would *you* care about those ways? If you can't tell us why you
> would care, how can we answer your _real_ question?


> Treat it as my secret, I want and that is why I ask because I can, I wish
> you tell me the answer without a knowledge of "why I ask",
> it is a very long discussion of answering by a question to question in
> your Jewish style, is not it?
>

I considered treating your questions in good faith, but then you said
this.  If my questions have you spouting this nonrational drivel them you
should stay away from OpenBSD because I am a committer and if you can't
trust my questions then you shouldn't trust my code.




Philip Guenther


Re: OpenBSD insecurity rumors from isopenbsdsecu.re

2020-05-11 Thread Philip Guenther
On Mon, May 11, 2020 at 4:28 PM  wrote:

> Is not a prohibition for USA citizens to work on OpenBSD cryptography
> software parts an indication of trust relationship between current OpenBSD
> and current USA?
>

I'm not sure what that sentence even means.  What would a "trust
relationship" between OpenBSD and "current USA" actually mean in terms of a
CHANGE IN BEHAVIOR?  Hell, what does "current USA" even _mean_?!?  Did you
mean to say "the US Federal Government"?  If so, what would "trust between
OpenBSD and the US Federal Government" actually mean in terms of a change
in behavior that you, i...@aulix.com, could actually detect?

And why would *you* care about those ways?  If you can't tell us why you
would care, how can we answer your _real_ question?

There is cryptographic software in OpenBSD that was developed in part by
someone who is/was a US citizen, in OpenSSH even, as a check of
copyright/license statements on source files show.  How does that change
your world view?


Philip Guenther


Re: Double fault trap in rtable_l2

2020-04-20 Thread Philip Guenther
On Sat, Apr 18, 2020 at 11:28 PM Thomas de Grivel 
wrote:

> I got this error last night on an OpenBSD 6.6-stable amd64 on which I
> recently enabled IKEv2 :
>
> > kernel: double fault trap, code=0
> > Stopped atrtable_l2+0x27: callq   srp_enter+0x4
>

That was the *complete* output from ddb?  Really?  Not a screen full of
backtrace after that showing that it has a very deep stack?

As you might guess from my questions: the #1 cause of a double fault traps
are kernel bugs causing deep recursion where it runs off the end of the
allocated stack, triggering a page fault exception which itself faults when
it can't write the stack frame for the page fault.  That "fault while
trying to fault" results in a double fault, which I configured to be
delivered on its own stack so that we can report this.

Fixing the deep recursion in this case would require you providing the full
stack trace to the list, so that the correct parties can see it and
identify where it's incorrectly looping.


Philip Guenther


Re: Openbsd supports pae?

2020-04-10 Thread Philip Guenther
Because it would be a total PITA now and in the future and benefit only
that small set of machines that have >4GB of memory but that can't run
64bit.

Since you like one-liner questions: why do you care?


Re: ffs details

2020-02-25 Thread Philip Guenther
On Tue, Feb 25, 2020 at 6:03 PM  wrote:

> Hi, I need some details about ffs, I read the kernel source but my c
> knowledge is very basic. I understood all about the superblock but my
> problem is understand how the files are allocated on the disk.
> Anyone could give me more details about files allocation ?
>

You should start from the paper that described the design and
implementation:
https://www.cs.berkeley.edu/~brewer/cs262/FFS.pdf

as linked to from https://en.wikipedia.org/wiki/Unix_File_System

Kirk McKusick has continued to revise and improve FFS; many of those
changes have been included in OpenBSD.  Check his biography and his
personal website for links to papers and presentations.


Philip Guenther


Re: is there a 2GB limit on amd64 link?

2020-02-05 Thread Philip Guenther
On Wed, Feb 5, 2020 at 7:38 PM  wrote:

> I am encountering a linker error when compiling with ports-gcc Fortran:
>
> ld: error: lbug2.f90:(function MAIN__: .text+0x80): relocation
> R_X86_64_PC32 out o
> f range: 2456507324 is not in [-2147483648, 2147483647]
>
> The code has several large arrays, the total size of which exceeds 2GB.
>
> Is this a linker issue, a gcc fortran issue, or a pebkac?
>

It's at least a gnu fortran issue: it needs to generate object code in a
larger "model" than it currently is.  I've never used gnu fortran, but it
might accept the -mcmodel=medium option like gcc and generate code
sequences for data symbols that don't limit them to the bottom 2GB (or to
within 2GB of the involved code, depending on gcc's choices in implementing
the model).

If it doesn't accept that option, then you'll need to work with the the
docs, mailling lists, etc of the upstream gnu fortran project about how to
have it generate code for the medium or large data models per the amd64 ABI.


Philip Guenther


Re: Readv and writev failing across ethernet

2019-12-24 Thread Philip Guenther
On Tue, Dec 24, 2019 at 8:14 PM Raymond, David 
wrote:

> Openmpi uses readv/writev.  I am beginning to think that the timeout
> and permission errors are legit and reflect real conditions.  What

does re do when it receives a write request when it is busy?
>

're' does not expose a device, but rather provides network interfaces that
are then used with sockets.  What sort of sockets does openmpi use?  What
sort of packet loss is generated on this network and what protocols does
openmpi use to recover from that?

(Lacking both dmesg or kdump, I'll probably have nothing further to
contribute to this thread)

Philip Guenther


Re: Re-organising partitions without re-installation

2019-12-23 Thread Philip Guenther
On Mon, Dec 23, 2019 at 3:10 PM Stuart Longland 
wrote:
...

> Where do you get `sysclean` from?  I don't seem to have it:
> > sjl-router# man sysclean
>
> > man: No entry for sysclean in the manual.
> > sjl-router# which sysclean
> > which: sysclean: Command not found.
>

$ pkg_info sysclean
Information for
http://mirrors.sonic.net/pub/OpenBSD/snapshots/packages/amd64/sysclean-2.8.tgz

Comment:
list obsolete files between OpenBSD upgrades

Description:
sysclean is a script designed to help remove obsolete files between OpenBSD
upgrades.

sysclean compares a reference root directory against the currently installed
files, taking files from both the base system and packages into account.

sysclean does not remove any files on the system. It only reports obsolete
filenames or packages using out-of-date libraries.

Maintainer: Sebastien Marie 

WWW: https://github.com/semarie/sysclean/

$


Re: Readv and writev failing across ethernet

2019-12-23 Thread Philip Guenther
On Mon, Dec 23, 2019 at 6:07 AM Ingo Schwarze  wrote:

> Theo de Raadt wrote on Sun, Dec 22, 2019 at 05:34:45PM -0700:
> > Philip Guenther  wrote:
> >> Somebody wrote:
>
> >>> The man pages for readv and writev don't document the possibility of
> >>> such errors.
>
> >> IMO, weird errnos from devices should be documented in the manpage for
> the
> >> device.  Consider the termios(4) manpage, for example.
>
> > I agree on that.  Otherwise the information-flood is too much.
> >
> > But I think some of our manual pages are a bit weak indicating there
> > are other errors not listed:
>
> Is the following good enough?
>
> Or are you saying that *all* section 2 and 3 manual pages should be
> reworded to say:  "FOOBAR may for example fail if:"?
>

Not all.  For section 2 it's the calls that take an fd that need to be
open-ended about errors.

Philip Guenther


Re: Disabling ACPI permanently

2019-12-23 Thread Philip Guenther
On Mon, Dec 23, 2019 at 5:10 AM Radek  wrote:

> I'm trying to permanently disable acpi doing the following steps[1].
> After the first reboot OS boots fine.
> After the second reboot acpi seems to be re-enabled at boot - I get [2].
> What Am I doing wrong?
>

First, you should also check whether there's a newer BIOS firmware for this
box, as there's a good chance Intel has fixed issues and issued a new one.
If so, installing that may totally resolve the issue.

If not, or if upgrading the firmware doesn't resolve this, then you should
next send a bug report to b...@openbsd.org using sendbug.  To get the most
data when you do so, disable _just_ the acpipci device (using boot -c)
instead of all of acpi and then run sendbug as root on that system.  The
bug report will then include the data from the ACPI tables, so that the
driver can be fixed to deal with this.

...

> acpipci0 at acpi0 PCI0panic: malloc: allocation too large, type = 33, size
> = 292057776136
>


Philip Guenther


Re: Readv and writev failing across ethernet

2019-12-23 Thread Philip Guenther
On Mon, Dec 23, 2019 at 5:04 AM Raymond, David 
wrote:

> The "timeout" error was numerically 60.  Curiously, boards with RTL
> 8111GR chips did not produce these errors, but those with RTL 8111H
> chips did.  Unfortunately, this chipset seems to be in a lot of newer
> motherboards.
>
> I didn't use ktrace/kdump.  The openmpi software returned the error
> presented by readv/writev.
>
> It sounds like the simplest solution at this point is to try
> non-Realtek pcie network cards.  Any suggestions?  How are Intel or
> Broadcom cards?
>

At this point I think you're clearly in the "device driver is buggy"
situation.  If this device has an in-tree driver (and not something you're
compiling locally into your kernel) then you should start a new thread
starting with a dmesg and a clear description of the involved hardware.


Philip Guenther


Re: Readv and writev failing across ethernet

2019-12-22 Thread Philip Guenther
On Sun, Dec 22, 2019 at 3:33 PM Raymond, David 
wrote:

> I am running openmpi-4.0.2 (self-compiled with GDS patches) on
> up-to-date 6.6 stable with a Go program that calls Clang MPI routines.
> With particular hardware (details provided if desired), readv and
> writev calls randomly fail with respectively "Timeout" and "Permission
> denied" errors for calls from one machine to another across the
> ethernet.


While "Permission denied" is the error message for EACCES, "Timeout" is not
a complete errno error message OpenBSD.  Has it been established that the
underlying readv/writev syscalls are returning particular errors by using
ktrace/kdump?

Next: if you have a device open, then the device driver *totally controls*
what errnos syscalls get.  If a device driver wanted to return EDOM
("Numerical argument out of domain") it totally could.  If you're getting
weird errno from a device, well, review the device source!


The errors don't occur between cores on the same machine.
>

THIS SHOULD NOT BE A SURPRISE: the net is not the same as your local
machine.


The man pages for readv and writev don't document the possibility of
> such errors.


IMO, weird errnos from devices should be documented in the manpage for the
device.  Consider the termios(4) manpage, for example.


Philip Guenther


Re: Unable to build OpenBSD 6.6 libc on beaglebone black

2019-12-07 Thread Philip Guenther
On Sat, Dec 7, 2019 at 5:10 PM Jacob Adams  wrote:

> When trying to build libc with the latest security patch applied on my
> beaglebone black, I was met with the following error:
>
> cc -O2 -pipe -g -Wimplicit -I/usr/src/lib/libc/include
> -I/usr/src/lib/libc/hidden -D__LIBC__
> -Werror-implicit-function-declaration
> -include namespace.h -Werror=deprecated-declarations -DAPIWARN -DYP
> -I/usr/src/lib/libc/yp -DSOFTFLOAT_FOR_GCC -I/usr/src/lib/libc/softfloat
> -I/usr/src/lib/libc -I/usr/src/lib/libc/gdtoa
> -I/usr/src/lib/libc/arch/arm/gdtoa
> -DINFNAN_CHECK -DMULTIPLE_THREADS -DNO_FENV_H -DUSE_LOCALE
> -I/usr/src/lib/libc
> -I/usr/src/lib/libc/citrus -DRESOLVSORT -DFLOATING_POINT -DPRINTF_WIDE_CHAR
> -DSCANF_WIDE_CHAR -DFUTEX  -MD -MP  -c
> /usr/src/lib/libc/db/btree/bt_close.c -o
> bt_close.o
> In file included from /usr/src/lib/libc/db/btree/bt_close.c:37:
> /usr/src/lib/libc/hidden/stdlib.h:68:14: error: use of undeclared
> identifier
> 'calloc_conceal'
> PROTO_NORMAL(calloc_conceal);
>  ^
> /usr/src/lib/libc/hidden/stdlib.h:109:14: error: use of undeclared
> identifier
> 'malloc_conceal'
> PROTO_NORMAL(malloc_conceal);
>  ^
> 2 errors generated.
> *** Error 1 in /usr/src/lib/libc (:39 'bt_close.o': @cc -O2
> -pipe -g
> -Wimplicit -I/usr/src/lib/libc/include -I/usr/src/lib/libc/...)
>
>
> I unpacked a copy of the 6.6 src.tar.gz that I had downloaded a while ago
> in
> /usr/src, and then updated to the stable branch with:
>
> cvs -qd anon...@anoncvs.ca.openbsd.org:/cvs up -Pd -rOPENBSD_6_6
>
> I then ran:
>
> cd lib/libc
> make obj
> make
>
> and encountered this error.
>
> Clearly I've done something wrong, could someone please point me to my
> mistake?
>

This box didn't have the 6.6 include files installed.  This is demonstrated
by the lack of a calloc_conceal() declaration in your
/usr/include/stdlib.h. You can't just build 6.6 pieces without their
dependent pieces being present.

Now, unless you can explain _exactly_ how you ended up with this franken
system (66 kernel but not include files?) and come up with a plan to get it
out of the franken-state into a normal "matched kernel and userland,
including compilation environment", then my recommendation would be to grab
the 6.6 bsd.rd, boot to it, and (u)pgrade to 6.6 being sure to include the
comp66 set in your install, and _then_ try building things...or just run
syspatch.


Philip Guenther


Re: How to achieve O_TTY_INIT when opening a USB modem?

2019-11-24 Thread Philip Guenther
On Sun, Nov 24, 2019 at 7:53 PM Jeffrey Walton  wrote:

> On Sun, Nov 24, 2019 at 10:10 PM Philip Guenther 
> wrote:
> >
> > On Sun, Nov 24, 2019 at 3:11 AM Jeffrey Walton 
> wrote:
> >>
> >> I am struggling to get a USB modem and terminal configured properly
> >> under OpenBSD. The same code on Linux is fine. The symptom I am seeing
> >> is a hung read() after issuing ATZ\r to the modem.
> >>
> >> I'm guessing there's an uninitialized field in my struct termios tty.
> >
> > I'm not sure what you mean by that.  Do you mean you're concerned that
> you're you making a tcsetattr(3) call on an incompletely initialized
> structure?  Or do you mean you're concerned that the initial configuration
> of the tty provided by the kernel is in a "not good" state?
>
> I think cfmakeraw is not initializing the structure properly. It is an
> intermittent failure.
>

This code is misusing cfmakeraw(3): it needs to call tcgetattr(3) on the
tty fd and only call cfmakeraw() on the termios structure that tcgetattr()
has filled in.

(There may be other problems; I only reviewed enough to see that it was
violating the rule I mentioned in my previous post.  The _only_ portable
way to initialize a struct termios is to use tcgetattr()!)


Philip Guenther


Re: How to achieve O_TTY_INIT when opening a USB modem?

2019-11-24 Thread Philip Guenther
On Sun, Nov 24, 2019 at 3:11 AM Jeffrey Walton  wrote:

> I am struggling to get a USB modem and terminal configured properly
> under OpenBSD. The same code on Linux is fine. The symptom I am seeing
> is a hung read() after issuing ATZ\r to the modem.
>
> I'm guessing there's an uninitialized field in my struct termios tty.
>

I'm not sure what you mean by that.  Do you mean you're concerned that
you're you making a tcsetattr(3) call on an incompletely initialized
structure?  Or do you mean you're concerned that the initial configuration
of the tty provided by the kernel is in a "not good" state?


> The latest Posix provides O_TTY_INIT to ensure a terminal is in a good
> configuration, but OpenBSD does not recognize it.
>
What is the equivalent under OpenBSD?


OpenBSD, like all BSDs, does not require anything special to be done to
initialize a tty on first open.  We can (and I guess we should at this
point) define O_TTY_INIT to be zero.


How do I achieve O_TTY_INIT when
> using a struct termios tty?
>

Before calling tcsetattr(3) you should call tcgetattr(3) to get the tty
device's current settings and only alter the setting you care about.


Philip Guenther


Re: Value of eax register after BIOS interrupt call from boot(8)

2019-11-09 Thread Philip Guenther
On Friday, November 8, 2019, Theo de Raadt  wrote:

> Philip Guenther  wrote:
>
> > No, it should be the other way, moving the “clear NT flag” block down
> after
> > the “save registers into save area” block
>
> Ah.
>
> Index: arch/amd64/stand/libsa/gidt.S
> ===
> RCS file: /cvs/src/sys/arch/amd64/stand/libsa/gidt.S,v
> retrieving revision 1.11
> diff -u -p -u -r1.11 gidt.S
> --- arch/amd64/stand/libsa/gidt.S   27 Oct 2012 15:43:42 -
> 1.11
> +++ arch/amd64/stand/libsa/gidt.S   9 Nov 2019 06:50:57 -
> @@ -423,14 +423,6 @@ intno  = . - 1
> movl%edx, 0x9*4(%esp)
> movb%bh , 0xe*4(%esp)
>
> -   /* clear NT flag in eflags */
> -   /* Martin Fredriksson  */
> -   pushf
> -   pop %eax
> -   and $0xbfff, %eax
> -   push%eax
> -   popf
> -
> /* save registers into save area */
> movl%eax, _C_LABEL(BIOS_regs)+BIOSR_AX
> movl%ecx, _C_LABEL(BIOS_regs)+BIOSR_CX
> @@ -438,6 +430,13 @@ intno  = . - 1
> movl%ebp, _C_LABEL(BIOS_regs)+BIOSR_BP
> movl%esi, _C_LABEL(BIOS_regs)+BIOSR_SI
> movl%edi, _C_LABEL(BIOS_regs)+BIOSR_DI
> +
> +   /* clear NT flag in eflags */
> +   pushf
> +   pop %eax
> +   and $0xbfff, %eax
> +   push%eax
> +   popf
>
> pop %gs
> pop %fs
> Index: arch/i386/stand/libsa/gidt.S
> ===
> RCS file: /cvs/src/sys/arch/i386/stand/libsa/gidt.S,v
> retrieving revision 1.36
> diff -u -p -u -r1.36 gidt.S
> --- arch/i386/stand/libsa/gidt.S31 Oct 2012 13:55:58 -
> 1.36
> +++ arch/i386/stand/libsa/gidt.S9 Nov 2019 06:51:29 -
> @@ -426,14 +426,6 @@ intno  = . - 1
> movl%edx, 0x9*4(%esp)
> movb%bh , 0xe*4(%esp)
>
> -   /* clear NT flag in eflags */
> -   /* Martin Fredriksson  */
> -   pushf
> -   pop %eax
> -   and $0xbfff, %eax
> -   push%eax
> -   popf
> -
> /* save registers into save area */
> movl%eax, _C_LABEL(BIOS_regs)+BIOSR_AX
> movl%ecx, _C_LABEL(BIOS_regs)+BIOSR_CX
> @@ -441,6 +433,13 @@ intno  = . - 1
> movl%ebp, _C_LABEL(BIOS_regs)+BIOSR_BP
> movl%esi, _C_LABEL(BIOS_regs)+BIOSR_SI
> movl%edi, _C_LABEL(BIOS_regs)+BIOSR_DI
> +
> +   /* clear NT flag in eflags */
> +   pushf
> +   pop %eax
> +   and $0xbfff, %eax
> +   push%eax
> +   popf
>
> pop %gs
> pop %f
>

Ok guenther@


Re: Value of eax register after BIOS interrupt call from boot(8)

2019-11-08 Thread Philip Guenther
On Friday, November 8, 2019, Theo de Raadt  wrote:

> Philip Guenther  wrote:
>
> > Since we're unlikely to do _more_ with BIOS calls in the boot loader, my
> > inclination would be to eliminate the structure value and the code that
> > sets it (incorrectly).  Opinions?
>
> I dunno, my crystal ball provides a more cynical outlook.
>
> How about we just repair by swapping the blocks as you propose, then
> noone gets surprised down the road if they try to use the bios-interface
> API's full functionality.
>
> The bootblocks don't shrink, but they don't grow either.
>
> Is this the right diff?  I'm deleting the name which is in the commitlogs
> since that isn't our style.

...

> --- sys/arch/amd64/stand/libsa/gidt.S   27 Oct 2012 15:43:42 -
> 1.11
>
+++ sys/arch/amd64/stand/libsa/gidt.S   9 Nov 2019 03:57:11 -
> @@ -417,19 +417,18 @@ intno = . - 1
> .byte   0xb8
>  2: .long   0x90909090
>
> -   /* pass BIOS return values back to caller */
> -   movl%eax, 0xb*4(%esp)
> -   movl%ecx, 0xa*4(%esp)
> -   movl%edx, 0x9*4(%esp)
> -   movb%bh , 0xe*4(%esp)
> -
> /* clear NT flag in eflags */
> -   /* Martin Fredriksson  */
> pushf
> pop %eax
> and $0xbfff, %eax
> push%eax
> popf


No, it should be the other way, moving the “clear NT flag” block down after
the “save registers into save area” block

Philip


Re: vi in ramdisk?

2019-11-07 Thread Philip Guenther
On Thu, Nov 7, 2019 at 9:57 PM Brennan Vincent 
wrote:

> I am asking this out of pure curiosity, not to criticize or start a debate.
>
> Why does the ramdisk not include /usr/bin/vi by default? To date,
> it is the only UNIX-like environment I have ever seen without some form
> of vi.
>

The ramdisk space is extremely tight.  We include what we feel is
necessary, PUSHING OUT other stuff as priorities shift.  If you have watch
the commits closely, you would have seen drivers vanish from the ramdisks
on tight archs as new functionality was added.

Given what we want people to use the ramdisks for (installing,
reinstalling, upgrading, fixing boot and set issues), vi is not necessary,
while other functionality and drivers extend their applicability.  We will
keep the latter and not include the former.


Philip Guenther


Re: Value of eax register after BIOS interrupt call from boot(8)

2019-11-07 Thread Philip Guenther
On Thu, Nov 7, 2019 at 9:31 AM Julius Zint  wrote:

> the following code snipped is from sys/arch/amd64/stand/libsa/gidt.S
>
> /* pass BIOS return values back to caller */
> movl%eax, 0xb*4(%esp)
> movl%ecx, 0xa*4(%esp)
> movl%edx, 0x9*4(%esp)
> movb%bh , 0xe*4(%esp)
>
> /* clear NT flag in eflags */
> /* Martin Fredriksson  */
> pushf
> pop %eax
> and $0xbfff, %eax
> push%eax
> popf
>
> /* save registers into save area */
> movl%eax, _C_LABEL(BIOS_regs)+BIOSR_AX
> movl%ecx, _C_LABEL(BIOS_regs)+BIOSR_CX
> movl%edx, _C_LABEL(BIOS_regs)+BIOSR_DX
> movl%ebp, _C_LABEL(BIOS_regs)+BIOSR_BP
> movl%esi, _C_LABEL(BIOS_regs)+BIOSR_SI
> movl%edi, _C_LABEL(BIOS_regs)+BIOSR_DI
>
> These instructions are being executed after a BIOS interrupt. If i read
> correctly, than (BIOS_regs)+BIOSR_AX contains the contents of the eflags
> processor register and not of %eax. Is this intended or should it contain
> the value of %eax?
>

Yeah, it looks like it's in the wrong order.  The trick, of course, is that
nothing actually examines BIOS_regs.biosr_ax, so the fact that the wrong
value is saved there hasn't mattered.

Since we're unlikely to do _more_ with BIOS calls in the boot loader, my
inclination would be to eliminate the structure value and the code that
sets it (incorrectly).  Opinions?


Philip Guenther


Re: this assembly example works in linux, netbsd - but not in openbsd, why?

2019-10-29 Thread Philip Guenther
On Tue, 29 Oct 2019, Guild Navigator wrote:
> Program prints first two strings directly.
> But it does not print the third string (1st array string).
> 
> And debugging says why.
> The address of msg1 and msg2 is not stored correctly in the array.
> So when I access the address of msg1 from the array:
> movq array (%rip), %rsi
> it is NOT the address of msg1.
> 
> I dont know if it is a linker problem?
> I could kind of do "manual relocation" of sorts to manually
> correct the addresses put in the array.

In general, if you're going to exclude all the C startup bits that the 
operating system has provided, then you've signed up for handling all the 
possible ELF bits yourself.  If you haven't boned up on ELF and its 
variations yet, then you should do so, if just so you can recognize when 
stuff has gone wrong.

In particular, the OpenBSD linker defaults to PIE.  To quote 
clang-local(1) (similar text is in gcc-local(1)):
 -   clang will generate PIE code by default, allowing the system to load
 the resulting binary at a random location.  This behavior can be
 turned off by passing -fno-pie to the compiler and -nopie to the
 linker.  It is also turned off when the -pg flag is used.

This means that yes, your executable has relocations.  You've left out the 
rcrt0.o code that OpenBSD provides that handles such relocations, 
therefore you must either do the relocation processing yourself, or invoke 
the linker with the -nopie flag to instead generate a staticly positioned 
binary.

If you want to handle the relocations yourself, then eyeball the code in 
/usr/src/lib/csu/, particularly boot.h and amd64/md_init.h, and read the 
ELF spec and the amd64 ABI spec for structure definitions and similar.


> But what would be the OpenBSD correct way to
> write such simple print-from-the-array-of-strings program?

The answer to that literal question is "write it in C", but you obviously 
have another requirement of "...in ASM".

There are *zero* places in OpenBSD where we write pure assembler programs.  
There are only two places where we do process bootstrap bits, lib/csu and 
libexec/ld.so/, and for both of those we do _just_ enough ASM to make 
calling a limited subset of C possible, and then call a C routine to do 
self-relocation.  Improving the C version of the self-relocation code is 
*much* faster than trying improve N assembly versions.  Heck, I did so 
just this month.

ASM is cool for stuff that C can't do, but if C can do it the developer's 
time (and the time of future openbsd maintainers!) is much better spent in 
C than in ASM.  I've touched ASM on every single current OpenBSD arch, so 
I understand the high cost of doing that when it _has_ been necessary and 
I have no interest in borking around in ASM for stuff C can reasonably do.


Philip Guenther



Re: help with understanding __BSD_VISIBLE

2019-07-13 Thread Philip Guenther
On Fri, Jul 12, 2019 at 10:39 AM Allan Streib  wrote:

> Probably an elementary question stemming from my lack of C expertise.
>
> I am trying to complile some C code that includes its own "bcrypt"
> function. This is conflicting with the declaration in pwd.h.
>
> error: conflicting types for 'bcrypt'
> int bcrypt(char *, const char *, const char *);
> ^
> /usr/include/pwd.h:112:8: note: previous declaration is here
> char*bcrypt(const char *, const char *);
>
> In pwd.h I see that the bcrypt declaration is wrapped in a #if block:
>
...

> __POSIX_VISIBLE is defined as 200809, so __BSD_VISIBLE should be 0 and
> the pwd.h declaration for bcrypt should be skipped?
>

There are four options here:
1) change the software to not use the name 'bcrypt' for a non-static
function.  OpenBSD has only been using it for 15 years...

2) If you're going to use the name bcrypt, then don't do so in files that
pull in .  (This would be a last choice in my book, as that's a
fragile setup)

3) *IF* the software was written to only rely on the interfaces of some
version of the POSIX standard, then follow the compilation rules described
in that standard.  You mention POSIX 2008, so perhaps this software would
build when following those rules, passing the compiler
-D_POSIX_C_SOURCE=200809L to only declare the symbols from that standard

Note that application software should *never* define macros matching the
pattern __*_VISIBLE such as __BSD_VISIBLE.  Those are in the reserved
namespace and on OpenBSD they are set by  based on the macros
specified in the various standards for use by application and build
software.  The ones you should care about are:
  _POSIX_C_SOURCE -- standardized: specifies a POSIX version
  _XOPEN_SOURCE-- standardized: specifies a POSIX + XSI version
  _ISOC11_SOURCE-- adds C2011 interfaces
  _BSD_SOURCE     -- adds all BSD and obsoleted interfaces

Make sense?

Philip Guenther


Re: Putting fifos in subshells into the background

2019-06-12 Thread Philip Guenther
On Wed, Jun 12, 2019 at 12:54 AM Richard Ulmer 
wrote:

> while making the Kakoune editor work on OpenBSD, I encountered some
> strange behaviour [1]. This little script doesn't work with the OpenBSD
> sh, but works at least with dash, bash and zsh:
>
> mkfifo 'testfifo'
> cat "$(
> ( printf 'foo\n' > testfifo 2>&1 ) > /dev/null 2>&1 &
> printf 'testfifo'
> )"
>
> I can make it work for all the mentioned shells like this:
>
> mkfifo 'testfifo'
> cat "$(
> ( ( printf 'foo\n' > testfifo 2>&1 ) & ) > /dev/null 2>&1
> printf 'testfifo'
> )"
>
> Can someone explain or justify the behaviour of the OpenBSD sh, or do
> you think this is a bug?
>

This is a bug, almost certainly from an over-zealous optimization in the
logic handling subshells where the possibility that an inner redirection
could be blocking wasn't taken into account when it tries to avoid
unnecessary forks.

Sorry, I don't have a fix in my back pocket.  Your workaround is good; I'll
note the intermediate set of parens can also be braces, which would let you
avoid the otherwise necessary whitespace between open-parens if that grates
on your soul like it does mine.  :)


Philip Guenther


Re: hw.ncpu=1, hw.ncpuonline=1, hw.ncpufound=4

2019-05-27 Thread Philip Guenther
On Mon, May 27, 2019 at 6:18 PM Ipsen S Ripsbusker <
ips...@ripsbusker.no.eu.org> wrote:

> Aaron Mason writes:
> > Looks to me like you're not running bsd.mp.  A dmesg would clear this
> up.
>
> Indeed I was not running bsd.mp. I switched to bsd.mp, and then 2 of 4
> CPUs were online. Then I set "sysctl hw.smt = 1" to get all 4 online.
>

This is a side-point, but you do understand that those extra 2 aren't full
CPUs, they're just the cardboard mockups that Intel sold you, and that if
you run any untrusted code (including javascript in a web-browser) that
those fake CPUs leak data across process boundaries, right?



> Otto Moerbeek writes:
> > On Sun, Apr 07, 2019 at 01:54:35PM +, Ipsen S Ripsbusker wrote:
> > > ...
> > > Also, now that I have realized this, I have a theory about a related
> > > issue, and I would like to know how I can debug it. I am using softraid
> > > CRYPTO, and I have found that accessing the disk with one process will
> > > interrupt the other processes accessing the disk. Now I wonder this
> > > happens because the sole core must switch encryption/decription
> > > processes for the different files. How could I determine whether this
> is
> > > indeed happening?
>

Can you explain in more detail what you were observing when you said "found
that accessing the disk with one process will interrupt the other processes
accessing the disk"?  The word 'interrupt' is overloaded in computing and
what you saw may be a real problem with device support, or it may be
completely innocuous, something which you should be ignoring.

Philip Guenther


Re: Purpose of primary and secondary user groups

2019-01-13 Thread Philip Guenther
On Sun, Jan 13, 2019 at 6:13 AM Bryan Harris  wrote:

> Is there also a difference when creating a file in a folder with set GID
> bit on that folder and owned by secondary group? I think in normal
> behavior, if folder allows a user to create a file (sec. group w/ 770
> perm.) then the new file group will not take the group of the folder but
> will take the group of the user's primary group. But if you have set GID
> bit then the new file will take the group of the folder it's in (which
> will be one of the user's secondary groups).
>
> I thought in OpenBSD there is also a flag to mount the filesystem to
> always do this regardless of set GID but I can't remember. I don't see
> it in the man page so maybe with all of this I'm really thinking of
> Linux but I can't remember.
>

Nope.  OpenBSD always uses the BSD behavior.  The use of the SGID bit on
directories to request BSD behavior was an addition in SystemV-based
systems when enough of their devs and users yelled at them to Not Be Stupid
And Provide the Better Behavior.  I'm not sure who or when first added the
mount option.  Linux certainly has both of those, but is not the only one.


Philip Guenther


Re: demystifying trap

2019-01-12 Thread Philip Guenther
On Sat, Jan 12, 2019 at 10:49 AM Predrag Punosevac 
wrote:

> Could one of peple with some rudimental knowledge of kernel interals
> tell me what am I seeing here
>
> Jan 12 13:42:37 oko /bsd: trap [mmonit-bin]89524/427284 type 6: sp
> 122488ae75d0 not inside 7f7fffbf4000-7f7f4000
>

'sp' means "stack pointer" in here.  The kernel is killing your process
because it moved its stack pointer outside the memory which was mapped with
MAP_STACK.  This is most often seen with userspace thread implementations
that haven't been updated to use MAP_STACK when allocating memory for
thread stacks.


Philip Guenther


Re: Porting some software to OpenBSD

2019-01-05 Thread Philip Guenther
On Sat, Jan 5, 2019 at 7:25 PM Adam Steen  wrote:

> I have a question about string (printf) formatting.
>
> I have a variable
>
> 'uint64_t freq'
>
> which is printed with
>
> 'log(DEBUG, "Solo5: clock_init(): freq=%lu\n", freq);'
>
> but am getting the following error
>
> '
> error: format specifies type 'unsigned long' but the argument has type
> 'uint64_t' (aka 'unsigned long long') [-Werror,-Wformat]
> freq);
> ^~~~
> 1 error generated.
> '
>
> The easy fix is to change the format to '%llu', but this brakes FreeBSD
> and Linux. Am i missing something or should i be investigating the log
> implementation?
>

Option 1)
log(DEBUG, "Solo5: clock_init(): freq=%llu\n", (unsigned long
long)freq);

Option 2)
#include 
log(DEBUG, "Solo5: clock_init(): freq=%"PRIu64"\n", freq);

Software native to OpenBSD uses option 1 when necessary.


Philip Guenther


Re: Purpose of primary and secondary user groups

2018-12-29 Thread Philip Guenther
On Sat, Dec 29, 2018 at 11:29 AM Ipsen S Ripsbusker <
ip...@ripsbusker.no.eu.org> wrote:

> Aside from compatibility, what is the purpose of primary groups,
> compared to secondary groups?
>
> Said otherwise, why do we have both primary and secondary groups
> rather than only secondary groups?
>
> Yet another phrasing: Why do I need to set a primary group?
>

Secondary groups can only be set, all at once, when running as root (e.g.,
login, sshd), while the primary group can be altered by setgid binaries and
then switched among using set*gid(2).

For filesystem objects like files and directories, the BSD behavior is for
the object to get its group from the directory in which it was created,
ignoring the groups of the process that created it.  On more SysV-like
systems the default is to take the primary group of the process that
created it.  However, for objects that exist in the kernel but not the
filesystem such as pipes, sockets, and SysV shared memory segments,
semaphores, and message queues, the common behavior is to take the primary
group of the process that created it.  This  doesn't have much effect other
than fstat() for pipes and sockets, but for SysV stuff it affects what
operations processes can perform.


Philip Guenther


Re: I can't make build stable 6.4

2018-12-22 Thread Philip Guenther
On Sat, Dec 22, 2018 at 10:29 AM Krzysztof Strzeszewski 
wrote:

> I change permission:
>
> chown build /usr/src/lib/libcrypto/obj/v3_info.o.d
> chown build /usr/src/lib/libcrypto/obj/v3_info.po.d
> chown build /usr/src/lib/libcrypto/obj/v3_info.so.d
> chown build /usr/src/lib/libcrypto/obj/v3_purp.so.d
>
> end it's ok.
>
> it is a bug end 4 files have bad permission for user root instead build...
>

Many of us run builds and haven't seen this.  The source files for those
have been around for over a decade and haven't been updated recently, so
this wasn't source files updated in the middle of the builds.

Without know the exact sequence of operations on this tree it would be hard
to diagnose how this happened.

"When in doubt, rm -rf /usr/obj/* before building"

Philip Guenther


Re: Is HPET timer accessible in userland?

2018-12-13 Thread Philip Guenther
On Thu, Dec 13, 2018 at 4:58 PM Paul Swanson  wrote:

> Is the HPET timer on AMD64 available to
> developers in OpenBSD user land?
>

No.

The CPU TSC is available to userspace.  Note you may need to use the RDTSCP
instruction on MP boxes (and VMs...) where the TSC is not consistent across
CPUs, real or virtual.


Philip Guenther


Re: netstat *:* udp sockets

2018-12-13 Thread Philip Guenther
On Thu, Dec 13, 2018 at 10:40 AM Ted Unangst  wrote:

> netstat -an tells me I am listening to all the udp.
>
> Active Internet connections (including servers)
> Proto   Recv-Q Send-Q  Local Address  Foreign Address
> (state)
> udp  0  0  *.**.*
> udp  0  0  127.0.0.1.53   *.*
> udp  0  0  *.**.*
> udp  0  0  *.5353 *.*
> udp  0  0  *.**.*
>
> What are those *.* sockets doing? How can you listen to all the ports?
>

Those are just UDP sockets on which connect() hasn't been called and that
aren't in the middle of a recvfrom()  or recvmsg(), no?


And, perhaps more directly, how would I block this in pf.conf?
>

Excellent choice, blocking dhclient from receiving the leases that it
requests.
"What problem are you trying to solve?"

Philip Guenther


Re: Core Dev?

2018-12-04 Thread Philip Guenther
On Tue, Dec 4, 2018 at 2:47 AM Marc Espie  wrote:

> (note that Antoine is the 2nd most prolific contributor to OpenBSD in terms
> of # of commits)
>

Sure, Marc, but that's just because Antoine is such a high caliber mole
that 22 years and 22k commits in order to backdoor AWS systems that were
_clearly_ going to happen is completely believable.

Philip Guenther


Re: statethreads crashes in ld on 6.4

2018-12-03 Thread Philip Guenther
On Mon, 3 Dec 2018, Claus Assmann wrote:
> Here's the dissambler output and the ktrace output follows.
> Unfortunately I don't know enough about this to figure out
> what is wrong, hopefully someone else can (or tell me which
> other information is still needed). TIA!

A close read of the ktrace output points to the problem:

...
>  65554 server   GIO   fd 2 wrote 89 bytes
>"[03/Dec/2018:08:28:29] INFO: process 0 (pid 65554): starting 8 
> threads on localhost:1234
>"

So it's just about to create its eight (userspace) threads...


>  65554 server   CALL  
> mmap(0,0x12000,0x3,0x1002,-1,0)
>  65554 server   RET   mmap 21771804393472/0x13cd24aac000
>  65554 server   CALL  
> mmap(0,0x12000,0x3,0x1002,-1,0)
>  65554 server   RET   mmap 21771451404288/0x13cd0fa09000
>  65554 server   CALL  
> mmap(0,0x12000,0x3,0x1002,-1,0)
>  65554 server   RET   mmap 21773345935360/0x13cd808cd000
>  65554 server   CALL  
> mmap(0,0x12000,0x3,0x1002,-1,0)
>  65554 server   RET   mmap 21774756491264/0x13cdd4a03000
>  65554 server   CALL  
> mmap(0,0x12000,0x3,0x1002,-1,0)
>  65554 server   RET   mmap 21774604423168/0x13cdcb8fd000
>  65554 server   CALL  
> mmap(0,0x12000,0x3,0x1002,-1,0)
>  65554 server   RET   mmap 21773142749184/0x13cd74707000
>  65554 server   CALL  
> mmap(0,0x12000,0x3,0x1002,-1,0)
>  65554 server   RET   mmap 21773994246144/0x13cda7314000
>  65554 server   CALL  
> mmap(0,0x12000,0x3,0x1002,-1,0)
>  65554 server   RET   mmap 21774606540800/0x13cdcbb02000

Eight mmaps, presumably one per thread...


>  65554 server   CALL  kbind(0x7f7d4fa8,24,0x8a4abe18ba78cb4a)
>  65554 server   RET   kbind 0

Okay, so this kbind() is by the original thread.  The first argument to 
kbind() happens to be a buffer which is always on the current thread's 
stack.  All is good here.

...
>  65554 server   CALL  kbind(0x13cd24abcc48,24,0x8a4abe18ba78cb4a)
>  65554 server   PSIG  SIGSEGV SIG_DFL addr=0x0 trapno=0
>  65554 server   NAMI  "server.core"

And now this kbind() call blows up: the address is not on the original 
thread's stack but in one of those mmap()s...but those mmap()s were not 
marked as stacks by including MAP_STACK.  To quote the "Security 
improvements" section of https://www.openbsd.org/64.html

* Implemented MAP_STACK option for mmap(2). At pagefaults and
  syscalls the kernel will check that the stack pointer points
  to MAP_STACK memory, which mitigates against attacks using
  stack pivots.


To confirm, if you check your dmesg(8) or /var/log/messages you should 
find the kernel complaining something like
   syscall [server]65554/### sp 13cd24a## not inside 0x7f7f###-0x7f7f###


Philip Guenther



Re: statethreads crashes in ld on 6.4

2018-12-02 Thread Philip Guenther
On Sun, Dec 2, 2018 at 7:51 PM Edgar Pettijohn 
wrote:

> Sorry just saw it came with some examples. Testing with the `lookupdns'
> program
> ended with a Bus error (core dumped). Here is gdb output:
>
> Core was generated by `lookupdns'.
> Program terminated with signal SIGBUS, Bus error.
> #0  _longjmp () at /usr/src/lib/libc/arch/amd64/gen/_setjmp.S:99
> 99  1:  movq%r11,0(%rsp)
> (gdb) bt
> #0  _longjmp () at /usr/src/lib/libc/arch/amd64/gen/_setjmp.S:99
> Backtrace stopped: Cannot access memory at address 0xb044815db732800f
>

Crashing on _longjmp() would suggest it's not happy with OpenBSD's
setjmp/longjmp XOR cookies, but those have been in for a while.  If
statethreads were working for Claus with 6.3 then he's hitting something
different.


Philip


Re: 6.4-release tset(1) really slow, what have I missed?

2018-12-02 Thread Philip Guenther
On Sun, Dec 2, 2018 at 2:15 PM Adam Thompson  wrote:

> I've successfully installed OpenBSD 6.4-RELEASE at OVH, but I'm noticing
> one thing there that's different from everywhere else I've used 6.4.
>
> tset(1) takes approximately 12-15 seconds to execute, (almost) every
> time.
>
> On a DigitalOcean VPS running 6.3-STABLE (via openup) tset sensibly
> takes about 1 or 2 seconds:
>athom...@mail.athompso.net:~$ time tset -s
>TERM=xterm;
>0m01.01s real 0m00.00s user 0m00.01s system
>athom...@mail.athompso.net:~$ uname -r
>6.3
>
> On the OVH VPS running 6.4-STABLE (via openup), the same command takes
> 15 seconds:
>athom...@mail2.athompso.net:~$ time tset -s
>TERM=xterm;
>0m15.19s real 0m00.00s user 0m00.01s system
>athom...@mail2.athompso.net:~$ uname -r
>6.4
>
>
> That's from two SSH sessions from the same client with the same
> parameters.
>
> I've captured ktrace(1) output, which shows tset(1) doing, well,
> nothing:
> ...
>   57429/443422  tset 0.035908 CALL
> kbind(0x7f7f7678,24,0xecf2201fc1aab9ca)
>   57429/443422  tset 0.035933 RET   kbind 0
>   57429/443422  tset 0.035950 CALL
> nanosleep(0x7f7f7760,0x7f7f7750)
>   57429/443422  tset 0.035967 STRU  struct timespec { 1 }
>   57429/443422  tset 15.809238 STRU  struct timespec { 0 }
>   57429/443422  tset 15.809272 RET   nanosleep 0
>   57429/443422  tset 15.809303 CALL
> kbind(0x7f7f76c8,24,0xecf2201fc1aab9ca)
>   57429/443422  tset 15.809380 RET   kbind 0
> ...
>
> I don't think this is a bug in 6.4, it's clearly environment-specific...
> but I have no idea what on earth could be causing it.
>

It requested a sleep of 1 second and 15 seconds passed.  That's a kernel
timetracking issue, so the output of "sysctl kern.timecounter" would be a
good place to start.  Is this is an MP kernel using the CPU TSC, but on a
VM where the virtual CPU's TSCs aren't in sync?


Philip Guenther


Re: statethreads crashes in ld on 6.4

2018-12-02 Thread Philip Guenther
On Sat, Dec 1, 2018 at 6:34 AM Claus Assmann 
wrote:

> statethreads (http://state-threads.sourceforge.net/) crashes on
> OpenBSD 6.4/amd64 (release) with an error in ld (see below); it
> works fine on previous OpenBSD versions.  Do I have to set some
> "special" cc/ld options to make this work?


That'll depend on what the problem turns out to be, of course...


> Or are patches to
> statehreads required (there doesn't seem to be a port for it,
> otherwise I would try that)?
>

Not that I know of.



> #0  0x0c0b0980db08 in _dl_bind (object=0xc0a85cff400, index=)
>from /usr/libexec/ld.so
> (gdb)
>

Since ld.so is relinked on each boot, just an address doesn't really show
what died.  The disassembly up to that address would help.
More important is knowing what signal killed the process.  ktracing it and
seeing what the syscalls leading up to signal were (and what extra info was
in the signal) tells a lot.


Philip Guenther


Re: why thread is not usable in perl5 of OpenBSD6.4?

2018-11-25 Thread Philip Guenther
On Sun, Nov 25, 2018 at 1:57 AM 岡本健二  wrote:

> I have to use thread on the perl5 of OpenBSD 6.4.
> However, it was disabled on the distribution.
>

Hmm, is this something that worked in previous releases, or is something
that you've only tried in OpenBSD 6.4?

Off-hand, it's still disabled by default in the Configure script that perl
people ship, and I don't see anything in the OpenBSD bits to override their
choice.



> I tried to make the thread active to recompile the perl5 with -Dusethreads,
> which led me to many test fails.
>

Were there tests that failed with -Dusethreads that passed when that wasn't
used?  If so, which, and what was their output?

To put it another way: if you're suggesting that we build the base perl
with -Dusethreads, what are the consequences of that?  Test failures?
Bigger binary?  pkg_add is slower?


Why the thread function was disabled in this release?
> Is it security reason?
>

 Upstream has it off by default, nothing so far has needed it, and it makes
things slower (or at least that's why upstream says).  Why would we enable
it?


Philip Guenther


Re: non-interactive sh and SIGTERM

2018-11-25 Thread Philip Guenther
On Fri, Nov 23, 2018 at 1:51 PM Olivier Taïbi  wrote:

> Sorry about the wrong report, I just tested again and I can see the same
> behaviour with OpenBSD 6.4: sending SIGTERM to the sh process after
> launching sh -c 'sleep 1000' does not result in sh sending a SIGTERM to
> the sleep process.
>

Hmm, why should it?  If you wanted to kill whatever processes where started
from that invocation, shouldn't you send SIGTERM to the process group?



> Philip, what was your test?
>

 : morgaine; sh -c 'while :; do :; done' &
[3] 16632
: morgaine; kill 16632
[3] - Terminated   sh -c "while :; do :; done"
: morgaine;
: morgaine; sh -c 'while :; do sleep 1; done' &
[3] 59539
: morgaine; kill 59539
: morgaine;
[3] - Terminated   sh -c "while :; do sleep 1; done"
: morgaine;

sh itself doesn't ignore SIGTERM, but rather exits after receiving it.


Philip Guenther


Re: non-interactive sh and SIGTERM

2018-11-22 Thread Philip Guenther
On Thu, Nov 22, 2018 at 3:08 PM Olivier Taïbi  wrote:

> It seems that non-interactive sh(1) (i.e. sh -c command or sh file)
> ignores the TERM signal. I'm surprised, is this the intended behaviour?
> The man page says that interactive shells will ignore SIGTERM, but does
> not mention the non-interactive case.
>

In my quick test it doesn't ignore SIGTERM, so you'll need to provide
additional information for us to help you.


Philip Guenther


Re: FreeBSD in vmm

2018-11-20 Thread Philip Guenther
On Tue, Nov 20, 2018 at 6:29 PM Ken M  wrote:

> Has anyone gotten this working?
>
> Just trying it as an experiment.
>
> I installed using qemu, serial console is working but when I boot through
> vmctl
> the console shows a supervisor read error, page not found which from what
> I read
> is indicative of bad memory. In qemu it boots fine though. Not sure what I
> am
> missing.
>

Not supported yet.  There will be some sort of announcement when it works.


Philip Guenther


Re: CURRENT userland does not compile due to games/glorkz

2018-11-12 Thread Philip Guenther
On Mon, Nov 12, 2018 at 2:41 AM Jyri Hovila [Turvamies.fi] <
jyri.hov...@turvamies.fi> wrote:

> > It's not a shortcut,
>
> This, as many things in this world, completely depend on the point of view.
>
> One can not simply say "this is this" or "this is not this", without
> sufficient background information and overall understanding of the
> situation as a whole.
>

...which you didn't include.  As the line from diagnostic medicine goes
"hear hoofbeats?  expect horses, not zebras".  Failure to mention why your
case is unusual suggests that you're a "normal case" -current follower, not
someone who has an undisclosed reason for never using snaps.  If you're
uninterested in what you (now?) know to be the normal answer, you should
say that so everyone's time can be saved.

It also means that you need crank up your debugging and analysis, so you
can work through these things yourself.  What failed?  Why?  What does that
imply?  What can you change to resolve it?  To avoid it?  To undo it?  If
when you build -current, you also build a release, do you still have the
files from your last successful build so you can rollback to something you
accept?  Do you have a test machine you can use your own snap to run
through the source update multiple times to experiment with solutions?

"What problem are you trying to solve?"

...

> >  It's fine if you want to waste your own time, but this is the
> > one single method of getting out of many holes, like yours.
>
> It is also perfectly fine if you want to ignore how the real world
> functions, and/or give a super irritating / dislikable impression of
> yourself and your personality. To give you back just a little, it certainly
> seems you know your holes well enough.
>

That was an unpleasant turn.


Philip Guenther


Re: heap full during amd64 boot.

2018-11-03 Thread Philip Guenther
On Sat, Nov 3, 2018 at 12:13 PM Angelo Rossi 
wrote:

> First of all you can't endorse me with services I cannot fullfill just
> because you're lowly sense of humor told this.


What is the effect (or goal, for that matter) of sharing this information
with a broad base of users?  Surely it's for more people to have and be
able to use that knowledge, no?  Meanwhile there have been multiple threads
between bugs@ and misc@ where people reported such single-filesystem setups
as having problems and were told "don't do that; it's a bad idea; use a
normal multi-FS setup".

If supporting such setups wasn't your goal, it was not clear what your goal
was from your original message.



> Then if the right behaviour
> for bootloader is to give error on this broken configuration it follows
> that the i386 arch is broiken since it permits to boot from such "crazy"
> partitioning scheme.


For my longer explanation of resource limitations at the bootloader and how
that interacts with testing the envelope, see here:
   https://marc.info/?l=openbsd-misc=154053727724928=3

Given that background, you should understand that adding extra checks to
the bootloader to detect and give a clearer error message for these "crazy"
setup will actually break *more* of them!

There are trade-offs: we made the changes we did because we thought they
were worth the cost.  Breaking more systems just to tell people clearly
that their setups are unwise seems like a bad trade-off to me, but maybe
it's the Right Thing if it'll eliminate these threads.


Philip Guenther


Re: heap full during amd64 boot.

2018-11-03 Thread Philip Guenther
On Sat, Nov 3, 2018 at 7:59 AM Angelo Rossi 
wrote:

> When using a=/ and b=swap partitioning scheme on installation or upgrading
> from 6.3 with same partitioning scheme the default HEAP_SIZE=0xA
> generates heap full error during boot in 6.4 amd64. To solve this I
> installed the -stable soiurces from AnonCVS, and changed HEAP_SIZE from
> 0xA to 0xC (the machine I tested an needs 700687 B so it should
> work with an
> HEAP_SIZE=0xB) in the file
> /usr/src/sys/arch/amd64/stand/Makefile.inc . Then I compiled and installed
> the new bootloader.
>

...and thereby continued to run a badly configured system, while providing
information to others on how to do so as well.

HEY EVERYONE USING A SINGLE PARTITION: YOU CAN GET SUPPORT FROM <
angelo.rossi.home...@gmail.com>.




Re: How effectiate login.conf changes in console? ("ksh -l" does not)

2018-10-30 Thread Philip Guenther
On Mon, Oct 29, 2018 at 9:19 PM Joseph Mayer 
wrote:

> On Tuesday, October 30, 2018 1:56 PM, Philip Guenther 
> wrote:
> > On Mon, Oct 29, 2018 at 8:40 PM Joseph Mayer joseph.ma...@protonmail.com
> > wrote:
> >
> > > After having changed /etc/login.conf I'd like to effectuate the
> > > changes directly in the console, without doing a logout-relogin
> > > cycle.
> > > Running "ksh -l" does not effectuate login.conf changes but only
> > > re-runs the profile script [1].
> > > Running "login" asks for username and password which seems less
> > > efficient than possible.
> > > Is there any way to do this?
> >
> > Since changes to login.conf may mean raising/increasing hard limits,
> which
> > can only be done by privileged processes, the only sure fire way to have
> > login.conf changes take effect is to logout and log back in.
>
...

> What about "su -l" [1]?
>
...

> If I'm root and do "su -l", will root's login.conf settings be applied?
>
> su.c [2] uses setusercontext() [3], and because emlogin is 0,
> LOGIN_SETRESOURCES is specified as flag, and so is LOGIN_SETUMASK -
> meaning login.conf settings are indeed effectuated by root doing
> "su -l" (relogin as root) or "su -l someuser" (login as someuser).
>
> Correct?
>

I guess?  Frankly, this is not an area I really care about: if I wanted to
test a login.conf change I would either logout/login if I had the password
for the account, or I suppose if it came up that I didn't, "su -c class" as
root.If 'su -l' works for you in your testing (you did test it, yes?),
then use it.


Philip Guenther


Re: How effectiate login.conf changes in console? ("ksh -l" does not)

2018-10-29 Thread Philip Guenther
On Mon, Oct 29, 2018 at 8:40 PM Joseph Mayer 
wrote:

> After having changed /etc/login.conf I'd like to effectuate the
> changes directly in the console, without doing a logout-relogin
> cycle.
>
> Running "ksh -l" does *not* effectuate login.conf changes but only
> re-runs the profile script [1].
>
> Running "login" asks for username and password which seems less
> efficient than possible.
>
> Is there any way to do this?


Since changes to login.conf may mean raising/increasing hard limits, which
can only be done by privileged processes, the only sure fire way to have
login.conf changes take effect is to logout and log back in.


Philip Guenther


Re: Dell PowerEdge R410 not booting 6.4

2018-10-26 Thread Philip Guenther
On Thu, Oct 25, 2018 at 8:44 PM diego righi  wrote:

> So why openbsd 6.4 i386 and amd64 bootloaders (not biosboot, boot!)
> express different behavior? Wasn't openbsd about correctness? :/
>
If I'm wrong and it is documented that I can't do this fine, but so also
> i386 should not work, this behavior is just strange for me, that's it.
>

This is something that most people, perhaps even most software developers,
are not strongly aware of: that resource requirements are often both
fine-grained and sharp-edged.  That is: the exact requirements can vary in
many fine-steps between systems, but there can be a sharp edge at which
performance plummets badly or the system totally fails.  This is true of
*many* systems (including lots of cloud services) which work just fine
until they *suddenly* fail, because the memory straw broke the available
RAM camel's back, or the micro-service is now taking just _longer_ to
service one request than the inter-request arrival interval so the queue so
the queue grows in latency past the user/system tolerance.

Case in point: the memory resources required by the biosboot code depend
many factors including:
* the size of the root partition
* the block size of the root partition (which is affected by the size)
* the inode number of the kernel being booted
* the exact disk block numbers which the booted kernel was put in

We all, the developers and the community of user who actively test -current
kernel (THANK YOU!) exercise various combinations of those, the *vast*
majority of which use the recommended system layout.  That recommend layout
doesn't push the first two of those items at all, and keeps the third and
fourth in sane ranges.

Meanwhile, those using monster root partitions have unknowingly been
pushing the memory usage by biosboot, but below its limits.

So, some change was made during the 6.3->6.4 dev cycle which requires
_slightly_ more memory in biosboot.  Maybe it was something about the
compiler upgrades, or the maybe it was the SoftRaid crypto passphrase-retry
change.  Or maybe it was the tiny tweak of making biosboot default the
console to com0 @ 115200 on VMs.Something made biosboot take more
memory...and now those systems with monster root partitions were pushed
over the edge of how much memory biosboot has available.

Rule of thumb: the costs must be worth the gain.
So:
 * enhancements and fixes break systems that don't get actively tested
 * we are are not going to block enhancements/fixes because of that
 * we test what we recommend, on many systems
 * if a change breaks the recommended config, then it'll get reverted/fixed
 * ...this is more likely the more quickly the problem is reported
 * ...and even then the recommendation for the future might change
 * we also test some systems that go beyond those recommendations...
 * ...but not all
 * if a system that doesn't follow the recommendations breaks as the result
of a change, the developers will make a judgement about whether the gain of
the change is worth the costs.  We don't like breaking any config, even
unusual ones, but if we think the setup is inadvisable, we'll say so and
move on.

In this particular case:
 * the changes to biosboot where in snapshots for MONTHS, but no one
reported problems
 * if you aren't following recommendations, and aren't testing snapshots,
then you should be 100% willing to change your configuration on upgrade,
'cause you ain't giving the feedback necessary to keep your unusual config
alive
 * SINGLE PARTITION CONFIGS ARE DUMB, DON'T DO THAT; DON'T BOTHER
COMPLAINING, JUST FIX THEM.


Philip Guenther


Re: dmesg for edgerouter 6p

2018-10-23 Thread Philip Guenther
On Tue, Oct 23, 2018 at 12:14 PM Holger Glaess  wrote:

> i upgrade from an native 6.4 beta installation , no problems at all.
>

To quote the email sent to your local 'root' user after install/upgrade:

If you wish to ensure that OpenBSD runs better on your machines, please do
us
a favor (after you have your mail system configured!) and type something
like:
 # (dmesg; sysctl hw.sensors) | \
mail -s "Sony VAIO 505R laptop, apm works OK" dm...@openbsd.org
so that we can see what kinds of configurations people are running.  As
shown,
including a bit of information about your machine in the subject or the body
can help us even further.  We will use this information to improve device
driver
support in future releases.  (Please do this using the supplied GENERIC
kernel,
not for a custom compiled kernel, unless you're unable to boot the GENERIC
kernel.  If you have a multi-processor machine, dmesg results of both
GENERIC.MP
and GENERIC kernels are appreciated.)  The device driver information we get
from
this helps us fix existing drivers. Thank you!


Re: Bootloader failing to install on 2012 Mac Mini (Openbsd 6.4)

2018-10-23 Thread Philip Guenther
On Tue, Oct 23, 2018 at 4:38 PM Liam Wigney  wrote:

> I've used Openbsd before but my installs have gone smoothly with no issues
> and this is really the first time it's been a problem. The install is a
> super boring one, it's whole disk Openbsd with the default gpt partition
> layout and nothing else special.
>
> During the install after the sets are successfully installed there's a
> notification that the bootloader has failed to install due to mkdir being
> called with an invalid argument.


All the error messages from installboot from mkdir failing include both the
path and the specific error message.  Those are included because they're
helpful in understanding exactly what failed (and thus what could be
wrong).  Including the _exact_ and _full_ error message would make it
easier to assist.

(Ruling out stuff that _didn't_ fail is key to figuring out root causes.)



> Some research online said that I should
> try to do installboot manually in the subsequent prrompt, so I called
> installboot sd0 and got the following error
>
> installboot: /usr/mdec/biosboot: No such file or directory
>

Yes, when running from the bsd.rd ramdisk additional argument are necessary
so that installboot can find the files it needs and disk on which to
install them.  ...but doing that will just replicate what the upgrade
script already did and the error it gave you...

At this point, the two pieces of information that would help the most are:
1) the *EXACT AND FULL* error message that the upgrader reported from
installboot
2) what your disklabel and partition layout looks like.  The output of "df
-k" from the ramdisk shell prompt after the upgrade fails would be good,
for example, as it has everything mounted under /mnt.


Philip Guenther


Re: ath.c -> dmesg -> bug

2018-10-10 Thread Philip Guenther
On Wed, Oct 10, 2018 at 3:35 PM NN  wrote:

> I try to analyse my dmesg with:
>
>  # dmesg | grep ath0
>
> and I can see ERROR message:
>
>  > ath0 device timeout ...
>
> I have checked "ath.c" file in "/cvs/src/sys/dev/ic/" on stable branch.
>
> I found this one construction: "--sc->sc_tx_time == 0". Probably it's
> meen "0 == 0",


> I have made this patch (see in attachment) and now it's working without
> any ERROR/WARNING for me.
>
> Please confirm.
>
> If my FIX for "ath.c" is correct, please update cvs in new 6.4 Release.
>
...

> --- ath.c31 Jan 2018 11:27:03 -1.116
> +++ ath.c11 Oct 2018 00:06:54 -
> @@ -930,7 +930,7 @@ ath_watchdog(struct ifnet *ifp)
>   if ((ifp->if_flags & IFF_RUNNING) == 0 || sc->sc_invalid)
>   return;
>   if (sc->sc_tx_timer) {
> -if (--sc->sc_tx_timer == 0) {
> +if (sc->sc_tx_timer == 0) {
>

This diff cannot be correct: the condition right above it is only true if
sc->sc_tx_timer is non-zero, so then testing whether it is _currently_ zero
will never be true.  That's also the only place sc->sc_tx_timer is
decremented, so deleting the '--' disables the timeout.  The existing code
decrements it and then tests whether it's zero, effectively testing whether
sc->sc_tx_timer was exactly 1.

Your work to update the driver in the thread from October 5th is a more
productive way to address the issues you're experiencing.


Philip Guenther


Re: xscreensaver locking disabled

2018-09-20 Thread Philip Guenther
On Thu, Sep 20, 2018 at 4:41 PM Ken M  wrote:

> I am following -current and use openbox if it matters for my window
> manager.
> xscreensaver is started by openbox, anyway when I try to lock, well this
> is what
> I see:
>
> $ xscreensaver-command -lock
> xscreensaver-command: locking not enabled.
>

If xscreensaver decides it can't do locking, then when started it should
write to stderr why it thinks that.  Does openbox capture the stderr of the
processes that it starts to some file you can review?  If not, then stop
xscreensaver with
 xscreensaver-command -exit
and then start xscreensaver against manually in a shell and see what it
says.

Philip Guenther


Re: make(1) and multiple outputs

2018-09-04 Thread Philip Guenther
On Tue, Sep 4, 2018 at 12:43 AM Marc Espie  wrote:

> On Mon, Sep 03, 2018 at 12:14:45PM -0900, Philip Guenther wrote:
>
...

> > Does our make have some logic in the -jN handling to detect and prevent
> > that, Marc?
>
> Philip, is that a rhetorical question ?
>

Heh, no.  Just the question of someone whose head is full of intel grunge,
leaving vague memories of other parts of the system.


You know quite well it does.
>
> There's code that looks at the target line for presence of $@, to
> desambiguate multiple targets rules from "macro-like" behavior, and the
> other targets get locked out while one target is built, so that in effect
> all
> targets get updated at once.
>

Woot.


Philip Guenther


Re: make(1) and multiple outputs

2018-09-03 Thread Philip Guenther
On Mon, Sep 3, 2018 at 5:23 AM Marc Espie  wrote:

> Our make is perfectly happy generating several targets with one rule.
>
> The only thing we're actually missing wrt % is suffixes rules with
> multiple results.
>
> See any Makefile that generates .h and .c file from .y, for instance
> lib/libkeynote/Makefile
>
> a line like:
>
> k.tab.c k.tab.h: keynote.y keynote.h signature.h
> $(YACC.y) $(YACCFLAGS) ${.CURDIR}/keynote.y
>
> looks exactly like what you want.
>

Classically, a rule like that doesn't mean one invocation will generate
both targets, but rather that the same recipe can be invoked for each
target (with different values for $@, etc).  In default single-job mode (no
-jN) this works out fine as after the first invocation 'make' will notice
the second file is already up-to-date, but with -jN some makes could decide
to build both of the targets at the same time and invoke yacc twice,
possibly resulting in truncated/corrupted output files.

Does our make have some logic in the -jN handling to detect and prevent
that, Marc?

Otherwise, the workaround has been as Geoff noted: have all the target
files depend on a timestamp file which has the real recipe and
prerequisites.  That's still recommended for GNU make users when there's no
reasonable set of patterns that can match the generated files.  People
occasionally pine for the SunOS 4.x 'make' feature of "targ1 + targ2 [+
targN...]" functionality, but it's not a great syntax and no one has done
the work.


Philip Guenther


Re: Cannot set swap priority to "move" swap on another disk.

2018-08-19 Thread Philip Guenther
On Sun, Aug 19, 2018 at 7:20 PM Philip Guenther  wrote:
...

> If that's correct, then there's no supported way to change it: the
> addition of the swap partition from the boot disk is done by the kernel
> before starting init, in swapmount(), which hardcodes a priority of zero.
>

Correction: you can change it with swapctl -c, so you can invoke that from
rc.local to solve your problem.

If you want to _fix_ it, then I would suggest updating swapctl(8) so that
it's -A option, instead of totally skipping selected swap partitions which
are already mounted, instead updates the priority of them if they don't
match what's in the fstab.


Philip Guenther


Re: Cannot set swap priority to "move" swap on another disk.

2018-08-19 Thread Philip Guenther
On Thu, Aug 16, 2018 at 10:42 PM Eric Huiban  wrote:

> With "6.3 release" version, i'm unable to set swap priority with fstab
> using the following :
>
> 2e04cb867188f137.b none swap sw,priority=0
> e7f9094bf357d407.b none swap sw,priority=1
>
> I get the following result :
>
> $ swapctl
> Device  512-blocks UsedAvail Capacity  Priority
> /dev/sd0b 219416400 21941640 0%0
> /dev/sd1b 625249160 62524916 0%0
> Total 844665560 84466556 0%
>
> Using "swapctl -a -p 1 e7f9094bf357d407.b" present the very same result.
> Same for "swapctl -a -p 1 /dev/sd0b".
> Also tried an hypothetic reboot...
>

You don't actually say it, but if read closely the commands you give
suggest that the swap partition whose priority you want to change is the
one on the *boot disk*.

If that's correct, then there's no supported way to change it: the addition
of the swap partition from the boot disk is done by the kernel before
starting init, in swapmount(), which hardcodes a priority of zero.


Philip Guenther


Re: VCORE snmp, sysctl hw.sensors

2018-07-23 Thread Philip Guenther
On Mon, Jul 23, 2018 at 3:49 AM Stanley van Dijk  wrote:

> Could anyone help me out with what I'm looking at?
>
> This comes from an snmp mib:
>
> hw.sensors.it0.volt0=1.34 VDC (VCORE_A)
> hw.sensors.it0.volt1=1.92 VDC (VCORE_B)
>
> What is vcore_a and what is vcore_b?
>

Sensor chips are wired up and measure whatever the hell their designers and
users decide.  The it(4) driver is written to expect the voltage sensors on
the chip to measure various inputs, the first two of which are both, to
quote the it(4) manpage, "Core voltage".  What that *really* means is
probably dependent on the motherboard, etc.  So, we do the best we can and
include a label to tell them apart (A vs B) but if you need more details
you'll need to consult the Surely Very Fine and Clear documentation of your
device.


Philip Guenther


Re: "Cannot allocate memory" error when memory is enough

2018-07-06 Thread Philip Guenther
On Wed, Jul 4, 2018 at 6:31 PM Nan Xiao  wrote:

> Thanks very much for your time and patience. I run "syspatch" command
> regularly, so it should be 6.3-stable.
>

> My full dmesg output is here:
>
...
Okay, nothing weird in there.


And full ouput of "vmstat -m":
>

Nothing stands out in that output either, with nothing showing failures or
consuming much more than might be expected.

So, I'm back to my theory that the programs that are failing to run for you
are from packages built for -current and not -stable and have
PT_OPENBSD_RANDOMIZE segments larger than are permitted by -stable.

For example, the gdb-7.12.1p2 package in -current has an 88kB
PT_OPENBSD_RANDOMIZE segment:

: morgaine; readelf -Wl /usr/local/bin/egdb | awk '/RANDOM/{print
($5+0)/1024}
88.4844
: morgaine;

That's bigger than what a -stable kernel will permit.

So, what's the output of that command for the egdb binary that fails for
you, and how confident are you that it's from a -stable package and not a
-current package?


Philip Guenther


Re: "Cannot allocate memory" error when memory is enough

2018-07-04 Thread Philip Guenther
On Wed, Jul 4, 2018 at 12:57 AM Nan Xiao  wrote:

> My OS is 6.3. I already use "pkg_add -u" to upgrade all installed
> packages. cmake and egdb are are installed by "pkg_add", not compiled
> by me.
>

You don't mention -release, or -stable, or -current, which is utterly
critical: 6.3-release and 6.3-stable are not guaranteed to run -current
packages, and ditto for even merely an older -current kernel+base vs fresh
-current packages.  Your messages continue to lack these critical details,
which is why we tell everyone to *include your full dmesg output*.  That
would have instantly answered what version you were running and how out of
date (or not) it is!



>  "vmstat -m" gives some information:
>
> $ vmstat -m
>

...but you trimmed out most of what would show failures or odd consumption
patterns.


It seems kernel dynamic memory is run out, and devbuf and temp consume
> most of the space.
>

What I saw in the output doesn't indicate that.


Philip Guenther


Re: "Cannot allocate memory" error when memory is enough

2018-07-03 Thread Philip Guenther
On Tue, 3 Jul 2018, Philip Guenther wrote:


Flakey button on my mouse; time to clean it again and throw it out if it 
keeps glitching.  Sorry about that.


> On Tue, Jul 3, 2018 at 4:53 PM Nan Xiao  wrote:
> > Thanks for your reply! The "ulimit -a" outputs following:
> >
> > $ ulimit -a
> > time(cpu-seconds)unlimited
> > file(blocks) unlimited
> > coredump(blocks) unlimited
> > data(kbytes) 33554432
> > stack(kbytes)8192
> > lockedmem(kbytes)1332328
> > memory(kbytes)   3978716
> > nofiles(descriptors) 128
> > processes1310
> >
> > It seems should be enough to launch cmake or egdb.

But it wasn't and the kernel can only indicate that with a single error 
code, so now you have to actually dig into what's going on.  There are 
many possibilities, as a search for ENOMEM in /usr/src/sys/kern/*exec*.c 
will show.
1) the ELF interpreter (normal ld.so) could be too large
2) the PT_OPENBSD_RANDOMIZE segment could be larger than permitted by the 
   kernel
3) program's text segment could exceed the maximum for the arch, MAXTSIZ
4) the program's vnode couldn't be mmaped for some reason
5) the argument list and environment were together too big for the stack
6) the signal trampoline couldn't be mapped into the process VM
7) other random memory allocation problems

Of those, (1), (4), and (6) are *really* unlikely.  (3) is possible if 
you're building a debugging binary that's *huge* as a result.  (5) would 
result in _all_ programs failing in that shell.  I think (7) would show up 
in a close examination of the "vmstat -m" output.

(2) is perhaps the most likely, as recent compiler changes have increased 
the expected size of the PT_OPENBSD_RANDOMIZE segment and while the kernel 
limit on that was also increased recently, you didn't provide any 
information about your setup: are your kernel, userland, and ports all in 
sync?


Philip Guenther



Re: "Cannot allocate memory" error when memory is enough

2018-07-03 Thread Philip Guenther
On Tue, Jul 3, 2018 at 4:53 PM Nan Xiao  wrote:

> Thanks for your reply! The "ulimit -a" outputs following:
>
> $ ulimit -a
> time(cpu-seconds)unlimited
> file(blocks) unlimited
> coredump(blocks) unlimited
> data(kbytes) 33554432
> stack(kbytes)8192
> lockedmem(kbytes)1332328
> memory(kbytes)   3978716
> nofiles(descriptors) 128
> processes1310
>
> It seems should be enough to launch cmake or egdb.
>
> Thanks!
> Best Regards
> Nan Xiao
>
>
> On Tue, Jul 3, 2018 at 9:37 PM, Marc Espie  wrote:
> > On Tue, Jul 03, 2018 at 05:31:22PM +0800, Nan Xiao wrote:
> >> Hi all,
> >>
> >> Greeting from me!
> >>
> >> I am running OpenBSD 6.3, and don't know from when, loading some
> >> binary will prompt "Cannot allocate memory":
> >>
> >> $ egdb
> >> ksh: egdb: Cannot allocate memory
> >>
> >> $ cmake
> >> ksh: cmake: Cannot allocate memory
> >>
> >> But the memory seems enough:
> >> $top
> >> ..
> >> Memory: Real: 57M/1365M act/tot Free: 2546M Cache: 925M Swap: 0K/4103M
> >> ..
> >>
> >> I try to use "ktrace/kdump" tool, but can't find something special:
> >> ..
> >>  21881 ktrace   NAMI  "/usr/local/bin/egdb"
> >>  21881 ktrace   RET   execve -1 errno 12 Cannot allocate memory
> >> ..
> >>
> >> Could anyone give some clues? Thanks very much in advance!
> >> Best Regards
> >> Nan Xiao
> >
> > Check your limits.
> >
> > ulimit -a
> >
> > from the shell will tell you what's wrong.
> >
> > you might also need to brush up on login.conf  and get your user into
> > a different class.
>
>


Re: Owner and group of a newly created file

2018-07-01 Thread Philip Guenther
On Sun, Jul 1, 2018 at 6:23 AM Thomas Levine <_...@thomaslevine.com> wrote:

> I was just reading about the effect of Set-user-Id and Set-group-Id bits
> on file creation, as they seem like they would be useful for me.
> Unfortunately, most of the documentation I have managed to find is
> related to GNU systems, and this could easily be different in OpenBSD.
>
> https://www.gnu.org/software/coreutils/manual/html_node/Directory-Setuid-and-Setgid.html


This goes back to a split in behavior between the BSD-derived and
USG-derived ("Unix Systems Group", spun off from AT) systems.
BSD-derived systems always gave new files the group of the directory in
which they were created, while USG-derived systems used the effective
group-id of the process that created the file.  Vendors realized the BSD
behavior is more useful for actual groups of people, but they presumably
didn't feel like they could change the behavior of their existing systems
so they added this "setgid on the directory means follow BSD rules"
behavior.  Linux has always had a more USG/Sys5 flavor to it, so they
followed that rule instead of just making the behavior the Right Thing.



> It appears that they have no effect on file creation. Rather, they a
> only "on execution", as specified in the manual.
> https://man.openbsd.org/chmod


Correct: those bits are ignored by OpenBSD on anything but executable
normal files.



> Very conveniently for me, this behaviour (u-s,g+s in GNU) is the mode
> that I want. Perhaps this is by design.
>

Yep.

Philip Guenther


Re: OpenBSD performance upgrade

2018-06-08 Thread Philip Guenther
On Fri, Jun 8, 2018 at 10:13 AM Elias M. Mariani 
wrote:

> I usually run long computations on OpenBSD-current, in the last few
> days I see an upgrade in the performance of the process (in this case
> I have 6 threads running a very optimized assembler code).
> Each iteration of the code was about 14 sec. and now is around 13 sec.
> Don't mind the computation, the question is more about if something
> was changed (and if so what) to hit the performance so much, the
> compilation is the same as before, so the code did not change and the
> software does not use anything from ports, only the standard C
> library.
>
A more accurate description would be that the threads are more
> homogeneous in relation with the iterations time, maybe one thread
> suddenly give a 11 sec. result, and another 15, probably related with
> thread reallocations, now I have a steady time in all the threads and
> in average the numbers are better.
> Anyways... Better is better. Just curious to know why is working better. :D
>

If the "optimized assembler"  that the threads are running uses AVX or
similar "extended CPU state" extensions then the improvement is almost
certainly from my switch amd64 from "lazy FPU switching" to what I'll call
"semi-eager switching", where the current thread's registers are always
ensured to be loaded before returning to userspace, eliminating the need
for extra userspace->kernel->userspace transitions and IPIs to load the
registers in the current CPU.

Glad to hear it's such a large improvement for your processing.  Enjoy, and
remember to tip your OS vendor!  


Philip Guenther


Re: Building ramdisk_cd (6.3)

2018-05-23 Thread Philip Guenther
On Wed, May 23, 2018 at 4:19 PM, Alfredo Rainho Neves <arai...@nevex.com.br>
wrote:

> I am trying to build the ramdisk_cd, but having some problems with
> permission of the ramdisk_cd directory. It is set to my user and group
> wsrc,
> but when I try to do a make I get the following:
>

If you want to do that you should follow *exactly* the instructions in the
release(8) manpage up through at least step 4.


I tried adding the "build" user to the wsrc group but still get the problem.
>

Undo that.  The group file shipped with base is correct for this: user
'build' should have 'build' as its default group and additionally be in
group 'wobj' and no others.  I mean, if you needed to add it to another
group we would have documented that in the release(8) manpage...


Philip Guenther


Re: CVE-2018-8897

2018-05-10 Thread Philip Guenther
On Thu, May 10, 2018 at 5:06 PM, IL Ka <kazakevichi...@gmail.com> wrote:
>
> >> OpenBSD does not allow userspace to access the hardware debug registers.
>
> Does it mean that gdb and other debuggers can't use hardware breakpoints?
>

Correct: gdb is a userspace program, so it can't set hardware breakpoints
on x86.

(I don't know whether hardware breakpoints are supported on any of the
other CPUs supported by OpenBSD)



> Then how do they implement memory watch?
>

Got me, but even the ancient, in-tree gdb is able to do so.  Have you
consulted the gdb source?


Philip Guenther


Re: crash of OpenBSD 6.3 -stable (amd64 MP kernel) - unswapping kills connections

2018-04-27 Thread Philip Guenther
On Thu, Apr 26, 2018 at 11:21 PM, Infoomatic <infooma...@gmx.at> wrote:
>
> thanks for your input! Actually, I was never really satisfied with the
> stability of ntopng, so this problem of the memory leak does not really
> surprise me. However, when killing the process, which also means freeing
> swap space, I think it is not an expected behaviour that the system does
> not handle any tcp/ip or icmp connections any more until the swap space is
> fully freed (which, in my case when ntopng used 3 out of 4GB swap, lastet
> for nearly 20 minutes). IMHO, unswapping a process should not influence
> network connectivity that much.
>

You're correct that we don't want the clean up of an exiting process to
affect network processing.  The issue is that our UVM is still under the
kernel lock; work into using more fine-grained locking there has begun but
nothing has really hit the tree yet.


Philip Guenther


Re: doas id -ru returns 0 ?

2018-04-23 Thread Philip Guenther
On Mon, Apr 23, 2018 at 4:53 PM, Rudolf Sykora <rudolf.syk...@gmail.com>
wrote:

> I expected that
>
> doas id -ru
>
> would return my uid.
>
> But it returns 0 (ie root)
>
> Can anybody comment on it?
>

Hmm, what led you to expect it to return your UID?

doas, like su, sets both the effective and real UID to the target user's;
running something with doas is not the same as making it setuid and running
it.  Running with effective!=real can trip up programs that didn't expect
it, so it not a safe choice for something like doas.


Philip Guenther


Fwd: swapctl question

2018-04-15 Thread Philip Guenther
Whoops, meant to send this to the list too:

-- Forwarded message --
From: Philip Guenther <guent...@gmail.com>
Date: Sat, Apr 14, 2018 at 11:13 PM
Subject: Re: swapctl question
To: Z Ero <zerotetrat...@gmail.com>


On Sat, Apr 14, 2018 at 10:37 PM, Z Ero <zerotetrat...@gmail.com> wrote:

> amd64, 6.2
>
> I have my swap partition set to priority 9 in fstab.
>

> Why does swapctl report priority 0?
>

The compiled in default swap location (normally the 'b' partition of the
boot disk) is added as swap at priority zero in kernel startup as part of
uvm_swap_init(), before any userspace processes are started or /etc/fstab
is read.


# swapctl
> Device  512-blocks UsedAvail Capacity  Priority
> /dev/sd0b 11874624  1266232 1060839211%0
> # cat /etc/fstab
>

You only have one swap device so the priority doesn't matter: priority is
for selection _among_ swap devices and has no effect on the kernel's
decision of _whether_ to swap out a page.


I want to minimize swapping since I am using a mechanical hard disk
> and thus swap slows things down.
>

Slows things down relative to _what_?  Which statistics have you been
examining when under the workload you're interested in?


Philip Guenther


Re: Date of yesterday

2018-04-09 Thread Philip Guenther
On Mon, Apr 9, 2018 at 2:05 PM, Tom Smyth <tom.sm...@wirelessconnect.eu>
wrote:

> Howdy...
> Daylight savings time sucks...  :/...
>  Is there a way to Reference UTC and then do  the calculating
> n and then convert to local time zone if  you are worried about
> calculating yesterday on the edge case of the 2 hrs a year
> that this would make an impact...
>

What...why...why are you making this harder than it has to be?

mktime/localtime let you perform calculations based on time broken down
into years/months/days/etc.  "Yesterday" is a calculation based on days, so
do it in that form.  Those APIs exist to let you do that!  That's what the
solution I provided in my original reply does!



> as a side issue would  avoiding running this particular job
> between 11PM and 1am  prevent the edge case from having
> an impact
>

So you know how to do the Right Thing, but you're going to instead leave a
bug for you or your successor to hit months or years away?  Please do not
do that on any system that others might depend on.


Philip Guenther


Re: Date of yesterday

2018-04-09 Thread Philip Guenther
On Mon, Apr 9, 2018 at 1:36 PM, Stephane HUC "PengouinBSD" <
b...@stephane-huc.net> wrote:

> what?
>
> please, explain-me!
>
As I wrote before, and you quoted before:

> | Did you test that after 11pm on the day when daylight-saving time ends
and
> | the clock is turned back, resulting in a 25 hour long day?

On the day when daylight-saving time ends, the clock is turned back an hour
resulting in a day which is 25 hours long!

 : morgaine; date -r $((1541403000))
Sun Nov  4 23:30:00 PST 2018
: morgaine; date -r $((1541403000 - 86400))
Sun Nov  4 00:30:00 PDT 2018
: morgaine;


Re: Date of yesterday

2018-04-09 Thread Philip Guenther
On Mon, Apr 9, 2018 at 11:58 AM, Stephane HUC "PengouinBSD" <
b...@stephane-huc.net> wrote:

> get the current timestamp, subtracting 86400 seconds is not reliable to
> get yesterday's date to the nearest second?
> terrible!


Yes, some days are 9 seconds long.


Re: Date of yesterday

2018-04-09 Thread Philip Guenther
On Mon, Apr 9, 2018 at 2:04 AM, Stephane HUC "CIOTBSD" <b...@stephane-huc.net
> wrote:

> as: date -r $(( $(date +%s) - 86400)) +%F
> ;)

...

> > On Sun, Apr 08, 2018 at 11:12:43PM -0700, Philip Guenther wrote:
> > | Did you test that after 11pm on the day when daylight-saving time ends
> and
> > | the clock is turned back, resulting in a 25 hour long day?
>


The best part about top-posting is that you don't have to read the earlier
comments which already explained why the solution you're proposing isn't
reliable...


Re: Date of yesterday

2018-04-09 Thread Philip Guenther
On Sun, Apr 8, 2018 at 10:54 PM, Robert Klein <rokl...@roklein.de> wrote:

> this works for me:
>
> date -r $(( $(date +%s) - 1 * 24 * 60 * 60 )) +%Y_%m_%d
>

Did you test that after 11pm on the day when daylight-saving time ends and
the clock is turned back, resulting in a 25 hour long day?

I would use this:
   perl -MPOSIX=strftime,mktime -le '@d=localtime(); $d[3]--; mktime(@d);
print strftime("%Y_%m_%d",@d)'

Philip Guenther


Re: Compilations errors with plan9port on 2018/04/05 snapshot

2018-04-05 Thread Philip Guenther
On Thu, Apr 5, 2018 at 9:50 PM, Philip Guenther <guent...@gmail.com> wrote:

> On Thu, Apr 5, 2018 at 7:53 PM, Patrick Marchand <m...@patrickmarchand.com
> > wrote:
>
>> Output of compiling plan9port on amd64 with the april 5 snaphot
>>
> ...
>
>> ===>  Patching for plan9port-20180117
>> Segmentation fault (core dumped)
>> *** Warning in /usr/ports/plan9/plan9port: "uname -m" returned non-zero
>>
>
> dmesg from this box, please.
>

Also, does this segfault happen consistently at that same exact spot, or is
it inconsistent?


Re: Compilations errors with plan9port on 2018/04/05 snapshot

2018-04-05 Thread Philip Guenther
On Thu, Apr 5, 2018 at 7:53 PM, Patrick Marchand <m...@patrickmarchand.com>
wrote:

> Output of compiling plan9port on amd64 with the april 5 snaphot
>
...

> ===>  Patching for plan9port-20180117
> Segmentation fault (core dumped)
> *** Warning in /usr/ports/plan9/plan9port: "uname -m" returned non-zero
>

dmesg from this box, please.


Philip Guenther


Re: Why are so many people running and writing about current snapshots

2018-03-26 Thread Philip Guenther
To answer your original question: yes, 6.3 is almost here.  We've been
running this schedule of twice a year releases for *decades*, so you as a
fan of stable OpenBSD releases should be familiar with the time frames by
now, no?

On Mon, Mar 26, 2018 at 8:31 PM, Z Ero <zerotetrat...@gmail.com> wrote:

> I just don't want OpenBSD to turn into Linux where the fixation is on
> newest shiny thing rather than doing code right.


*How* does that happen?  People test the builds _before_ release so that we
can iron out problems in the changes that happened over the previous six
months!  If no one tests, then it'll be a crap release and you'll be
wondering why the code wasn't done right.



> Sometimes I think
> people who are excessively interested in bleeding edge features more
> want an OS for tinkering with than an OS for production / work.


I want a box that lets me get stuff done too.  That's why when the Meltdown
issue hit the fan I tightened my belt and shoveled the shit to mitigate it
with mlar...@...and testing in snapshots was how we identified problems and
gained confidence it its stability.  Stability isn't something magical
gained just by sitting in the tree untested!  Things become stable when
people test them.  If the only people testing snapshots before release are
the developers, then the release will be stable on the developers' boxes
and not so stable on everyone else's.

I want something stable to use. But to each his own.
>

That's nice; I want my code to work on the first try.  Too bad both our
wishes require work.

If you're not testing snapshots then you're not contributing to that
stability.  Constraints in your life keep you from doing that?  Sure, fine,
but be aware that you're taking not giving, and instead of asking others
"why do you give?" you should ask yourself "how am I giving, here, in my
community, in my life, in the world?"


Philip Guenther


Re: segfault when exiting a program

2018-03-26 Thread Philip Guenther
On Mon, Mar 26, 2018 at 5:37 PM, Nicolas Schmidt <schmi...@math.hu-berlin.de
> wrote:
>
> a while ago I posted on this list because of a problem I experienced with
> building OpenBSD 6.2-current from source (the base system, not the kernel).


https://www.openbsd.org/faq/faq5.html#Flavors

I'm not sure what you mean by "6.2-current": exactly what tag did you check
out and when?  From the line numbers, you are either actually building
6.2-stable, checked out from the OPENBSD_6_2 tag, or are building something
checked out from the trunk back in the fall.



> Today I found the culprit, and it's rather strange: returning from main(),
> or calling exit() explicitly causes a segmentation fault.
>

> A minimal example is:
>
> int main(int argc, char **argv) { return 0; }
>
> Evaluating cc -o test test.c; ./test should result in a segmentation
> fault. Here's the backtrace gdb gives me:
>
> #0  _libc___cxa_finalize () at /usr/src/lib/libc/stdlib/atexit.c:133
> #1  0x0de4d9fb in _libc_exit (status=0) at /usr/src/lib/libc/stdlib/exit.
> c:54
> #2  0x18bef421 in main () from /home/nico/test
>
> Anyone able to reproduce this?
>

Nope.  I don't know what you did on your system since it was stable, but
you've somehow built and installed
a) a broken libc,
b) a broken csu (crt0, crtbegin, etc), OR
c) a broken compiler

If you have a good memory or record of what builds and changes you made,
then you could go through that and figure out exactly how/why the broken
bits were built and installed.  Frankly, I don't think you have notes good
enough to figure that out (*I* rarely keep that good of track of my changes
and builds, so that's not an insult), so the recommended strategy is to
reinstall with known good setup, verify that it's actually good before
making any changes, and then keep better notes *next* time so you can
figure out how you broke it.


Philip Guenther


Re: How recursive copy to clone OS installation (devices, links, owners, privileges etc.)?

2018-03-14 Thread Philip Guenther
On Wed, Mar 14, 2018 at 6:08 PM, Tinker <t1...@protonmail.ch> wrote:

> Say you have an OpenBSD installation (with /dev and all) mounted on
> /mnt , and you'd like to clone it to /mnt2 , which is a partition
> of different size, so dd is not an option.
>
> For simplicity of the example both the source and destination OS
> installations are on single ffs partitions, e.g. /mnt hosts /dev/sd1a
> which is sd1's only partition, and /mnt2 hosts /dev/sd2a which is sd2's
> only partition.
>
> Can you make cp or some other recursive copying tool properly replicate
> device files, links, file privileges and attributes, user and group
> ownership, and maybe even creation and modification times, so the
> copying together will make /mnt2 a complete and bootable replica of
> /mnt ?
>

Ignoring the "bootable" qualifier which is more about disklabel and
installboot:

cd /mnt && pax -rwpe . /mnt2


Philip Guenther

(Replies that are mangled by protonmail will be ignored.)


Re: The sysctl(3) is changed to sysctl(2)?

2018-03-12 Thread Philip Guenther
On Mon, Mar 12, 2018 at 7:52 PM, Theo de Raadt <dera...@openbsd.org> wrote:

> It is a library routine that calls a system call.
> It isn't worth changing at this point.
>

Actually we did.


> > I find sysctl(3) in OpenBSD 6.2 is changed to system call in -current
> > (please refer the manual: https://man.openbsd.org/sysctl.2).
> >
> > So the sysctl would be a system call instead of library function in
> > future OpenBSD?
>

Back when sysctl() supported the CTL_USER branch of MIB, the function in
libc had non-trivial logic.  At some point I deleted the CTL_USER support
reducing it just a trivial wrapper around the ASM that did the syscall, and
then we deleted the shim and just made it the ASM shim directly like many
of the other syscalls.

...but don't read too much into the section 2 vs section 3 distinction.
For example, consider the first six syscalls: exit, fork, read, write,
open, close.  *None* of those are bare ASM shims; *all* of them have
non-trivial wrappers in libc!  exit(3) is widely acknowledged as such and
_exit(2) is provided for direct access to the syscall, but we're not going
to rename the manpages for the others just to reflect that fork(2) handles
pthread_atfork() registrations, and the other four do pthread cancellation
checks.

At this point section 2 mean, uh, "you may see this in kdump output"?



Philip Guenther


Re: Which hexeditor may I use to import binary files via shell?

2018-03-10 Thread Philip Guenther
On Sat, Mar 10, 2018 at 9:42 PM, Felix Maschek <fe...@maschek.com> wrote:
>
> Is there a shell command availabl to import binary files via shell?
> Something like a hex editor?
>

b64encode(1) and the matching b64decode(1)

For files that have only a few bytes that aren't printable ASCII, vis(1)
and unvis(1) may be more friendly.

Philip Guenther


Re: interrupt at 50% on dell E5450

2018-03-01 Thread Philip Guenther
On Thu, Mar 1, 2018 at 12:37 AM, vincent delft <vincent.de...@gmail.com>
wrote:

> If I do a “boot –c” and “disable acpimadt” the machine does no more do lot
> of interrupts.
>
> But I miss lot of hardwares (2 cpu instead of 4, no mouse, …)
>
>
>
> Otherwise, I’ve tried to remove lot of CPU performance parameters in the
> Bios settings, but this has no effects.
>
>
>
> I’ve tried to disable HW elements like wifi, bluethoot, … But this has no
> effect on the number of interrupts.
>

After a cold boot with acpimadt *enabled*, what's the output of "vmstat -i"
?


Philip Guenther

(You don't need to quote your previous message; there are list archives and
it just makes it more annoying to reply.)


Re: deadfs, fifofs

2018-02-24 Thread Philip Guenther
On Wed, Jan 17, 2018 at 3:03 AM, Gregory Edigarov <ediga...@qarea.com>
wrote:
>
> Curiosity killed the cat.
>

Need to search more for what you are curious of...


> What are those for? I cannot find any reference in docs.
>

dead_vnops.c exports a variable dead_vops which is used in vclean() as the
operation vector for a vnode that can no longer be used, such as after
revoke(2) or when the filesystem has been forcibly unmounted.  Providing a
dummy vector like that avoids adding checks to each VOP_* call.

fifo_vnops.c provides the functions used in the struct vops vectors for
FIFOs on all filesystem, providing the actual behavior of FIFOs everywhere.


Philip Guenther


Meltdown, aka "Dear Intel, you suck"

2018-01-06 Thread Philip Guenther
So, yes, we the OpenBSD developers are not totally asleep and a handful of
us are working out how to deal with Intel's fuck-up aka the Meltdown
attack.  While we have the advantage of less complexity in this area (e.g.,
no 32bit-on-64bit compat), there's still a pile of details to work through
about what has to be *always* in the page tables vs what can/should/must be
hidden.

Do KARL or other features of OpenBSD mitigate this?  Not particularly.  If
you're running code from multiple trust domains then yeah, you're largely
at risk.

We have received *no* non-public information.  I've seen posts elsewhere by
other *BSD people implying that they receive little or no prior warning, so
I have no reason to believe this was specific to OpenBSD and/or our
philosophy.  Personally, I do find itamusing? that public announcements
were moved up after the issue was deduced from development discussions and
commits to a different open source OS project.  Aren't we all glad that
this was under embargo and strongly believe in the future value of
embargoes?

Unless something unexpected happens, we'll be applying the workaround to
amd64 first and then working out what to do for i386 and arm* (if still
though to be necessary for arm) after that.  No promises on only applying
it to Intel CPUs or knobs to disable it, yet: we'll see how complex that
would make things.  As always, our own developer laptops are the first
targets, so we're invested in it working and being usable.


Philip Guenther
guent...@openbsd.org


Re: Broadcast/Multicast & NTP - CAPWAP

2017-12-30 Thread Philip Guenther
On Sat, 30 Dec 2017, Patrick Dohman wrote:
> I’m looking to determine if the cause of intermittent subnet 
> “collisions” that necessitate power cycle of numerous networks hosts is 
> the result of OpenBSD security configurations

You haven't described your setup or what you're actually running on your 
OpenBSD box, so I don't know how OpenBSD is even *involved* in what you're 
asking about.

...
> Essentially If security configurations that disable for example 
> broadcast echo & address mask query can lead to unexpected results. For 
> example MTU size & TCP window scaling options requiring the results of a 
> broadcast ICMP echo.

Path MTU detection is dependent on ICMP "fragmentation required" 
responses, but OpenBSD generates, processes, and passes those by default.  
TCP window scaling is not dependent on any sort of ICMP.


> Or if unintended result of the stateless UDP traffic never reaching it’s 
> destination due to security config can result in ICMP UDP MTU errors.

Uh, no.

Frankly, this sounds like grasping at straws; you need to pause and 
actually write down *testable* details before trying to come up with
(more) hypotheses.  As I wrote before:

>> If the latter, then you should take it down a level and describe what you 
>> tried to do, what you expected to see "on the wire/in the air", and what 
>> you _actually_ saw there?


Philip Guenther



Re: Broadcast/Multicast & NTP - CAPWAP

2017-12-30 Thread Philip Guenther
On Sat, 30 Dec 2017, Patrick Dohman wrote:
> At this point it appears that openbsd security configurations may result 
> in a los of UDP ICMP traffic to all hosts on a segment. If possible 
> please clarify if any of the following are required foe the proper 
> operation of NTP/CAPWAP on a broadcast/multicast segment.

Do you just want to hope that someone on this list has already deployed 
"CAPWAP" with OpenBSD and wait for them to answer, or are you interested 
in trying to debug it?

If the latter, then you should take it down a level and describe what you 
tried to do, what you expected to see "on the wire/in the air", and what 
you _actually_ saw there?


(Reading at least one 120+ page standard written by Cisco just to 
understand the background to someone else's problem is a high barrier to 
assistance by others who are familiar with networking but not with CAPWAP 
and/or LWAPP.)


Philip Guenther



  1   2   3   4   5   6   7   8   9   10   >