Re: Help: System hang/Lockup using snapshots on Intel i5 NUC?

[Raul Miller]

You might also try testing that memory on that machine is not faulty.

(I've been struggling with an ongoing onslaught of machines with faulty memory.)

FYI,

-- 
Raul

On Fri, Mar 6, 2020 at 6:19 PM Raymond, David  wrote:
>
> You might try an alternate desktop/window manager such as lxqt or
> icewm and see if the problem persists.  When I tried XFCE on my X1
> carbon laptop, XFCE was not so nice, though I can't remember the
> details at this point.
>
> Dave Raymond
>
> On 3/5/20, Why 42? The lists account.  wrote:
> >
> > Hi All,
> >
> > We've been running OpenBSD on a server for several years now and its been
> > reliable with minimal issues, so I thought I would also like to try it as
> > a desktop system.
> >
> > Thus I've been experimenting with an Intel NUC 8i5BEH running OpenBSD
> > current snapshots and with XFCE as the Windowing system. And it all works
> > very nicely. So well in fact that I've added an SSD, NFS mounted my old
> > Linux box and rsynced over my home directory. OpenBSD as my main desktop
> > system!
> >
> > For the most part everything has gone well, I have only noticed one
> > serious issue so far: The complete system hangs intermittently. Which is
> > naturally a bit of a downer :(.
> >
> > When this happens the mouse is frozen, the capslock LED on the (USB)
> > keyboard doesn't light up and the system doesn't respond to ssh. To
> > recover I have to hold down the power switch to shutoff the system, then
> > turn it on again, reboot and examine the resulting fsck errors.
> >
> > I have impression this often occurs when using a Web browser. At first
> > when I used Iridium, then Chrome, it seemed to happen every few hours.
> > When I switched to trying Firefox, then the hangs seemed to occur less
> > often, maybe every day or two. Perhaps I'm doing less browsing because of
> > the hangs :).
> >
> > The graphics driver being used is: inteldrm0 at pci0 dev 2 function 0
> > "Intel Iris Plus Graphics 655" rev 0x01
> >
> > I can leave the system running, sitting at the xenodm screen, for days
> > without issue. I've also done a couple of complete memtest86 runs without
> > error. I've even upgraded to the latest BIOS/firmware version.
> >
> > I've increased maxproc and maxfiles in sysctl.conf and also set
> > ddb.panic=0 thinking that the behaviour might change to a panic+reboot
> > instead of a hang, but this made no difference.
> >
> > After a hang + reboot there is nothing obvious in the log files.
> >
> > Any suggestions how to further debug such an issue?
> >
> > The OpenBSD kernel tells me that there is a serial port / UART (com0 at
> > isa0 port 0x3f8/8 irq 4: ns16550 ...) but I've taken the NUC to pieces
> > and I cannot see anything on the board that looks like a serial port
> > header.
> >
> > The kernel does log a few of dubious messages at boot time. There are
> > several instances of "not configured". And there is one occurrence of
> > "mem address conflict 0xfe01/0x1000". I don't know if these are
> > relevant, generally the system seems quite stable. Until it isn't. If you
> > see what I mean. (See below for a complete set of boot time messages).
> >
> > I would be grateful for any support in debugging, or even better,
> > resolving this issue.
> >
> > Cheers,
> > Robb.
> >
> > mjoelnir:log 5.03 23:22:54 # dmesg
> > OpenBSD 6.6-current (GENERIC.MP) #20: Sat Feb 29 14:38:12 MST 2020
> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > real mem = 34201518080 (32617MB)
> > avail mem = 33152389120 (31616MB)
> > mpath0 at root
> > scsibus0 at mpath0: 256 targets
> > mainbus0 at root
> > bios0 at mainbus0: SMBIOS rev. 3.2 @ 0x7a9a4000 (77 entries)
> > bios0: vendor Intel Corp. version "BECFL357.86A.0077.2019.1127.1452" date
> > 11/27/2019
> > bios0: Intel(R) Client Systems NUC8i5BEH
> > acpi0 at bios0: ACPI 6.1
> > acpi0: sleep states S0 S3 S4 S5
> > acpi0: tables DSDT FACP APIC FPDT FIDT MCFG SSDT SSDT HPET SSDT SSDT UEFI
> > LPIT SSDT SSDT DBGP DBG2 DMAR SSDT NHLT BGRT TPM2 WSMT
> > acpi0: wakeup devices SIO1(S3) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4)
> > PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4)
> > PXSX(S4) RP08(S4) [...]
> > acpitimer0 at acpi0: 3579545 Hz, 24 bits
> > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> > cpu0 at mainbus0: apid 0 (boot processor)
> > cpu0: Intel(R) Core(TM) i5-8259U CPU @ 2.30GHz, 9182.89 MHz, 06-8e-0a
> > 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,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
> > cpu0: 256KB 64b/line 8-way L2 cache
> > cpu0: smt 0, core 0, 

