Re: fw_update verify firmware?

2020-05-14 Thread Theo de Raadt
Aaron Mason wrote: > On Fri, May 15, 2020 at 3:39 AM Nick Holland > wrote: > > > > On 2020-05-14 11:08, i...@aulix.com wrote: > > > > I actually had Adaptec give me a firmware update with a time bomb in > > it, and didn't bother to tell me that after X days, it would brick my > > adapter and

ULTRASPARC vs ARMv7 (Sun Netra T1 vs Orange PI ONE) from ONLY a security point of view

2020-05-14 Thread Глеб Рахмановский
  Dear Gurus, Please let me know, are there any advantages of UltraSparc IIe over Cortex A7 AllWinner H3 for a secure communication host ignoring a factor of power efficiency, size and loud noise? IMHO the only feature OpenBSD can benefit from UltraSparc is StackGhost ?    

Re: fw_update verify firmware?

2020-05-14 Thread Aaron Mason
On Fri, May 15, 2020 at 3:39 AM Nick Holland wrote: > > On 2020-05-14 11:08, i...@aulix.com wrote: > > I actually had Adaptec give me a firmware update with a time bomb in > it, and didn't bother to tell me that after X days, it would brick my > adapter and prevent me from updating/downdating it.

Re: fw_update verify firmware?

2020-05-14 Thread Marc Espie
On Thu, May 14, 2020 at 04:25:11AM +, Mogens Jensen wrote: > I was just trying out the fw_update program on OpenBSD 6.5, deleting/ > installing all the firmware and was wondering if fw_update will verify > the files before installing? Others pointed out that firmwares are signed. For a while

Re: fw_update verify firmware?

2020-05-14 Thread Theo de Raadt
Nick Holland wrote: > On 2020-05-14 11:08, i...@aulix.com wrote: > >> If that binary code was on a ROM, would it be less malicious? > > > > Cannot more recent and up to date binary code be more malicious than > > old one in the ROM? > > This has nothing to do with OpenBSD. That can be true

Re: fw_update verify firmware?

2020-05-14 Thread Nick Holland
On 2020-05-14 11:08, i...@aulix.com wrote: >> If that binary code was on a ROM, would it be less malicious? > > Cannot more recent and up to date binary code be more malicious than > old one in the ROM? This has nothing to do with OpenBSD. That can be true for any kind of code update, whether

Re: fw_update verify firmware?

2020-05-14 Thread Theo de Raadt
i...@aulix.com wrote: > > If that binary code was on a ROM, would it be less malicious? > > Cannot more recent and up to date binary code be more malicious than old one > in the ROM? Our firmwares do not replace code on ROM, since the hardware in question HAS NO ROM.

Re: fw_update verify firmware?

2020-05-14 Thread info
> If that binary code was on a ROM, would it be less malicious? Cannot more recent and up to date binary code be more malicious than old one in the ROM? Just because backdoor development is progressing as time goes and old backdoors may be less dangerous compared to modern ones? > If the

Re: fw_update verify firmware?

2020-05-14 Thread Theo de Raadt
Janne Johansson wrote: > Den tors 14 maj 2020 kl 06:27 skrev Mogens Jensen < > mogens-jen...@protonmail.com>: > > > Normally I would just assume that fetched files are verified, but maybe > > in the case with fw_update, the rationale is that firmware files are > > binary blobs so we can't know

Re: Intel CPU (in)security

2020-05-14 Thread info
> Inside every modern Intel CPU is a secondary CPU running an embedded OS with direct access to nice things like all the RAM, AES acceleration hardware, TMP etc. So we have since Core2Duo at least following : IntelME - can be vanished by Libreboot Important BLOBS (even in Coreboot) for hardware

Re: Intel CPU (in)security

2020-05-14 Thread Anders Andersson
On Thu, May 14, 2020 at 1:54 PM wrote: > > Please suggest what has been cleaned by moderators on the website: > > https://web.archive.org/web/20200514115002/https://www.reddit.com/r/openbsd/comments/gf7wip/how_secure_are_intel_cpus/fpshspb/ No. But this link may be informative:

Intel CPU (in)security

2020-05-14 Thread info
Please suggest what has been cleaned by moderators on the website: https://web.archive.org/web/20200514115002/https://www.reddit.com/r/openbsd/comments/gf7wip/how_secure_are_intel_cpus/fpshspb/

Re: using aggr interface instead of trunk

2020-05-14 Thread mabi
Hi Iain, ‐‐‐ Original Message ‐‐‐ On Wednesday, May 13, 2020 7:55 PM, Iain R. Learmonth wrote: > More details are at:https://marc.info/?l=openbsd-cvs=156229058006706=2 I actually already read that one after seeing the announcement on undeadly.org iirc ;) > Assuming you mean trunk,

Re: Intel I210 Fiber Optic Ethernet Card Transceiver Info.

2020-05-14 Thread Stuart Henderson
On 2020-05-13, Vertigo Altair wrote: > Hi, > > > Sorry for late reply but I had a problem accessing this device. > > I’ve tried both OpenBSD 6.6 and 6.7 (amd64), nothing changed: > > I think you’re probably right; transceiver command is only available for > ix(4) driver. AFAIK the list is: ix,

Re: fw_update verify firmware?

2020-05-14 Thread Stuart Henderson
On 2020-05-14, Mogens Jensen wrote: > I was just trying out the fw_update program on OpenBSD 6.5, deleting/ > installing all the firmware and was wondering if fw_update will verify > the files before installing? > > There is a SHA256.sig in the remote firmware directory, but no > indication from

fw_update verify firmware?

2020-05-14 Thread Mogens Jensen
I was just trying out the fw_update program on OpenBSD 6.5, deleting/ installing all the firmware and was wondering if fw_update will verify the files before installing? There is a SHA256.sig in the remote firmware directory, but no indication from fw_update, even with verbose output, if this is

Re: fw_update verify firmware?

2020-05-14 Thread Janne Johansson
Den tors 14 maj 2020 kl 06:27 skrev Mogens Jensen < mogens-jen...@protonmail.com>: > Normally I would just assume that fetched files are verified, but maybe > in the case with fw_update, the rationale is that firmware files are > binary blobs so we can't know if they are malicious anyway,