Re: Installation Media Self Integrity Check

[Jordan Geoghegan]

On 2020-08-12 21:30, Dan Peretz wrote:

Hello, the FAQ states this:
"The installXX.iso and installXX.fs images do not contain an
SHA256.sig file, so the installer will complain that it can't check
the signature of the included sets [...] This is because it would make
no sense for the installer to verify them. If someone were to make a
rogue installation image, they could certainly change the installer to
say the files were legitimate."
Although that's true for intentional modifications, it would still be
useful to have the installation medium perform a self integrity check
against accidental or natural data corruption. For example, Ubuntu
recently enabled a by-default integrity check, starting with release
20.04:
"Ubuntu now defaults to checking the integrity of the medium in use
when booting into live sessions. This can be skipped by hitting
Ctrl-C. We’ve enabled this because failed installs due to corrupt
downloads of installation media is one of the most common error
conditions that users encounter." (Source:
)
I would like to have OpenBSD include at least an unsigned SHA256 file
in the discs. The installer would then detect that the checksums are
unsigned and warn about the security implications, but it would let
the user run the check. I think it would be wise to make it check the
bsd.rd image that's actually booted when booting from the disc, and
not just the bsd.rd file set. (I get that the OpenBSD installer is
just a multipurpose "bsd.rd" RAM disk that can be found not just in
the installation discs, right?)

Thank you!



I think the whole idea is to check the ISO itself with signify before 
you even boot/write it. If you're concerned about whether the ISO was 
written to your install media correctly (or its integrity after the 
fact), then it should be pretty straightforward to check if the hashes 
match up. Once you've verified the SHA256 file from the mirrors, you 
know the hashes are valid (and if you're worried about MITM/compromised 
web hosts, the signify keys are published all over social media and 
blogs etc). Signify does its best to cope with the chicken and the egg 
problem (and everything that comes with trusting trust), but at the end 
of the day, you have to draw the line somewhere.


If you're spooked about the SHA256.sig warning, then you can install 
over the network from a mirror, but ultimately it's irrelevant. Check 
your ISO with signify and you're good to go.

Re: Installation Media Self Integrity Check

[Theo de Raadt]

Dan Peretz  wrote:

> Thank you for responding, Theo :)
> 
> On Thu, Aug 13, 2020 at (...):59 AM Theo de Raadt  wrote:
> >
> > the FAQ is wrong.
> >
> > Those images don't contain signatures because my build & sign
> > procedure does not have a way to sign something, then continue
> > building, then sign the result.
> >
> >
> > If you looked, you would see there is an unsigned SHA256 file.
> >
> 
> Yes, I opened the install ISO and I see. I also read the INSTALL.amd64
> doc. Maybe change the FAQ to something like this?
> "[...] If someone were to make a rogue installation image, they could
> certainly change the installer to say the files were legitimate.
> Regardless, an unsigned SHA256 file is used by the installation to
> detect accidental corruption in the file sets. If the distribution
> sets do not match their recorded checksums, the installation program
> will complain."

I disagree with your direction.  

You are now explaining to someone how to create invalid images,
rather than 


> > It already uses the SHA256 file to determine which files to install,
> > this is done, but a hash is not a cryptographic signature, so the warning
> > issued is accurate.
> >
> 
> Maybe also rephrase the warning by the installer to something like
> this, to make it clearer to the admin that the installer does not skip
> verification *completely*:
> "Directory does not contain SHA256.sig. Continue without verifying
> authenticity? (The sets will still be verified against accidental
> corruption with SHA256.) [no]"

I disagree.  I think it is good enough the way it is.  I don't think
People need to know all the details behind a warning.

> > Huh.  What you are asking for cannot be done.  And obviously a bogus
> > image would declare that it isn't bogus.
> >
> 
> True, but I meant that if the ISO boots a BSD.RD file, then the
> ramdisk (booted from that exact file) would verify the checksum of
> that file, from the disc. Obviously not from RAM. It's not foolproof,
> and it surely doesn't help against malicious alterations, but I think
> this is better than not doing so...