Re: Compiling Zeek 3.0.2 returns an error at final stage

[Monah Baki]

>From the server if you curl a website, in zeek log current folder do you
see a http.log file, and after changing the interface did you zeekctl
deploy.

Thanks
Monah



On Sat, Mar 7, 2020 at 5:42 PM Carlos Lopez  wrote:

> Thanks Monah … But this is not the problem … interface configuration is
> correct …
>
>
>
> --
>
> Regards,
>
> C. L. Martinez
>
>
>
> *From: *Monah Baki 
> *Date: *Saturday, 7 March 2020 at 23:30
> *To: *Carlos Lopez 
> *Cc: *"misc@openbsd.org" 
> *Subject: *Re: Compiling Zeek 3.0.2 returns an error at final stage
>
>
>
> Hi Carlos,
>
>
>
> Check your node.cfg, the interface section
>
>
>
> [zeek]
> type=standalone
> host=localhost
> interface=eth0   << might want to change it
>
>
>
> On Sat, Mar 7, 2020 at 5:01 PM Carlos Lopez  wrote:
>
> Many thanks for your answer Stuart ... Finally, I have compiled Zeek
> 3.0.3-dev.3 an all goes ok during compilation ... But zeek doesn't capture
> any packet ... and tcpdump works without problems and I can see all traffic
> ...
>
> --
> Regards,
> C. L. Martinez
>
> On 07/03/2020, 22:08, "owner-m...@openbsd.org on behalf of Stuart
> Henderson" 
> wrote:
>
> On 2020-03-07, Carlos Lopez  wrote:
> > Hi all,
> >
> >  I am trying to install Zeek 3.0.2 under OpenBSD 6.6 amd64 fully
> patched but compilation returns me the following error:
> >
> > [ 97%] Building C object src/CMakeFiles/zeek.dir/nb_dns.c.o
> > [ 97%] Linking CXX executable zeek
> > ld: error: unable to find library -llibbinpac.so.VERSION
> > c++: error: linker command failed with exit code 1 (use -v to see
> invocation)
> > *** Error 1 in build (src/CMakeFiles/zeek.dir/build.make:1826
> 'src/zeek')
> > *** Error 1 in build (CMakeFiles/Makefile2:1661
> 'src/CMakeFiles/zeek.dir/all')
> > *** Error 1 in build (Makefile:152 'all')
> > *** Error 1 in /root/builds/src/zeek-3.0.2 (Makefile:15 'all')
> >
> >  But libbinpac.so exists compiled under the source dirs.:
> >
> > root@obsd66:~/builds/src/zeek-3.0.2# find . -name "*binpac.so"
> > ./build/aux/binpac/lib/libbinpac.so
> > root@obsd66:~/builds/src/zeek-3.0.2
> >
> >  Any tip to solve this issue?
> >
>
> You're probably better off using the port. There is a fair chance that
> if you update *just* the net/bro directory (the port dir wasn't renamed
> but the package was) to -current that it will build, and if not, you'll
> be closer to getting it working.
>
> Or the easy option, update to -current, pkg_add zeek.
>
>
>

Re: Compiling Zeek 3.0.2 returns an error at final stage

[Carlos Lopez]

Thanks Monah … But this is not the problem … interface configuration is correct 
…

--
Regards,
C. L. Martinez

