Re: fd0 at fdc0 drive 0: density unknown

[Theo de Raadt]

> > The old behavior was that the kernel would wait after the "fdc0 ..." line 
> > until fd0 attaches. Now it does the waiting in the background and continues 
> > booting. I agree that it's a bit ugly, but it makes booting about 5 seconds 
> > faster.
> 
> It's not just a bit ugly... It's horrible. It has to go. I'm surprised
> noone has reverted this crazy change yet.

usb devices attach late all the time also.

Tony, your opinion counts for very little around here -- quite a few
rungs below my cats...

Re: fd0 at fdc0 drive 0: density unknown

[Tony Montana]

> The old behavior was that the kernel would wait after the "fdc0 ..." line 
> until fd0 attaches. Now it does the waiting in the background and continues 
> booting. I agree that it's a bit ugly, but it makes booting about 5 seconds 
> faster.

It's not just a bit ugly... It's horrible. It has to go. I'm surprised
noone has reverted this crazy change yet.

Re: OT - "Intel Management Engine" security issues

[Aaron Marcher]

Hi,

I am writing this from a Thinkpad T420 with Coreboot flashed and the
Intel Management Engine disabled!

recently there was a lot of work done regarding disabling/neutralizing
the ME.

Have a look at this:
http://blog.ptsecurity.com/2017/08/disabling-intel-me.html
https://github.com/corna/me_cleaner
And of course Libreboot.

And yes, the Intel ME has a lot of access to the system and could/can do
more than you want to. It even runs a whole operating system based on
Minix.
http://blog.ptsecurity.com/2017/04/intel-me-way-of-static-analysis.html

Regards,
Aaron

-- 
Web: https://drkhsh.at/ or http://drkhsh5rv6pnahas.onion/
Gopher: gopher://drkhsh.at or gopher://drkhsh5rv6pnahas.onion
GPG: 0x09e71697435bf54b
Fingerprint: 57D2 5F2C 9402 A6BD FEF9 B3B6 09E7 1697 435B F54B

Re: OT - "Intel Management Engine" security issues

[Bryan Everly]

Dave,
You might want to take a look at both the Libreboot and Coreboot open
source projects.  The challenge with the IME is that if you literally
disable it, it will shut down the system - and it's code is pretty
heavily encrypted.  The Coreboot project has had some limited success
reverse-engineering how it works and can disable it in some cases but
it is very motherboard and CPU version specific which makes it
extremely difficult.
I'm running Libreboot with OpenBSD on a Thinkpad T500 and it works
reasonably well with the exception that I'm still figuring out how to
get full disk encryption working.  Coreboot is something I plan on
experimenting with as well because it can be (mostly) de-blobbed and
supports some more modern hardware.
- B
On Fri, 2017-09-08 at 14:51 -0400, Dave Anderson wrote:
> While this isn't specifically an OpenBSD issue, since OpenBSD
> emphasizes 
> security this seems like a good place to ask.
> 
> As far as I can tell the "Intel Management Engine" (IME) is a gaping 
> backdoor into every recent Intel-based system. My searches on the
> 'net 
> haven't turned up much useful information about it.
> 
> I'd really like to find documentation on how to configure and use
> it, 
> though I'd settle for just enough to know how to lock it down or
> disable 
> it such that it can't be used to attack me from the 'net.
> 
> While this wouldn't work for a laptop, for desktop systems it might
> be 
> sufficient to use an add-in NIC rather than the built-in one -- but
> the 
> limited info I've found suggests that the IME may be able to snoop
> on 
> all devices and so defeat this tactic. Does anyone here know?
> 
> Thanks for any information,
> 
> Dave
> 
> -- 
> Dave Anderson
> 
> 
> 

Re: OT - "Intel Management Engine" security issues

[Carl Mascott]

It can't be used to attack you from the public Internet unless (a) you don't 
have a firewall or (b) you have forwarded the IME port on your firewall to a 
host on your LAN. You are, however, susceptible to other hosts on your LAN 
guessing the IME password, so be sure to use a strong password.

On my old HP dc7900 IME is unconfigured and disabled out of the box.If 
resetting BIOS to defaults doesn't disable it, removing the motherboard battery 
for 30 minutes should do the trick.

You should be able to find an administrator's manual for IME via Google Search.


  From: Dave Anderson 
 To: misc@openbsd.org 
 Sent: Friday, September 8, 2017 2:52 PM
 Subject: OT - "Intel Management Engine" security issues
   