What you describe cannot be done.  You aren't thinking critically.

Re: aggr(4) not working with Intel XXV710 SFP28 on a Supermicro X11DPi-N(T)

[Hrvoje Popovski]

On 12.8.2020. 15:18, Winfred Harrelson wrote:
> On Tue, Aug 11, 2020 at 07:52:10PM +0100, Tom Smyth wrote:
>> Hi Winfred,
>> the intel 710 is a complex card,  I would suggest that you try updating the
>> firmware on the card, available from intel.com or your card vendor,
>> you may have to boot to a live linux cd to apply the firmware update,
>>
>> but I had some issues with the Intel XL710 cards and I had to update the
>> firmware to get it working stable,
>>
>> I hope this helps
>> Tom Smyth
> 
> Adding misc@openbsd.org back to the CC for the record.
> 
> Thanks for the quick reply.  I didn't reply back yesterday because I
> was having trouble getting the firmware updated from a Linux boot disk.
> I ended up having to try from a Windows boot disk.  Unfortunately, I
> am getting the same thing again:
> 
> 
> wharrels@styx2:/home/wharrels# dmesg | grep ^ixl
> ixl0 at pci5 dev 0 function 0 "Intel XXV710 SFP28" rev 0x02: port 0, FW 
> 8.0.61820 API 1.11, msix, 8 queues, address 3c:fd:fe:ed:b7:28
> ixl1 at pci5 dev 0 function 1 "Intel XXV710 SFP28" rev 0x02: port 1, FW 
> 8.0.61820 API 1.11, msix, 8 queues, address 3c:fd:fe:ed:b7:29
> ixl2 at pci8 dev 0 function 0 "Intel XXV710 SFP28" rev 0x02: port 0, FW 
> 8.0.61820 API 1.11, msix, 8 queues, address 3c:fd:fe:eb:19:b0
> ixl3 at pci8 dev 0 function 1 "Intel XXV710 SFP28" rev 0x02: port 1, FW 
> 8.0.61820 API 1.11, msix, 8 queues, address 3c:fd:fe:eb:19:b1
> ixl4 at pci12 dev 0 function 0 "Intel X722 10GBASE-T" rev 0x09: port 0, FW 
> 3.1.57069 API 1.5, msix, 8 queues, address 3c:ec:ef:1a:df:f2
> ixl5 at pci12 dev 0 function 1 "Intel X722 10GBASE-T" rev 0x09: port 1, FW 
> 3.1.57069 API 1.5, msix, 8 queues, address 3c:ec:ef:1a:df:f3
> 
> Yup, all the XXV710 cards have been updated to newest firmware.
> 
> Now for the (failed) attempt:
> 
> wharrels@styx2:/etc# ifconfig ixl0
> ixl0: flags=8843 mtu 1500
> lladdr 3c:fd:fe:ed:b7:28
> index 1 priority 0 llprio 3
> media: Ethernet autoselect (25GbaseSR full-duplex)
> status: active
> wharrels@styx2:/etc# ifconfig ixl2 
> ixl2: flags=8843 mtu 1500
> lladdr 3c:fd:fe:eb:19:b0
> index 3 priority 0 llprio 3
> media: Ethernet autoselect (25GbaseSR full-duplex)
> status: active
> wharrels@styx2:/etc# ifconfig aggr1 create
> wharrels@styx2:/etc# ifconfig aggr1 trunkport ixl0
> wharrels@styx2:/etc# ifconfig aggr1 trunkport ixl2
> wharrels@styx2:/etc# ifconfig aggr1 up
> wharrels@styx2:/etc# ifconfig aggr1
> aggr1: flags=8843 mtu 1500
> lladdr fe:e1:ba:d0:7c:e9
> index 11 priority 0 llprio 7
> trunk: trunkproto lacp
> trunk id: [(8000,fe:e1:ba:d0:7c:e9,000B,,),
>  (,00:00:00:00:00:00,,,)]
> ixl0 lacp actor system pri 0x8000 mac fe:e1:ba:d0:7c:e9, key 
> 0xb, port pri 0x8000 number 0x1
> ixl0 lacp actor state activity,aggregation,defaulted
> ixl0 lacp partner system pri 0x0 mac 00:00:00:00:00:00, key 
> 0x0, port pri 0x0 number 0x0
> ixl0 lacp partner state activity,aggregation,sync
> ixl0 port 
> ixl2 lacp actor system pri 0x8000 mac fe:e1:ba:d0:7c:e9, key 
> 0xb, port pri 0x8000 number 0x3
> ixl2 lacp actor state activity,aggregation,defaulted
> ixl2 lacp partner system pri 0x0 mac 00:00:00:00:00:00, key 
> 0x0, port pri 0x0 number 0x0
> ixl2 lacp partner state activity,aggregation,sync
> ixl2 port 
> groups: aggr
> media: Ethernet autoselect
> status: no carrier
> 
> 
> 
> I tried doing another sysupgrade this morning just in case something
> had changed overnight but no luck.  Any other ideas?
> 
> Winfred
> 

