Re: Segmentation fault when opening a particular PDF file in mupdf

[Xianwen Chen]

Dear Vincent,

Thank you for the suggestion!

I thought about using evince. I think I can use Firefox to open the document, 
before I obtain an updated mupdf. I use mupdf mainly because it is more 
lightweight than evince.

Sincerely,
Xianwen

On Fri, Feb 16, 2018 at 11:30 PM, vincent delft 
> wrote:
Hello,

You could also use evince. (http://openports.se/graphics/evince)
On my machine (openbsd-current) I can open your specific pdf.

regards



On Thu, Feb 15, 2018 at 9:05 PM, Xianwen Chen 
> wrote:
Dear Carlin and Erling,
Thank you both!
Yes, I am using 6.2 with mupdf-1.11p1. Then I shall just wait until next 
release and use Firefox to read the document at the moment.
Sincerely,
Xianwen

On Thu, Feb 15, 2018 at 5:13 PM, Erling Westenvik 
>>
 wrote:
On Fri, Feb 16, 2018 at 05:38:11AM +1300, Carlin Bingham wrote:
> On 16/02/2018 4:28 a.m., Xianwen Chen wrote:
> > mupdf crashes and reports segmentation fault when I try to open a
> > particular PDF file:
> > https://brage.bibsys.no/xmlui/bitstream/handle/11250/2440173/SoL-Rapport-2014-06.pdf?sequence=1=y
> >
> > If you use mupdf too, could you try to open the file and see whether
> > mupdf crashes on your computer too? In that way, you can help me
> > understand whether the problem is reproducible.

Opens just fine. See below.

> Are you using 6.2 with mupdf-1.11p1?
> There was a crash that's fixed on -current:
> https://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/textproc/mupdf/patches/patch-source_fitz_load-jpx_c?rev=1.5=text/x-cvsweb-markup

I'm using current as of yesterday, February 14th, here.

Erling

Re: Segmentation fault when opening a particular PDF file in mupdf

[Stuart Henderson]

On 2018-02-16, Xianwen Chen  wrote:
> Dear Stuart,
>
> Thank you.
>
> I am interested in trying to build it from ports. I checked OpenBSD's FAQs 
> and did not find information on building packages from ports. Could you point 
> me to a web page or a manual page?
>
> Sincerely,
> Xianwen

First you need to fetch the ports tree from cvs, see
http://www.openbsd.org/anoncvs.html (you want the 6.2-stable ports
tree for this, no need for src or xenocara).

Then cd /usr/ports/textproc/mupdf, "make package" (as a normal user),
then "make install" as root.

Re: Segmentation fault when opening a particular PDF file in mupdf

[Xianwen Chen]

Dear Stuart,

Thank you.

I am interested in trying to build it from ports. I checked OpenBSD's FAQs and 
did not find information on building packages from ports. Could you point me to 
a web page or a manual page?

Sincerely,
Xianwen

On Thu, Feb 15, 2018 at 11:37 PM, Stuart Henderson 
> wrote:
On 2018-02-15, Xianwen Chen > 
wrote:
> Dear Carlin and Erling,
> Thank you both!
> Yes, I am using 6.2 with mupdf-1.11p1. Then I shall just wait until next 
> release and use Firefox to read the document at the moment.
> Sincerely,
> Xianwen

BTW I've just backported this fix to the 6.2-stable ports tree if you're
happy with building from ports.. (Will need to wait a couple of hours for
anoncvs mirrors to catch up).

noob question: driver separation?

[Hess THR]

Hello, 

are there any (at least on plan or theoretical level) that drivers will 
be/are/would be separated? ex.: 

- touchpad drivers shouldn't have to do anything with network access
- wireless drivers shouldn't be able to touch anything from ex.: /home
- graphics/wireless/sound/disk/etc. drivers shouldn't be able to get anything 
from keyboards
- and so on. 

or is this only a dream or bad concept that separation needed "inside kernel 
level"? 

Thanks and have a great weekend! :)

Interface status is active after turned down with ifconfig

[Sid Bradford]

Hi folks,

I recently came across some odd behaviour with CARP interfaces. From past
experiences, shutting down an interface with ifconfig puts the status to
"no carrier". With the current setup, it briefly shows "no carrier" before
coming back up as "active".

Functionally, it is in the down state and nothing is transmitted or
received, but ifconfig reports it as up and a link speed is negotiated. In
the case of CARP, the firewall that has the interface turned down will
occasionally show all the CARP interfaces as MASTER instead of INIT.

Anyone encounter this behaviour before? System information is below.

Cheers,

Sid

Version: OpenBSD 6.0-stable
Platform: amd64

