Recent security patch cause reboot loop on 11.1 RELEASE

[Denis Polygalov]

What I did is following:

# uname -a
FreeBSD my_host_name 11.1-RELEASE-p10 FreeBSD 11.1-RELEASE-p10 #0: Tue
May 8 05:21:56 UTC 2018
ro...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64

# freebsd-update fetch
Looking up update.FreeBSD.org mirrors... 3 mirrors found.
Fetching metadata signature for 11.1-RELEASE from update6.freebsd.org... done.
Fetching metadata index... done.
Inspecting system... done.
Preparing to download files... done.

The following files will be updated as part of updating to 11.1-RELEASE-p11:
/boot/kernel/kernel

Installing this update cause endless reboot loop.

# cat /boot/loader.conf
kern.maxfiles="32768"
zfs_load="YES"
linux_load="YES"
linprocfs_load="YES"
linsysfs_load="YES"

# dmesg |grep CPU
CPU: Intel(R) Xeon(TM) CPU 3.40GHz (3400.19-MHz K8-class CPU)
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
SMP: AP CPU #1 Launched!
SMP: AP CPU #3 Launched!
SMP: AP CPU #2 Launched!
cpu0: <ACPI CPU> on acpi0
cpu1: <ACPI CPU> on acpi0
cpu2: <ACPI CPU> on acpi0
cpu3: <ACPI CPU> on acpi0
acpi_perf0: <ACPI CPU Frequency Control> on cpu0
est: CPU supports Enhanced Speedstep, but is not recognized.
est: CPU supports Enhanced Speedstep, but is not recognized.
est: CPU supports Enhanced Speedstep, but is not recognized.

The machine is HP ProLiant ML350

Regards,
Denis
_______________________________________________
freebsd-...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-securi...@freebsd.org"

[Gordon Tetlow]

Sorry to hear you are having a problem.

Just to confirm, this is running on hardware and not on a Xen
hypervisor, correct?

Assuming it's running directly on the hardware, can you see if setting:
hw.lazy_fpu_switch=1
in /boot/loader.conf makes any difference?

Is there any panic message?

Thanks,
Gordon

[Denis Polygalov]

Seems like I did not cc my reply to the mailing list.
Doing it now because I found a hint which may
lead to the cause of the reboot loop.

Removing:

linux_load="YES"
linprocfs_load="YES"
linsysfs_load="YES"

prevent the reboot loop in multi-user mode but
leave me without Linux emulation...

Regards,
Denis.

> Hi Gordon,
>
> this is real hardware. I found the reason (see below).
> Setting hw.lazy_fpu_switch=1 in /boot/loader.conf makes no difference.
> No panic messages.
> I can tell you when it happen. Here is the boot messages:
> ... skipped ...
> Timecounters tick every 1.000 msec
> nvme cam probe device init
> ugen2.1: <Intel EHCI root HUB> at usbus2
> ugen1.1: <Intel UHCI root HUB> at usbus1
> ugen0.1: <Intel UHCI root HUB> at usbus0
> uhub0: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus2
> uhub1: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0
> uhub2: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus1
> uhub1: 2 ports with 2 removable, self powered
> uhub2: 2 ports with 2 removable, self powered
> uhub0: 4 ports with 4 removable, self powered
>
> <---- here screen (local monitor) goes black and machine restarted.
>
> ada0 at ata2 bus 0 scbus8 target 0 lun 0
> ada0: <WDC WD2000FYYZ-01UL1B1 01.01K02> ATA8-ACS SATA 3.x device
> ada0: Serial Number WD-WMC1P0D1KEHJ
> ada0: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes)
> ada0: 1907729MB (3907029168 512 byte sectors)
> da0 at ciss0 bus 0 scbus0 target 0 lun 0
> da0: <HP RAID 5 OK> Fixed Direct Access SCSI device
> da0: 135.168MB/s transfers
> da0: Command Queueing enabled
> da0: 858293MB (1757784604 512 byte sectors)
> Trying to mount root from ufs:/dev/da0s1a [rw]...
>
> I noticed that I can boot the *patched* kernel in single user mode.
> Removing these 3 lines from the /boot/loader.conf fixed rebooting loop problem:

>
> linux_load="YES"
> linprocfs_load="YES"
> linsysfs_load="YES"
>

> This machine is used as a test bench to test stuff
> before deploying on a production server.
> We need Linux emulation support on the production
> server to run closed source software...
> So... maybe this will help someone.
>
> Blaming evil penguins,
> Denis

[Johannes Meixner]

If you put those modules into rc.conf's kld_list, will it reboot as well?

According to the manpage, rc.conf is the faster way to load modules not
essential to booting.

[Gordon Tetlow]

Hmm. I'm unable to reproduce the error in any of my testing scenarios.
I apologize for not being to help further. As kib advised, if you can
please post a verbose dmesg from a successful boot along with where
you believe the panic occurs on a bad boot.

Gordon

[Denis Polygalov]

Hi Gordon,

I was about to make the verbose dmesg output as requested but before doing so
I did just # kldload linux.so on the patched kernel. Nothing bad happend.
Then I restarted with linux_* lines enabled in the loader.conf and
choose verbose dmesg in boot menu. Boot and ... everything was OK.
Then non-verbose dmesg and linux_* lines enabled - no problems.
So _suddenly_ it is fixed. I had 3 enters into reboot loops yesterday...
I will send the verbose dmesg by separated e-mail.

Regards,
Denis