>An area that I am personally interested in is running >OpenBSD on fully open-source / binary-blob-free >hardware: hardware where there is no proprietary >firmware that could hide vendor backdoors, and >ideally where even the design of the chip is available >to the user for review.
(Heck yes)^2 Of course this is hours of deep conversation away from something even approaching a realistic plan of attack; but Paul, with his embedded sys leanings might be in a good position to move things (slowly) forward. To the benefit of all computer security, everywhere. Personally, I envision a sort of "open source BIOS" library in the distant future. Something we jack in on jtag if we have to. There is no harm in *starting.* Meanwhile, my super productive Dell laptop can't keep me from wondering what the SMM is doing during the SMI, while obsd or any other OS sleeps. -x* every install. On Tue, Feb 19, 2019 at 9:36 PM Frank Beuth <secli...@boxdan.com> wrote: > On Thu, Feb 14, 2019 at 04:22:05AM +0000, Paul Swanson wrote: > >I have some general areas of interest, such as embedded > >computing, but nothing is set in stone yet, so I thought it'd > >be fun to hear from those in know about areas of priority need > >within the OpenBSD community. > > > >Are there particular problems that could benefit from new > >ideas or solutions? > > An area that I am personally interested in is running OpenBSD on fully > open-source / binary-blob-free hardware: hardware where there is no > proprietary > firmware that could hide vendor backdoors, and ideally where even the > design of > the chip is available to the user for review. > > The trouble is it's VERY hard to find "fully open" hardware, and the > hardware > which is known to exist (loongson, OpenPOWER, RISC V) is difficult to get, > expensive or not very good, and (except for loongson) not supported by > OpenBSD. > >