From: Monah Baki 
Date: Saturday, 7 March 2020 at 23:30
To: Carlos Lopez 
Cc: "misc@openbsd.org" 
Subject: Re: Compiling Zeek 3.0.2 returns an error at final stage

Hi Carlos,

Check your node.cfg, the interface section

[zeek]
type=standalone
host=localhost
interface=eth0   << might want to change it

On Sat, Mar 7, 2020 at 5:01 PM Carlos Lopez 
mailto:clo...@outlook.com>> wrote:
Many thanks for your answer Stuart ... Finally, I have compiled Zeek 
3.0.3-dev.3 an all goes ok during compilation ... But zeek doesn't capture any 
packet ... and tcpdump works without problems and I can see all traffic ...

--
Regards,
C. L. Martinez

On 07/03/2020, 22:08, "owner-m...@openbsd.org on 
behalf of Stuart Henderson" 
mailto:owner-m...@openbsd.org> on behalf of 
s...@spacehopper.org> wrote:

On 2020-03-07, Carlos Lopez mailto:clo...@outlook.com>> 
wrote:
> Hi all,
>
>  I am trying to install Zeek 3.0.2 under OpenBSD 6.6 amd64 fully patched 
but compilation returns me the following error:
>
> [ 97%] Building C object src/CMakeFiles/zeek.dir/nb_dns.c.o
> [ 97%] Linking CXX executable zeek
> ld: error: unable to find library -llibbinpac.so.VERSION
> c++: error: linker command failed with exit code 1 (use -v to see 
invocation)
> *** Error 1 in build (src/CMakeFiles/zeek.dir/build.make:1826 'src/zeek')
> *** Error 1 in build (CMakeFiles/Makefile2:1661 
'src/CMakeFiles/zeek.dir/all')
> *** Error 1 in build (Makefile:152 'all')
> *** Error 1 in /root/builds/src/zeek-3.0.2 (Makefile:15 'all')
>
>  But libbinpac.so exists compiled under the source dirs.:
>
> root@obsd66:~/builds/src/zeek-3.0.2# find . -name "*binpac.so"
> ./build/aux/binpac/lib/libbinpac.so
> root@obsd66:~/builds/src/zeek-3.0.2
>
>  Any tip to solve this issue?
>

You're probably better off using the port. There is a fair chance that
if you update *just* the net/bro directory (the port dir wasn't renamed
but the package was) to -current that it will build, and if not, you'll
be closer to getting it working.

Or the easy option, update to -current, pkg_add zeek.

Re: Compiling Zeek 3.0.2 returns an error at final stage

[Monah Baki]

Hi Carlos,

Check your node.cfg, the interface section

[zeek]
type=standalone
host=localhost
interface=eth0   << might want to change it

On Sat, Mar 7, 2020 at 5:01 PM Carlos Lopez  wrote:

> Many thanks for your answer Stuart ... Finally, I have compiled Zeek
> 3.0.3-dev.3 an all goes ok during compilation ... But zeek doesn't capture
> any packet ... and tcpdump works without problems and I can see all traffic
> ...
>
> --
> Regards,
> C. L. Martinez
>
> On 07/03/2020, 22:08, "owner-m...@openbsd.org on behalf of Stuart
> Henderson" 
> wrote:
>
> On 2020-03-07, Carlos Lopez  wrote:
> > Hi all,
> >
> >  I am trying to install Zeek 3.0.2 under OpenBSD 6.6 amd64 fully
> patched but compilation returns me the following error:
> >
> > [ 97%] Building C object src/CMakeFiles/zeek.dir/nb_dns.c.o
> > [ 97%] Linking CXX executable zeek
> > ld: error: unable to find library -llibbinpac.so.VERSION
> > c++: error: linker command failed with exit code 1 (use -v to see
> invocation)
> > *** Error 1 in build (src/CMakeFiles/zeek.dir/build.make:1826
> 'src/zeek')
> > *** Error 1 in build (CMakeFiles/Makefile2:1661
> 'src/CMakeFiles/zeek.dir/all')
> > *** Error 1 in build (Makefile:152 'all')
> > *** Error 1 in /root/builds/src/zeek-3.0.2 (Makefile:15 'all')
> >
> >  But libbinpac.so exists compiled under the source dirs.:
> >
> > root@obsd66:~/builds/src/zeek-3.0.2# find . -name "*binpac.so"
> > ./build/aux/binpac/lib/libbinpac.so
> > root@obsd66:~/builds/src/zeek-3.0.2
> >
> >  Any tip to solve this issue?
> >
>
> You're probably better off using the port. There is a fair chance that
> if you update *just* the net/bro directory (the port dir wasn't renamed
> but the package was) to -current that it will build, and if not, you'll
> be closer to getting it working.
>
> Or the easy option, update to -current, pkg_add zeek.
>
>
>
>