dmesg output:
OpenBSD 6.0-stable (.MP) #20170519: Wed May 17 21:09:23 EDT 2017
root@:/usr/src/sys/arch/amd64/compile/.MP
RTC BIOS diagnostic error 80
real mem = 8395776000 (8006MB)
avail mem = 8136962048 (7760MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x8ef68000 (46 entries)
bios0: vendor Dell Inc. version "2.0.8" date 01/12/2017
bios0: Dell Inc. PowerEdge R330
acpi0 at bios0: rev 2
acpi0: sleep states S0 S5
acpi0: tables DSDT FACP BOOT SSDT SLIC HPET LPIT APIC MCFG WDAT SSDT DBGP
DBG2 SSDT SSDT SSDT SSDT SSDT SSDT PRAD HEST BERT ERST EINJ DMAR FPDT
acpi0: wakeup devices PEGP(S0) PEG0(S0) PEGP(S0) PEG1(S0) PEGP(S0) PEG2(S0)
XHC_(S0) XDCI(S0) PXSX(S0) RP01(S0) PXSX(S0) RP02(S0) PXSX(S0) RP03(S0)
PXSX(S0) RP04(S0) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 2399 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Xeon(R) CPU E3-1220 v5 @ 3.00GHz, 3293.59 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 24MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Xeon(R) CPU E3-1220 v5 @ 3.00GHz, 3292.34 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Xeon(R) CPU E3-1220 v5 @ 3.00GHz, 3292.34 MHz
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Xeon(R) CPU E3-1220 v5 @ 3.00GHz, 3292.34 MHz
cpu3:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 3, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt0: no apic found for irq 32
acpiprt0: no apic found for irq 33
acpiprt0: no apic found for irq 34
acpiprt1 at acpi0: bus 1 (PEG0)
acpiprt2 at acpi0: bus 2 (PEG1)
acpiprt3 at acpi0: bus 3 (PEG2)
acpiprt4 at acpi0: bus -1 (RP01)
acpiprt5 at acpi0: bus -1 (RP02)
acpiprt6 at acpi0: bus -1 (RP03)
acpiprt7 at acpi0: bus -1 (RP04)
acpiprt8 at acpi0: bus -1 (RP05)
acpiprt9 at acpi0: bus -1 (RP06)
acpiprt10 at acpi0: bus -1 (RP07)
acpiprt11 at acpi0: bus -1 (RP08)
acpiprt12 at acpi0: bus 4 (RP09)
acpiprt13 at acpi0: bus -1 (RP10)
acpiprt14 at acpi0: bus 5 (RP11)
acpiprt15 at acpi0: bus -1 (RP12)
acpiprt16 at acpi0: bus -1 (RP13)
acpiprt17 at acpi0: bus -1 (RP14)
acpiprt18 at acpi0: bus -1 (RP15)
acpiprt19 at acpi0: bus -1 

Re: VMM VM - 'dummy' based driver-based X11 server inside, not possible?

[Jiri B]

On Fri, Feb 16, 2018 at 09:42:25PM +0200, Dumitru Mi?u Moldovan wrote:
> On 02/16/18 10:14, Jiri B wrote:
> 
> […]
> 
> > I'll try to clarify my use case further. I'd like to attach of a persistent
> > remote display session in screen/tmux-like manner.
> > 
> > IIUC a 'persistent' disqualifies X11 forwarding over SSH, and it
> > disqualifies usage of "remote" DISPLAY=$ip:$display too.
> > 
> > Thus, IIUC, X11 server needs to run on remote OS as well, and because the VM
> > does not have real graphical card, it does need a kind of fake X11 server.
> > 
> > Xvfb or X11 native 'dummy'-driver based solution should work, the graphics
> > itself can be later attached in screen/tmux-like manner via VNC for example.
> > 
> > Solutions I'm aware:
> > 
> > - X11 forwarding (not persistent)
> > - X11 with remote DISPLAY (not persistent)
> > - X11 'dummy' driver (not working in VMM VM)
> > - Xvfb (works but seems slower/obsoleted by X11 native 'dummy' driver)
> > 
> 
> Might want to add this to your list: https://www.xpra.org/ (have never
> tried it, but advertises itself as "screen for X11").

IIUC xpra uses 'dummy' X11 driver but I haven't checked too deeply
as there's no port for it right now.

Jiri

Re: VMM VM - 'dummy' based driver-based X11 server inside, not possible?

[Dumitru Mișu Moldovan]

On 02/16/18 10:14, Jiri B wrote:

[…]