Hi,

could you try install snapshot from http://ftp.hostserver.de/archive/
that is older than Thu Jun 25 06:41:38 2020 UTC ...

maybe this commit broke xxv710
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/pci/if_ixl.c?rev=1.56&content-type=text/x-cvsweb-markup

i have vlans over aggr over x710-da2 with latest snapshot and it's
working as expected ..

ixl0 at pci1 dev 0 function 0 "Intel X710 SFP+" rev 0x02: port 0, FW
7.3.60988 API 1.10, msix, 8 queues
ixl1 at pci1 dev 0 function 1 "Intel X710 SFP+" rev 0x02: port 1, FW
7.3.60988 API 1.10, msix, 8 queues

could  you send output from these two commands ..
ifconfig ixl sff
ifconfig ixl media

Re: Installation Media Self Integrity Check

[Dan Peretz]

Thank you for responding, Theo :)

On Thu, Aug 13, 2020 at (...):59 AM Theo de Raadt  wrote:
>
> the FAQ is wrong.
>
> Those images don't contain signatures because my build & sign
> procedure does not have a way to sign something, then continue
> building, then sign the result.
>
>
> If you looked, you would see there is an unsigned SHA256 file.
>

Yes, I opened the install ISO and I see. I also read the INSTALL.amd64
doc. Maybe change the FAQ to something like this?
"[...] If someone were to make a rogue installation image, they could
certainly change the installer to say the files were legitimate.
Regardless, an unsigned SHA256 file is used by the installation to
detect accidental corruption in the file sets. If the distribution
sets do not match their recorded checksums, the installation program
will complain."

>
> It already uses the SHA256 file to determine which files to install,
> this is done, but a hash is not a cryptographic signature, so the warning
> issued is accurate.
>

Maybe also rephrase the warning by the installer to something like
this, to make it clearer to the admin that the installer does not skip
verification *completely*:
"Directory does not contain SHA256.sig. Continue without verifying
authenticity? (The sets will still be verified against accidental
corruption with SHA256.) [no]"

>
> Huh.  What you are asking for cannot be done.  And obviously a bogus
> image would declare that it isn't bogus.
>

True, but I meant that if the ISO boots a BSD.RD file, then the
ramdisk (booted from that exact file) would verify the checksum of
that file, from the disc. Obviously not from RAM. It's not foolproof,
and it surely doesn't help against malicious alterations, but I think
this is better than not doing so...

Firefox Security 2020

[Kevin Chadwick]

With the recent news. I decided to take a look again at Firefox and after a days
use on multiple systems, it even seems to be faster than Chrome.