Re: Compiling Zeek 3.0.2 returns an error at final stage

[Carlos Lopez]

Many thanks for your answer Stuart ... Finally, I have compiled Zeek 
3.0.3-dev.3 an all goes ok during compilation ... But zeek doesn't capture any 
packet ... and tcpdump works without problems and I can see all traffic ...

-- 
Regards,
C. L. Martinez

On 07/03/2020, 22:08, "owner-m...@openbsd.org on behalf of Stuart Henderson" 
 wrote:

On 2020-03-07, Carlos Lopez  wrote:
> Hi all,
>
>  I am trying to install Zeek 3.0.2 under OpenBSD 6.6 amd64 fully patched 
but compilation returns me the following error:
>
> [ 97%] Building C object src/CMakeFiles/zeek.dir/nb_dns.c.o
> [ 97%] Linking CXX executable zeek
> ld: error: unable to find library -llibbinpac.so.VERSION
> c++: error: linker command failed with exit code 1 (use -v to see 
invocation)
> *** Error 1 in build (src/CMakeFiles/zeek.dir/build.make:1826 'src/zeek')
> *** Error 1 in build (CMakeFiles/Makefile2:1661 
'src/CMakeFiles/zeek.dir/all')
> *** Error 1 in build (Makefile:152 'all')
> *** Error 1 in /root/builds/src/zeek-3.0.2 (Makefile:15 'all')
>
>  But libbinpac.so exists compiled under the source dirs.:
>
> root@obsd66:~/builds/src/zeek-3.0.2# find . -name "*binpac.so"
> ./build/aux/binpac/lib/libbinpac.so
> root@obsd66:~/builds/src/zeek-3.0.2
>
>  Any tip to solve this issue?
>

You're probably better off using the port. There is a fair chance that
if you update *just* the net/bro directory (the port dir wasn't renamed
but the package was) to -current that it will build, and if not, you'll
be closer to getting it working.

Or the easy option, update to -current, pkg_add zeek.

Re: heads up: amd64 snap

[Amit Kulkarni]

