From owner-freebsd-security@freebsd.org Fri Jun 22 05:27:22 2018 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ED34F100EB00 for ; Fri, 22 Jun 2018 05:27:21 +0000 (UTC) (envelope-from dpolyg@gmail.com) Received: from mail-pf0-x244.google.com (mail-pf0-x244.google.com [IPv6:2607:f8b0:400e:c00::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4A6C97F0D1 for ; Fri, 22 Jun 2018 05:27:21 +0000 (UTC) (envelope-from dpolyg@gmail.com) Received: by mail-pf0-x244.google.com with SMTP id h12-v6so2631480pfk.11 for ; Thu, 21 Jun 2018 22:27:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uZDY3vTxOWMSjrNvLm+aPmvGQOKDF3zU/4LFWFyhAdE=; b=k89EHl4+qN/8KS21hPk30wzCf5IMdZKmMvravyXKeY2wW8PrBesq/agmLr4R86ZFOv H0nnwN1Gz8HQSvnRAJ9PoEMflfbcTIaG0VxWdT9Bnr1Wv121P1dBW/oZT5Z8pzZYvl6W z056c5wbcWXWb6qQqu1gQhE+TwcGbQ2l6tXu6Gqp7FEF3XHVZZykA3D/d9rqOcn0/T+q 7zBtBWIpHxZJL3rMLVJQYuJcX2gsG0DRYEOq+vsJGxKrZ0naRaXjPLUK4NdykFFY4Nna UxuLx21TTxB/A4y/V0q9ZBqPnp8Wm7j1k9HT2ONU6nxMKkwwDkY2WwkNjqdL03C3E9Vw G3Dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uZDY3vTxOWMSjrNvLm+aPmvGQOKDF3zU/4LFWFyhAdE=; b=hWZs5cr97K59SNHdY9j9m16347wejoKKpNAjlx3EMXuDFdc4uPThdVXotfUium8Krh s4NtSGPedvTAc80M+LysOTPHDQEKdBMjUB77/ybtIXc5h2LXAYIbF9oT7lnfdlmMqBG3 GtU//3G1c8eE5QnZ5T0Q8jEcHJnblPxsIomwtvPN95fPjHNYt+T45z0lC26nH4uNDmSu qxULYiFR/br/uJUWui9W2yf4fRJ4QRLjRUTfKOSvLNqSB80nM52Pxqjxj41KXbiHcTow zDAotH0Sf1ciYBGjcCgeH5/CQ+QXuDOR4DHuCMcHddFTxA8mgCsF06J/lBUc9UYZbRhz S67A== X-Gm-Message-State: APt69E34WQFIffHLCzfjUeNw9GAokamx6l5WAvKMJ/SSgD8PE2zToeAP GvMEk7NX9nYifWUMty5SqlKIKP3fCaCIt6YTXtQ= X-Google-Smtp-Source: ADUXVKKuA6IUOkSSvaYgQTGRUdC7Na0n7WWKbT4rBOeJte5c+IiBGrN7nCkflYL4B9NiF4FW2IKMeXdenmkP7dfLMAs= X-Received: by 2002:a63:3807:: with SMTP id f7-v6mr116495pga.446.1529645240292; Thu, 21 Jun 2018 22:27:20 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:65c1:0:0:0:0 with HTTP; Thu, 21 Jun 2018 22:27:19 -0700 (PDT) In-Reply-To: References: From: Denis Polygalov Date: Fri, 22 Jun 2018 14:27:19 +0900 Message-ID: Subject: Re: Recent security patch cause reboot loop on 11.1 RELEASE To: Gordon Tetlow Cc: freebsd-security Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 05:27:22 -0000 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 On 6/22/18, Gordon Tetlow wrote: > 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 > > On Thu, Jun 21, 2018 at 5:13 AM, Denis Polygalov wrote: >> 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: at usbus2 >>> ugen1.1: at usbus1 >>> ugen0.1: at usbus0 >>> uhub0: on usbus2 >>> uhub1: on usbus0 >>> uhub2: 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: 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: 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 >> >> >> >> >> On 21/06/2018 4:19 PM, Gordon Tetlow wrote: >>> >>> On Wed, Jun 20, 2018 at 11:14 PM, Denis Polygalov >>> wrote: >>>> >>>> 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 >>>> root@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: on acpi0 >>>> cpu1: on acpi0 >>>> cpu2: on acpi0 >>>> cpu3: on acpi0 >>>> acpi_perf0: 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 >>> >>> >>> 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 >>> >> _______________________________________________ >> freebsd-security@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-security >> To unsubscribe, send any mail to >> "freebsd-security-unsubscribe@freebsd.org" >