I notice significant work on pledge support. Does anyone know if it's comparable
to Chrome on that front now or still held back by not being designed with
isolation in mind?

What do people think about rlbox?

https://hacks.mozilla.org/2020/02/securing-firefox-with-webassembly/

Is Rust delivering security benefits for firefox?

USB speakers

[Justin Muir]

Wondering whether anyone has experience with Logitech USB speakers?

Plugged in mine, did the rcctl rsnd/0 thingi from multimedia FAQ:
# rcctl set sndiod flags -f rsnd/0 -F rsnd/1
# rcctl restart sndiod

It doesn't work. As a matter of fact, the speaker light doesn't even come
on now.

Any suggestions?


tia!

J

Dmesg output below:

uaudio0 at uhub4 port 2 configuration 1 interface 1 "Logitech Logitech USB
Speaker" rev 1.10/0.07 addr 3
uaudio0: class v1, full-speed, sync, channels: 2 play, 0 rec, 7 ctls
audio1 at uaudio0
uhidev2 at uhub4 port 2 configuration 1 interface 2 "Logitech Logitech USB
Speaker" rev 1.10/0.07 addr 3
uhidev2: iclass 3/0
uhid3 at uhidev2: input=2, output=0, feature=0

Re: X11 VESA Driver Config Question

[Jon Fineman]

- Original message -
From: Chris Bennett 
To: Jon Fineman , misc@openbsd.org
Subject: Re: X11 VESA Driver Config Question
Date: Wednesday, August 12, 2020 4:33 AM

On Tue, Aug 11, 2020 at 08:17:01PM -0400, Jon Fineman wrote:
> I just upgraded from 6.6 to snapshot via sysupgrade -s
> 
> After reboot I get the various emails the upgrade goes fine, no errors,
> the firmware is upgraded.
> 
> About 30 seconds after I get the login prompt the laptop powers off.
> 
> I turned in on and at the boot prompt typed boot -c and disable amdgpu 
> Subjectively I got more than 30 seconds after the boot prompt. I was
> able to log in and look around a bit and it powered off.
> 
> Same thing with booting into single user mode.
> 
> Thoughts? Suggestions on how to get any data?
> 
> Jon
> 