On Sat, Mar 7, 2020 at 1:25 PM Sebastien Marie  wrote:
>
> On Sat, Mar 07, 2020 at 11:03:10AM -0600, Amit Kulkarni wrote:
> >
> > Should I try to pull the boot
> > hard drive into another running system, and then manually try to copy
> > over a clean /bsd.mp on the next snapshot?
>
> just to complete what otto@ already said.
>
> the problem isn't the kernel (bsd.mp), so copying it manually will not solve 
> the
> problem. the problem is with the biosboot(8) file installed on the disk.
>
> to quote the man page of biosboot:
>
> This small program (roughly 512 bytes of code) is responsible for 
> loading
> the second-stage boot(8) program (typically /boot), which in turn will
> load the kernel.
>
> (see https://man.openbsd.org/biosboot.8 for complete explanation)
>
>
> to install it manually, you need installboot(8) command + biosboot(8) file (by
> default, it is using the one in /usr/mdec).
>
> unplugging the disk, put it in another machine, and next doing a upgrade will
> run the right command, so it is the more simple approch.
>

will do as you suggest.

Thanks

Re: heads up: amd64 snap

[Amit Kulkarni]

On Sat, Mar 7, 2020 at 11:15 AM Otto Moerbeek  wrote:
>
> On Sat, Mar 07, 2020 at 11:03:10AM -0600, Amit Kulkarni wrote:
>
> > Hi,
> >
> > How does this show itself?
> >
> > I have an older 2013 era system with Pentium G2020 or so (going from
> > memory here, so might be wrong), which does not go into OpenBSD
> > install. Just sits there with Dell logo. Only takes a Ctrl-Alt-Del
> > command for a reboot, and if I try to enter into BIOS, it does not. It
> > does not come into the OpenBSD boot prompt.
> >
> > I am trying to decide if this is due to the above changes or something
> > else, like hardware failure etc. I last installed a snapshot on it 3
> > days ago, and it has never come back up. Should I try to pull the boot
> > hard drive into another running system, and then manually try to copy
> > over a clean /bsd.mp on the next snapshot?
> >
> > thanks
> >
> > On Sat, Mar 7, 2020 at 9:20 AM Otto Moerbeek  wrote:
> > >
> > > It looks like some BIOS do not like the recent biosboot changes.
> > > Symptoms are a hang in the bios.
> > >
> > > I reverted them, the next amd64 snap should be ok again.
> > >
> > > -Otto
> > >
>
> Yes, this sounds very much like the issue I'm talking about.
>
> Updating the kernel will not help. The problem is in some bad
> interaction between *some* BIOS implementations and the updated
> biosboot.
>
> It is very likely that the disk will boot in another system without
> issues. On that system, install the new snap when it arrives. Then you
> can put the disk back in the problem system.
>
> There are probably workarounds, like putting the disk in another
> system and running an older installboot from that system on the disk
> containing the trouble.  But if you do not feel comfortable doing that
> please do an upgrade.
>
> And next time please try to report this earlier. The sooner we learn
> about these issues the better.
>

Sorry for not reporting earlier Otto, I sincerely thought this is a
hardware related issue, and was going to wait for the weekend to try
various things.

Thanks

Re: Compiling Zeek 3.0.2 returns an error at final stage

[Stuart Henderson]

On 2020-03-07, Carlos Lopez  wrote:
> Hi all,
>
>  I am trying to install Zeek 3.0.2 under OpenBSD 6.6 amd64 fully patched but 
> compilation returns me the following error:
>
> [ 97%] Building C object src/CMakeFiles/zeek.dir/nb_dns.c.o
> [ 97%] Linking CXX executable zeek
> ld: error: unable to find library -llibbinpac.so.VERSION
> c++: error: linker command failed with exit code 1 (use -v to see invocation)
> *** Error 1 in build (src/CMakeFiles/zeek.dir/build.make:1826 'src/zeek')
> *** Error 1 in build (CMakeFiles/Makefile2:1661 'src/CMakeFiles/zeek.dir/all')
> *** Error 1 in build (Makefile:152 'all')
> *** Error 1 in /root/builds/src/zeek-3.0.2 (Makefile:15 'all')
>
>  But libbinpac.so exists compiled under the source dirs.:
>
> root@obsd66:~/builds/src/zeek-3.0.2# find . -name "*binpac.so"
> ./build/aux/binpac/lib/libbinpac.so
> root@obsd66:~/builds/src/zeek-3.0.2
>
>  Any tip to solve this issue?
>

You're probably better off using the port. There is a fair chance that
if you update *just* the net/bro directory (the port dir wasn't renamed
but the package was) to -current that it will build, and if not, you'll
be closer to getting it working.

Or the easy option, update to -current, pkg_add zeek.

Re: heads up: amd64 snap

[Sebastien Marie]

On Sat, Mar 07, 2020 at 11:03:10AM -0600, Amit Kulkarni wrote:
> 
> Should I try to pull the boot
> hard drive into another running system, and then manually try to copy
> over a clean /bsd.mp on the next snapshot?

just to complete what otto@ already said.

the problem isn't the kernel (bsd.mp), so copying it manually will not solve the
problem. the problem is with the biosboot(8) file installed on the disk.

to quote the man page of biosboot:

This small program (roughly 512 bytes of code) is responsible for 
loading
the second-stage boot(8) program (typically /boot), which in turn will
load the kernel.

(see https://man.openbsd.org/biosboot.8 for complete explanation)


to install it manually, you need installboot(8) command + biosboot(8) file (by
default, it is using the one in /usr/mdec).

unplugging the disk, put it in another machine, and next doing a upgrade will
run the right command, so it is the more simple approch.

Thanks.
-- 
Sebastien Marie

Compiling Zeek 3.0.2 returns an error at final stage

[Carlos Lopez]

Hi all,

 I am trying to install Zeek 3.0.2 under OpenBSD 6.6 amd64 fully patched but 
compilation returns me the following error:

[ 97%] Building C object src/CMakeFiles/zeek.dir/nb_dns.c.o
[ 97%] Linking CXX executable zeek
ld: error: unable to find library -llibbinpac.so.VERSION
c++: error: linker command failed with exit code 1 (use -v to see invocation)
*** Error 1 in build (src/CMakeFiles/zeek.dir/build.make:1826 'src/zeek')
*** Error 1 in build (CMakeFiles/Makefile2:1661 'src/CMakeFiles/zeek.dir/all')
*** Error 1 in build (Makefile:152 'all')
*** Error 1 in /root/builds/src/zeek-3.0.2 (Makefile:15 'all')

 But libbinpac.so exists compiled under the source dirs.:

root@obsd66:~/builds/src/zeek-3.0.2# find . -name "*binpac.so"
./build/aux/binpac/lib/libbinpac.so
root@obsd66:~/builds/src/zeek-3.0.2

 Any tip to solve this issue?

-- 
Regards,
C. L. Martinez

Re: Hardening browser

[Luke A. Call]

On 03-07 19:19, whistlez...@riseup.net wrote:
> On Thu, Mar 05, 2020 at 07:32:36AM -0700, Luke A. Call wrote:
> > I just leave javascript off for usual browsing, with a tab sitting open
> > in chromium or iridium to turn it on for the occasional temporary need,
> > or added to the browser's exception list to allow permanently for
> > certain sites.  This partly because it seems easy, and partly since I 
> > probably won't know if a browser extension is sold to a malicious entity, or
> > otherwise compromised (so, seems a smaller attack surface, but still usually
> > convenient.)  
> As I know many sites without js doesn't work. Anyway I don't understand
> how switching off js defend you from 0day browser bug.
> Maybe you mean that because many 0day concern javascript ?

Yes, as well as the general category of speculative execution CPU
attacks, rowhammer-type attacks, evercookies that use javascript, 
and/or whatever else I don't know about that is enabled by javascript.
It just seems to be required for many attacks that one reads about, over
time, and given that trend, probably some future ones, all from
downloading unknown code to run locally.  For those fewer times when I do
enable it, I'm glad for OBSD's various protections, to further lower
risk.
-- 
Luke Call
My thoughts:  http://lukecall.net  (updated 2020-02-18)

Re: Hardening browser

[whistlez-ml]

On Thu, Mar 05, 2020 at 07:32:36AM -0700, Luke A. Call wrote:
> On 03-05 04:18, Tomasz Rola wrote:
> > On Wed, Mar 04, 2020 at 02:06:40AM +0100, whistlez...@riseup.net wrote:
> > > Hi,
> > > in the following message:
> > > https://marc.info/?l=openbsd-misc=158110613210895=2
> > > Theo discourages to use unveil instead of chroot.
> > > I asked if he suggests the same for the browser but he asked that chroot
> > > is onlye for *root*.
> > > Then what should I do to hardening the most exposed piece of code that
> > > we use everyday ?
> > > Now I'm using unveil+chrome...
> > > Thank you.
> > []
> > As of me, I use the trick with multiple users for different roles
> > (similar to other person who posted in this thread). I also employ
> > noscript in some of the roles. 
> 
> I just leave javascript off for usual browsing, with a tab sitting open
> in chromium or iridium to turn it on for the occasional temporary need,
> or added to the browser's exception list to allow permanently for
> certain sites.  This partly because it seems easy, and partly since I 
> probably won't know if a browser extension is sold to a malicious entity, or
> otherwise compromised (so, seems a smaller attack surface, but still usually
> convenient.)  

As I know many sites without js doesn't work. Anyway I don't understand
how switching off js defend you from 0day browser bug.
Maybe you mean that because many 0day concern javascript ?

Re: Hardening browser

[whistlez-ml]

On Wed, Mar 04, 2020 at 03:28:35PM +, Kevin Chadwick wrote:
> On 2020-03-04 11:38, Ottavio Caruso wrote:
> > Probably not what you were looking for but, back in the days when I
> > was ultra paranoid about my web browsing, I used to use stripped down
> > live usb installations of Linux distros (DSL was one of them that I
> > remember). I ignore if OpenBSD comes with such a solution out the box,
> > but I'm sure it wouldn't be difficult to make your own read-only
> > install. Then, you could either reboot from it or run it through an
> > emulator.
> 
> A live cd is read-only and is also something I did for a while in my teenage
> years. Knoppix, Insert were examples and STD was another aptly named one as it

a read only cd don't give you any defense againt uefi rootkit
> 
> However, considering OpenBSD replaces it's whole base every upgrade with 
> signed
> binaries, then you get all of that for free. You can even double check the 
> bios
> with flashrom (less so on laptops), bootloader, signing keys, packages etc., 
> if
> you want to.
>

if your kernel is infected with uefi rootkit most probably double check
uefi or bios with flashrom is absolutely not useful.

> If this effort is really worth it, then it probably makes more sense than
> trusting someone else to package up a usb linux distro or CD.
> 

the problem is not trusting people that make package, the problem is
the sites you visit. 

Re: heads up: amd64 snap

[Otto Moerbeek]

On Sat, Mar 07, 2020 at 11:03:10AM -0600, Amit Kulkarni wrote:

> Hi,
> 
> How does this show itself?
> 
> I have an older 2013 era system with Pentium G2020 or so (going from
> memory here, so might be wrong), which does not go into OpenBSD
> install. Just sits there with Dell logo. Only takes a Ctrl-Alt-Del
> command for a reboot, and if I try to enter into BIOS, it does not. It
> does not come into the OpenBSD boot prompt.
> 
> I am trying to decide if this is due to the above changes or something
> else, like hardware failure etc. I last installed a snapshot on it 3
> days ago, and it has never come back up. Should I try to pull the boot
> hard drive into another running system, and then manually try to copy
> over a clean /bsd.mp on the next snapshot?
> 
> thanks
> 
> On Sat, Mar 7, 2020 at 9:20 AM Otto Moerbeek  wrote:
> >
> > It looks like some BIOS do not like the recent biosboot changes.
> > Symptoms are a hang in the bios.
> >
> > I reverted them, the next amd64 snap should be ok again.
> >
> > -Otto
> >

Yes, this sounds very much like the issue I'm talking about.

Updating the kernel will not help. The problem is in some bad
interaction between *some* BIOS implementations and the updated
biosboot.

It is very likely that the disk will boot in another system without
issues. On that system, install the new snap when it arrives. Then you
can put the disk back in the problem system.

There are probably workarounds, like putting the disk in another
system and running an older installboot from that system on the disk
containing the trouble.  But if you do not feel comfortable doing that
please do an upgrade.

And next time please try to report this earlier. The sooner we learn
about these issues the better.

-Otto

Re: heads up: amd64 snap

[Amit Kulkarni]

Hi,

How does this show itself?

I have an older 2013 era system with Pentium G2020 or so (going from
memory here, so might be wrong), which does not go into OpenBSD
install. Just sits there with Dell logo. Only takes a Ctrl-Alt-Del
command for a reboot, and if I try to enter into BIOS, it does not. It
does not come into the OpenBSD boot prompt.

I am trying to decide if this is due to the above changes or something
else, like hardware failure etc. I last installed a snapshot on it 3
days ago, and it has never come back up. Should I try to pull the boot
hard drive into another running system, and then manually try to copy
over a clean /bsd.mp on the next snapshot?

thanks

On Sat, Mar 7, 2020 at 9:20 AM Otto Moerbeek  wrote:
>
> It looks like some BIOS do not like the recent biosboot changes.
> Symptoms are a hang in the bios.
>
> I reverted them, the next amd64 snap should be ok again.
>
> -Otto
>

heads up: amd64 snap

[Otto Moerbeek]

It looks like some BIOS do not like the recent biosboot changes. 
Symptoms are a hang in the bios.

I reverted them, the next amd64 snap should be ok again.

-Otto