While this isn't specifically an OpenBSD issue, since OpenBSD emphasizes 
security this seems like a good place to ask.

As far as I can tell the "Intel Management Engine" (IME) is a gaping 
backdoor into every recent Intel-based system. My searches on the 'net 
haven't turned up much useful information about it.

I'd really like to find documentation on how to configure and use it, 
though I'd settle for just enough to know how to lock it down or disable 
it such that it can't be used to attack me from the 'net.

While this wouldn't work for a laptop, for desktop systems it might be 
sufficient to use an add-in NIC rather than the built-in one -- but the 
limited info I've found suggests that the IME may be able to snoop on 
all devices and so defeat this tactic. Does anyone here know?

Thanks for any information,

     Dave

-- 
Dave Anderson




   

OT - "Intel Management Engine" security issues

[Dave Anderson]

While this isn't specifically an OpenBSD issue, since OpenBSD emphasizes 
security this seems like a good place to ask.


As far as I can tell the "Intel Management Engine" (IME) is a gaping 
backdoor into every recent Intel-based system. My searches on the 'net 
haven't turned up much useful information about it.


I'd really like to find documentation on how to configure and use it, 
though I'd settle for just enough to know how to lock it down or disable 
it such that it can't be used to attack me from the 'net.


While this wouldn't work for a laptop, for desktop systems it might be 
sufficient to use an add-in NIC rather than the built-in one -- but the 
limited info I've found suggests that the IME may be able to snoop on 
all devices and so defeat this tactic. Does anyone here know?


Thanks for any information,

Dave

--
Dave Anderson

Re: Intel NUC Kit DE3815TYKHE

[flipchan]

You mean OpenBSD 6.1 right?

On September 8, 2017 2:33:46 PM GMT+02:00, Artur Pedziwilk 
 wrote:
>Have anyone of you got that model of Intel NUC?
>
>Intel® NUC Kit DE3815TYKHE
>https://ark.intel.com/products/78577/Intel-NUC-Kit-DE3815TYKHE
>https://www.intel.com/content/dam/support/us/en/documents/boardsandkits/DE3815TYBE_TechProdSpec.pdf
>
>
>I am trying to find some small computer to use with OpenBSD 6.2.
>I am especially interested to play/test the OpenBSD with Intel Atom and
>Intel AES-NI.
>
>
>I am not sure at all if the driver
>https://man.openbsd.org/re
>Realtek 8139C+/8169/816xS/811xS/8168/810xE 10/100/Gigabit Ethernet
>device
>
>will support
>Realtek 8111GN-CG Gigabit Ethernet Controller (10/100/1000 Mb/s)
>of this board.
>
>Anyone can confirm it does/doesn't work?
>
>
>I am aware I have to have dummy VGA plug to be able to boot without
>display.
>
>
>Regards,
>Artur

-- 
Take Care Sincerely flipchan layerprox dev

Intel NUC Kit DE3815TYKHE

[Artur Pedziwilk]

Have anyone of you got that model of Intel NUC?

Intel® NUC Kit DE3815TYKHE
https://ark.intel.com/products/78577/Intel-NUC-Kit-DE3815TYKHE
https://www.intel.com/content/dam/support/us/en/documents/boardsandkits/DE3815TYBE_TechProdSpec.pdf


I am trying to find some small computer to use with OpenBSD 6.2.
I am especially interested to play/test the OpenBSD with Intel Atom and Intel 
AES-NI.


I am not sure at all if the driver
https://man.openbsd.org/re
Realtek 8139C+/8169/816xS/811xS/8168/810xE 10/100/Gigabit Ethernet device

will support
Realtek 8111GN-CG Gigabit Ethernet Controller (10/100/1000 Mb/s)
of this board.

Anyone can confirm it does/doesn't work?


I am aware I have to have dummy VGA plug to be able to boot without display.


Regards,
Artur

Re: After updating to latest snapshot xession crashes

[Niels Kobschätzki]

On 17/09/08 09:51, Stuart Henderson wrote:

On 2017-09-08, Niels Kobschätzki  wrote:

On 17/09/08 08:42, Niels Kobschätzki wrote:

Hi,

after I updated to the snapshot from September 7th, I cannot log into X
anymore. xdm comes up but logging in brings me directly back to xdm.
The xenodm.log say "XIO: fatail IO error 35"
dmesg, Xorg.0.log and xenodm.log are attached.

Any help is appreciated.


I got it working again after removing all the stuff I had in my
.xession for setting up the trackpoint via xinput.