> sysctl.conf needs
> machdep.allowaperture=2
> 
> if you can't mount from another computer, burn 6.6 onto a USB stick and
> mount from that. Don't even try from running -current.
> You can probably get /var/run/dmesg.boot. Plus /var/log/Xorg.0.log if
> you manage to get to X. (Good luck with that :-{ )
> 
> I was given advice in the past to build with a certain change, but I was
> unable to build that on my laptop due to very little memory.
> 
> There is newer firmware, X, etc.. Hopefully someone will chime in with
> something to try for a build
> 
> Chris Bennett


As suggested I installed 6.7 Release on a USB drive and booted from that. 
I was able to get /var/log/messages which I appended at the bottom. The only
other logs were install.resp and pflog which was empty.

Jon


> 
> 
> On Mon, 10 Aug 2020 20:28:34 -0500
> Chris Bennett  wrote:
> 
> > On Sun, Aug 09, 2020 at 10:02:24PM -0400, Jon Fineman wrote:
> > > I have an Acer Aspire A315 laptop that freezes every once in a
> > > while. I think it is GPU related, but have not been able to get any
> > > logs. In addition a while ago (roughly when 6.7 came out) I tried
> > > to upgrade from 6.6 to 6.7 and the laptop would turn off just after
> > > getting the log in prompt. Again no logs.
> > > 
> > > One thought was in my xorg.conf file to change the driver from
> > > AMDGPU to vesa. However that is producing an error. Log and dmesg
> > > below.
> > > 
> > > Any thoughts on how to proceed?
> > >   
> > 
> > There is an excellent chance that we have the same problem.
> > I was running -current for a long while, when I had the same problem
> > with sudden unexpected shutdown. This was a good while back.
> > I have 50GB of install66.iso from current back then. They are on one
> > of my servers. Unfortunately, I just don't have access to enough
> > bandwidth or data to download them to hopefully find the date that
> > there was a change that messed things up.
> > 
> > Try boot -c then disable amdgpu
> > Might help. Also try boot -s and wait. If it shuts down there too,
> > probably have the same problem. Or not. :-)
> > 
> > I'm stuck at 6.6 -stable for now.
> > 
> > Chris Bennett
> > 
> > 
> > > Thnaks.
> > > 
> > > Jon
> > > 
> > > 
> > > xorg.conf:
> > > Section "Device"
> > > Identifier "graphicsdriver"
> > > #Driver "AMDGPU"
> > > #Option "TearFree" "true"
> > > Driver "vesa"
> > > EndSection
> > > 
> > > 
> > > 
> > > Xorg.0.log:
> > > [124569.415] (--) checkDevMem: using aperture driver /dev/xf86
> > > [124569.425] (--) Using wscons driver on /dev/ttyC4
> > > [124569.446] 
> > > X.Org X Server 1.20.5
> > > X Protocol Version 11, Revision 0
> > > [124569.446] Build Operating System: OpenBSD 6.6 amd64 
> > > [124569.446] Current Operating System: OpenBSD laptop.jonjfineman.me
> > > 6.6 GENERIC.MP#3 amd64 [124569.447] Build Date: 30 July 2020
> > > 11:25:30AM [124569.447]  
> > > [124569.447] Current version of pixman: 0.38.4
> > > [124569.447]  Before reporting problems, check
> > > http://wiki.x.org to make sure that you have the latest version.
> > > [124569.447] Markers: (--) probed, (**) from config file, (==)
> > > default setting, (++) from command line, (!!) notice, (II)
> > > informational, (WW) warning, (EE) error, (NI) not implemented, (??)
> > > unknown. [124569.447] (==) Log file: "/var/log/Xorg.0.log", Time:
> > > Sun Aug  9 05:48:55 2020 [124569.447] (==) Using config file:
> > > "/etc/X11/xorg.conf" [124569.447] (==) Using system config directory
> > > "/usr/X11R6/share/X11/xorg.conf.d" [124569.447] (==) No Layout
> > > section. Using the first Screen section. [124569.447] (==) No
> > > screen section available. Using defaults. [124569.447] (**)
> > > |-->Screen "Default Screen Section" (0) [124569.447] (**) |
> > > |-->Monitor "" [124569.448] (==) No device
> > > specified for screen "Default Screen Section". Using the first
> > > device section listed. [124569.448] (**) |   |-->Device
> > > "graphicsdriver" [124569.448] (==) No monitor specified for screen
> > > "Default Screen Section". Using a default monitor configuration.
> > > [124569.448] (==) Automatically adding devices
> > > [124569.448] (==) Automatically enabli

Re: How many IPs can I block before taking a performance hit?

[Alan McKay]

So here is a related question - I want to implement something like
what some of you folks seem to have in place with dynamically updated
blacklists and reloading pf on the fly.

With a redundant pair of firewalls should I be doing this on the MASTER only?
I'm just wondering about reloading pf on the BACKUP and because state
tables are synced is there going to be any kind of negative effect on
MASTER in terms of performance or even the fact that MASTER will be
doing the reload at the same time.

It is relatively easy to detect whether or not I am MASTER and then
only do that if so.

Should I be doing that or will it matter?

Re: sensor value last change time not updated?

[Hiltjo Posthuma]