> I'll try to clarify my use case further. I'd like to attach of a persistent
> remote display session in screen/tmux-like manner.
> 
> IIUC a 'persistent' disqualifies X11 forwarding over SSH, and it
> disqualifies usage of "remote" DISPLAY=$ip:$display too.
> 
> Thus, IIUC, X11 server needs to run on remote OS as well, and because the VM
> does not have real graphical card, it does need a kind of fake X11 server.
> 
> Xvfb or X11 native 'dummy'-driver based solution should work, the graphics
> itself can be later attached in screen/tmux-like manner via VNC for example.
> 
> Solutions I'm aware:
> 
> - X11 forwarding (not persistent)
> - X11 with remote DISPLAY (not persistent)
> - X11 'dummy' driver (not working in VMM VM)
> - Xvfb (works but seems slower/obsoleted by X11 native 'dummy' driver)
> 

Might want to add this to your list: https://www.xpra.org/ (have never
tried it, but advertises itself as "screen for X11").



signature.asc
Description: OpenPGP digital signature

Pointer Authentication

[Kevin Chadwick]

This may be a waste of time for OpenBSD and way too specific in
application (64-bit etc.) but as I don't have the knowledge to say and
in case it is useful, here's the presentation.

It uses unused bits to create an auth tag for pointers which are
apparently atleast 3 bits but 16 bits on Linux.

Apparently there should be a paper around that may be faster to assess.

Raising the Bar: New Hardware Primitives for Exploit Mitigations (ARM
v8 - Qualcomm)

https://www.youtube.com/watch?v=PYe8W33lbAQ

Re: libasr/libevent question

[Klemens Nanni]

On Fri, Feb 16, 2018 at 08:52:13AM -0600, ed...@pettijohn-web.com wrote:
> Perhaps a doc bug then. Or an interpretation bug on my part.
>From event_init(3)'s DESCRIPTION:

The event API needs to be initialized with event_init() before
it can be used.

> 
> The event_asr_run() function is used to schedule the asynchronous resolver 
> query aq to run within a libevent event loop, and call the fn callback when 
> the result is available. The extra arg parameter is passed to the callback. 
> The user does not need to set up an event structure for using this function. 
> It returns an opaque handle representing the running query. This handle 
> becomes invalid before the callback is run. 
> 
> I interpreted this to mean it took care of the event stuff for me. Either 
> way, thanks. 
> On Feb 16, 2018 8:21 AM, Eric Faurot  wrote:
> >
> > On Thu, Feb 15, 2018 at 07:41:55PM -0600, Edgar Pettijohn wrote:
> > > I have this trivial program that I keep getting a segfault trying to use
> > > event_asr_run(). I have #if 0'd working code to show my progression from
> > > getaddrinfo() to event_asr_run(). It is hopefully something trivial that 
> > > I'm
> > > overlooking.  Anyway I compiled like so:
> >
> > You need to call event_init() before using other libevent functions.
> >
> > Eric.
> >
> 

Re: libasr/libevent question

[edgar]

Perhaps a doc bug then. Or an interpretation bug on my part.

The event_asr_run() function is used to schedule the asynchronous resolver 
query aq to run within a libevent event loop, and call the fn callback when the 
result is available. The extra arg parameter is passed to the callback. The 
user does not need to set up an event structure for using this function. It 
returns an opaque handle representing the running query. This handle becomes 
invalid before the callback is run. 

I interpreted this to mean it took care of the event stuff for me. Either way, 
thanks. 
On Feb 16, 2018 8:21 AM, Eric Faurot  wrote:
>
> On Thu, Feb 15, 2018 at 07:41:55PM -0600, Edgar Pettijohn wrote:
> > I have this trivial program that I keep getting a segfault trying to use
> > event_asr_run(). I have #if 0'd working code to show my progression from
> > getaddrinfo() to event_asr_run(). It is hopefully something trivial that I'm
> > overlooking.  Anyway I compiled like so:
>
> You need to call event_init() before using other libevent functions.
>
> Eric.
>

Re: libasr/libevent question

[Eric Faurot]

On Thu, Feb 15, 2018 at 07:41:55PM -0600, Edgar Pettijohn wrote:
> I have this trivial program that I keep getting a segfault trying to use
> event_asr_run(). I have #if 0'd working code to show my progression from
> getaddrinfo() to event_asr_run(). It is hopefully something trivial that I'm
> overlooking.  Anyway I compiled like so:

You need to call event_init() before using other libevent functions.

Eric.

Re: pfstat and queueing

[Stuart Henderson]

On 2018-02-16, Predrag Punosevac  wrote:
> Stuart Henderson wrote:
>
>> It can already be monitored to some extent, base snmpd does already
>> support a number of things in OPENBSD-PF-MIB, but not queues yet.
>
> Any chance that you share with us how you plot the data you recover with
> snmpwalk from those MIBs.