Please be more specific. "all the stuff" is not a useful bug report.


I removed the following from my .xsession to get things working again.:
# activate scroll wheel button
xinput set-prop "/dev/wsmouse" "WS Pointer Wheel Emulation" 1
xinput set-prop "/dev/wsmouse" "WS Pointer Wheel Emulation Axes" 6 7 4 5
xinput set-prop "/dev/wsmouse" "WS Pointer Wheel Emulation Button" 2
xinput set-prop "/dev/wsmouse" "WS Pointer Wheel Emulation Timeout" 50
xinput set-prop "/dev/wsmouse" "WS Pointer Wheel Emulation Inertia" 3

# increase pointer speed
xinput set-prop "/dev/wsmouse" "Device Accel Constant Deceleration" 0.4


The wifi worked suddenly again automagically after a couple of reboots
oO

Niels

Re: After updating to latest snapshot xession crashes

[Stuart Henderson]

On 2017-09-08, Niels Kobschätzki  wrote:
> On 17/09/08 08:42, Niels Kobschätzki wrote:
>>Hi,
>>
>>after I updated to the snapshot from September 7th, I cannot log into X
>>anymore. xdm comes up but logging in brings me directly back to xdm. 
>>The xenodm.log say "XIO: fatail IO error 35"
>>dmesg, Xorg.0.log and xenodm.log are attached.
>>
>>Any help is appreciated.
>
> I got it working again after removing all the stuff I had in my
> .xession for setting up the trackpoint via xinput.

Please be more specific. "all the stuff" is not a useful bug report.



> Now I need to get wifi working again…this update made a lot of problems…
>
> Niels
>
>

Re: Banana-Pi R2

[Stefan Fritsch]

On Wednesday, 6 September 2017 19:18:49 CEST Rui Ribeiro wrote:
> I once booted netbsd in my Banana Pi/Lamobo R1, which is a similar machine
> from "the same manufacturer"; the bigger problem is that outside Linux,
> there is no support for the Broadcom switching chipset.

The R2 is a completely different board (different SoC, different switch chip, 
both from mediatek). So in this case it's not only the switch chip but also 
the SoC that is not supported by openbsd.

Re: fd0 at fdc0 drive 0: density unknown

[Stefan Fritsch]

On Thursday, 7 September 2017 19:15:31 CEST Arfnokill wrote:
> Using snapshots on amd64. Since two days ago the kernel prints this fd0 at
> fdc0 drive 0: density unknown very late during boot.
> 
> It starts reordering libraries, and BAM... fd0 at fdc0 drive 0: density
> unknown in blue background. It's just cosmetic I guess, but it's
> uncomfortable.
> 
> Anybody else seeing this with recent snapshots?

The old behavior was that the kernel would wait after the "fdc0 ..." line 
until fd0 attaches. Now it does the waiting in the background and continues 
booting. I agree that it's a bit ugly, but it makes booting about 5 seconds 
faster.

Re: After updating to latest snapshot xession crashes

[Niels Kobschätzki]

On 17/09/08 08:42, Niels Kobschätzki wrote:

Hi,

after I updated to the snapshot from September 7th, I cannot log into X
anymore. xdm comes up but logging in brings me directly back to xdm. 
The xenodm.log say "XIO: fatail IO error 35"

dmesg, Xorg.0.log and xenodm.log are attached.

Any help is appreciated.


I got it working again after removing all the stuff I had in my
.xession for setting up the trackpoint via xinput.

Now I need to get wifi working again…this update made a lot of problems…

Niels

After updating to latest snapshot xession crashes

[Niels Kobschätzki]

Hi,

after I updated to the snapshot from September 7th, I cannot log into X
anymore. xdm comes up but logging in brings me directly back to xdm. 
The xenodm.log say "XIO: fatail IO error 35"

dmesg, Xorg.0.log and xenodm.log are attached.

Any help is appreciated.

Niels

xdm info (pid 31376): Starting
xdm info (pid 31376): Starting X server on :0

X.Org X Server 1.18.4
Release Date: 2016-07-19
X Protocol Version 11, Revision 0
Build Operating System: OpenBSD 6.2 amd64 
Current Operating System: OpenBSD netcat.InterDotNet.DE 6.2 GENERIC.MP#79 amd64
Build Date: 07 September 2017  11:59:45AM
 