On Fri, Aug 14, 2020 at 01:46:57PM +0200, Paul de Weerd wrote:
> Hi all,
> 
> I'm trying to read temperature sensor values from my ugold(4) device.
> Seems to work alright (I get the same temperature reading as sysctl(8)
> returns for the sensor), but the 'sensor value last change time'
> doesn't seem to be updated.
> 
> [weerd@pom] $ cat sensor_last_change.c  
> #include 
> #include 
> #include 
> #include 
> 
> int
> main()
> {
>   int mib[5];
>   size_t  sensorlen;
>   struct sensor   sensor;
> 
>   mib[0] = CTL_HW;
>   mib[1] = HW_SENSORS;
>   mib[2] = 3; /* ugold0 on my machine */
>   mib[3] = SENSOR_TEMP;
>   mib[4] = 0;
> 
>   sensorlen = sizeof(sensor);
>   sysctl(mib, 5, &sensor, &sensorlen, NULL, 0);
>   printf("%lld.%06ld: %.2f\n",
>   sensor.tv.tv_sec,
>   sensor.tv.tv_usec,
>   ((sensor.value-27315)/100.0));
> 
>   return 0;
> }
> [weerd@pom] $ make sensor_last_change   
> cc -O2 -pipe   -MD -MP   -o sensor_last_change sensor_last_change.c 
> [weerd@pom] $ ./sensor_last_change
> 0.00: 32.32
> [weerd@pom] $ sysctl -n hw.sensors.ugold0.temp0
> 32.32 degC (inner)
> 
> The 'tv' member of struct sensor seems to always be 0.0.  Am I doing
> something wrong?
> 
> Cluesticks very welcome...
> 
> Thanks,
> 
> Paul
> 
> -- 
> >[<++>-]<+++.>+++[<-->-]<.>+++[<+
> +++>-]<.>++[<>-]<+.--.[-]
>  http://www.weirdnet.nl/ 
> 

Hi,

I don't think you're doing anything wrong, but I don't think its supported by
the device and it's simply not set and so stays zero.

A quick grep shows some files which do use it:

/usr/src/sys $ grep -R sc_sensor\.tv .
./dev/gpio/gpiodcf.c:   microtime(&sc->sc_sensor.tv);
./dev/pv/hypervic.c:microtime(&sc->sc_sensor.tv);
./dev/pv/vmt.c: struct timeval *guest = &sc->sc_sensor.tv;
./dev/pv/vmmci.c:   struct timeval  *guest = &sc->sc_sensor.tv;
./dev/usb/udcf.c:   microtime(&sc->sc_sensor.tv);

I have a ugold(4) device and will gladly test any improvements/patches.

-- 
Kind regards,
Hiltjo

sensor value last change time not updated?

[Paul de Weerd]

Hi all,

I'm trying to read temperature sensor values from my ugold(4) device.
Seems to work alright (I get the same temperature reading as sysctl(8)
returns for the sensor), but the 'sensor value last change time'
doesn't seem to be updated.

[weerd@pom] $ cat sensor_last_change.c  
#include 
#include 
#include 
#include 

int
main()
{
int mib[5];
size_t  sensorlen;
struct sensor   sensor;

mib[0] = CTL_HW;
mib[1] = HW_SENSORS;
mib[2] = 3; /* ugold0 on my machine */
mib[3] = SENSOR_TEMP;
mib[4] = 0;

sensorlen = sizeof(sensor);
sysctl(mib, 5, &sensor, &sensorlen, NULL, 0);
printf("%lld.%06ld: %.2f\n",
sensor.tv.tv_sec,
sensor.tv.tv_usec,
((sensor.value-27315)/100.0));

return 0;
}
[weerd@pom] $ make sensor_last_change   
cc -O2 -pipe   -MD -MP   -o sensor_last_change sensor_last_change.c 
[weerd@pom] $ ./sensor_last_change
0.00: 32.32
[weerd@pom] $ sysctl -n hw.sensors.ugold0.temp0
32.32 degC (inner)

The 'tv' member of struct sensor seems to always be 0.0.  Am I doing
something wrong?

Cluesticks very welcome...

Thanks,

Paul

-- 
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
 http://www.weirdnet.nl/