I'm not collecting pf stats here, but simple MRTG or anything else
that can poll a numeric value from SNMP and plot it would do the
trick.

A walk starting from .1.3.6.1.4.1.30155 to see what's available already
(snmpwalk's default OID doesn't end up recursing into the OpenBSD MIBs).

(I am collecting sensors data via LibreNMS which has support for
OPENBSD-SENSORS-MIB committed upstream).

> I would be most interested in
> LibreNMS/Observium. Also how difficult would be to write PF plugin for
> PF? Somebody apparently tried
>
> https://github.com/darinkes/collectd-pf

That's a hacked-up 7 year old copy of pfctl with the license removed,
it's not going to be all that much use now.

> https://collectd.org/wiki/index.php/Plugin:PF

>From a quick look at the code I think this collects information about
number of states etc, like pfctl -si shows, collecting it from PF
rather than via snmpd where the information is also available.
It really depends what you're interested in monitoring as to whether
it will be useful.

Re: VMM VM - 'dummy' based driver-based X11 server inside, not possible?

[Jiri B]

On Fri, Feb 16, 2018 at 12:19:44AM -0800, Mike Larkin wrote:
> Xvfb + x11vnc worked fine in the test I just did.

Yes, it does, thanks for confirmation.

I was curious why X11 'dummy' mode does not if it should be
used in environments without graphical card for headless X11
server.

Maybe it does not work as our xf86-video-dummy is old,
https://github.com/freedesktop/xorg-xf86-video-dummy/commit/87249af5faf85c8d093e910c069faa4db0aee843#diff-67e997bcfdac55191033d57a16d1408a

I'll stick to Xvfb for now and I'll give a try to build
newer xf86-video-dummy.

Jiri

Re: VMM VM - 'dummy' based driver-based X11 server inside, not possible?

[Mike Larkin]

On Fri, Feb 16, 2018 at 03:14:49AM -0500, Jiri B wrote:
> On Thu, Feb 15, 2018 at 06:48:53PM -0800, Mike Larkin wrote:
> > > > what are you trying to accomplish?
> > > 
> > > A persistent remote display session, ie. xenodm->wm or users one 
> > > accessible
> > > via VNC with x11vnc.
> > > 
> > I found a solution to do this with about 1 minute of google searching. What
> > are you finding difficult?
> 
> I'm not sure I can follow.
> 
> I would be happy to listen for your proposal for my use case.
> 
> I'll try to clarify my use case further. I'd like to attach of a persistent
> remote display session in screen/tmux-like manner.
> 
> IIUC a 'persistent' disqualifies X11 forwarding over SSH, and it
> disqualifies usage of "remote" DISPLAY=$ip:$display too.
> 
> Thus, IIUC, X11 server needs to run on remote OS as well, and because the VM
> does not have real graphical card, it does need a kind of fake X11 server.
> 
> Xvfb or X11 native 'dummy'-driver based solution should work, the graphics
> itself can be later attached in screen/tmux-like manner via VNC for example.
> 
> Solutions I'm aware:
> 
> - X11 forwarding (not persistent)
> - X11 with remote DISPLAY (not persistent)
> - X11 'dummy' driver (not working in VMM VM)
> - Xvfb (works but seems slower/obsoleted by X11 native 'dummy' driver)
> 
> Thank you for help.
> 
> Jiri
> 
> 

Xvfb + x11vnc worked fine in the test I just did.

Re: VMM VM - 'dummy' based driver-based X11 server inside, not possible?

[Jiri B]

On Thu, Feb 15, 2018 at 06:48:53PM -0800, Mike Larkin wrote:
> > > what are you trying to accomplish?
> > 
> > A persistent remote display session, ie. xenodm->wm or users one accessible
> > via VNC with x11vnc.
> > 
> I found a solution to do this with about 1 minute of google searching. What
> are you finding difficult?

I'm not sure I can follow.

I would be happy to listen for your proposal for my use case.

I'll try to clarify my use case further. I'd like to attach of a persistent
remote display session in screen/tmux-like manner.

IIUC a 'persistent' disqualifies X11 forwarding over SSH, and it
disqualifies usage of "remote" DISPLAY=$ip:$display too.

Thus, IIUC, X11 server needs to run on remote OS as well, and because the VM
does not have real graphical card, it does need a kind of fake X11 server.

Xvfb or X11 native 'dummy'-driver based solution should work, the graphics
itself can be later attached in screen/tmux-like manner via VNC for example.

Solutions I'm aware:

- X11 forwarding (not persistent)
- X11 with remote DISPLAY (not persistent)
- X11 'dummy' driver (not working in VMM VM)
- Xvfb (works but seems slower/obsoleted by X11 native 'dummy' driver)

Thank you for help.

Jiri