Current version of pixman: 0.34.0
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Fri Sep  8 08:40:00 2017
(==) Using system config directory "/usr/X11R6/share/X11/xorg.conf.d"
xdm info (pid 39872): sourcing /etc/X11/xenodm/Xsetup_0
xdm info (pid 39872): sourcing /etc/X11/xenodm/GiveConsole
xdm info (pid 60282): executing session /etc/X11/xenodm/Xsession
xdm info (pid 39872): sourcing /etc/X11/xenodm/TakeConsole
XIO:  fatal IO error 35 (Resource temporarily unavailable) on X server ":0"
  after 165 requests (134 known processed) with 0 events remaining.
xdm info (pid 31376): Starting X server on :0
1 XSELINUXs still allocated at reset
SCREEN: 0 objects of 560 bytes = 0 total bytes 0 private allocs
DEVICE: 0 objects of 96 bytes = 0 total bytes 0 private allocs
CLIENT: 0 objects of 200 bytes = 0 total bytes 0 private allocs
WINDOW: 0 objects of 64 bytes = 0 total bytes 0 private allocs
PIXMAP: 0 objects of 136 bytes = 0 total bytes 0 private allocs
GC: 0 objects of 40 bytes = 0 total bytes 0 private allocs
CURSOR: 1 objects of 8 bytes = 8 total bytes 0 private allocs
SYNC_FENCE: 0 objects of 8 bytes = 0 total bytes 0 private allocs
TOTAL: 1 objects, 8 bytes, 0 allocs
1 CURSORs still allocated at reset
CURSOR: 1 objects of 8 bytes = 8 total bytes 0 private allocs
SYNC_FENCE: 0 objects of 8 bytes = 0 total bytes 0 private allocs
TOTAL: 1 objects, 8 bytes, 0 allocs
1 CURSOR_BITSs still allocated at reset
SYNC_FENCE: 0 objects of 8 bytes = 0 total bytes 0 private allocs
TOTAL: 0 objects, 0 bytes, 0 allocs
xdm info (pid 2159): sourcing /etc/X11/xenodm/Xsetup_0
(II) AIGLX: Suspending AIGLX clients for VT switch
[25.441] (--) checkDevMem: using aperture driver /dev/xf86
[25.452] (--) Using wscons driver on /dev/ttyC4
[25.476] 
X.Org X Server 1.18.4
Release Date: 2016-07-19
[25.476] X Protocol Version 11, Revision 0
[25.476] Build Operating System: OpenBSD 6.2 amd64 
[25.476] Current Operating System: OpenBSD netcat.InterDotNet.DE 6.2 
GENERIC.MP#79 amd64
[25.476] Build Date: 07 September 2017  11:59:45AM
[25.476]  
[25.476] Current version of pixman: 0.34.0
[25.476]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[25.476] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[25.476] (==) Log file: "/var/log/Xorg.0.log", Time: Fri Sep  8 08:40:00 
2017
[25.480] (==) Using system config directory 
"/usr/X11R6/share/X11/xorg.conf.d"
[25.481] (==) No Layout section.  Using the first Screen section.
[25.481] (==) No screen section available. Using defaults.
[25.481] (**) |-->Screen "Default Screen Section" (0)
[25.482] (**) |   |-->Monitor ""
[25.484] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[25.484] (==) Disabling SIGIO handlers for input devices
[25.484] (==) Automatically adding devices
[25.484] (==) Automatically enabling devices
[25.484] (==) Not automatically adding GPU devices
[25.484] (==) Max clients allowed: 256, resource mask: 0x1f
[25.499] (==) FontPath set to:
/usr/X11R6/lib/X11/fonts/misc/,
/usr/X11R6/lib/X11/fonts/TTF/,
/usr/X11R6/lib/X11/fonts/OTF/,
/usr/X11R6/lib/X11/fonts/Type1/,
/usr/X11R6/lib/X11/fonts/100dpi/,
/usr/X11R6/lib/X11/fonts/75dpi/
[25.499] (==) ModulePath set to "/usr/X11R6/lib/modules"
[25.499] (II) The server relies on wscons to provide the list of input 
devices.
If no devices become available, reconfigure wscons or disable 
AutoAddDevices.
[25.499] (II) Loader magic: 0x189f2539000
[25.499] (II) Module ABI versions:
[25.499]X.Org ANSI C Emulation: 0.4
[25.499]X.Org Video Driver: 20.0
[25.499]X.Org XInput driver : 22.1
[25.499]X.Org Server Extension : 9.0
[25.500] (--) PCI:*(0:0:2:0) 8086:1916:17aa:5053 rev