From owner-freebsd-scsi@freebsd.org Wed Feb 21 19:10:35 2018 Return-Path: Delivered-To: freebsd-scsi@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 12AF6F21310 for ; Wed, 21 Feb 2018 19:10:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 64C156CE1D for ; Wed, 21 Feb 2018 19:10:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 7E4837B05 for ; Wed, 21 Feb 2018 19:10:33 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w1LJAXL5080581 for ; Wed, 21 Feb 2018 19:10:33 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w1LJAXtx080580 for freebsd-scsi@FreeBSD.org; Wed, 21 Feb 2018 19:10:33 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-scsi@FreeBSD.org Subject: [Bug 225794] VM images for 12.0-CURRENT have problem with USB 3.0 ports Date: Wed, 21 Feb 2018 19:10:33 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: avg@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-scsi@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 19:10:35 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D225794 Andriy Gapon changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |freebsd-usb@FreeBSD.org Assignee|freebsd-virtualization@Free |freebsd-scsi@FreeBSD.org |BSD.org | --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-scsi@freebsd.org Wed Feb 21 21:23:41 2018 Return-Path: Delivered-To: freebsd-scsi@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 82504F018E0 for ; Wed, 21 Feb 2018 21:23:41 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1E56B74022 for ; Wed, 21 Feb 2018 21:23:41 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 69BE810ECB for ; Wed, 21 Feb 2018 21:23:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w1LLNejQ074428 for ; Wed, 21 Feb 2018 21:23:40 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w1LLNei3074427 for freebsd-scsi@FreeBSD.org; Wed, 21 Feb 2018 21:23:40 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-scsi@FreeBSD.org Subject: [Bug 225794] VM images for 12.0-CURRENT have problem with USB 3.0 ports Date: Wed, 21 Feb 2018 21:23:40 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: David.Boyd49@twc.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-scsi@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 21:23:41 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D225794 --- Comment #16 from David.Boyd49@twc.com --- Andriy, I will run the camcontrol modepage commands as soon as possible. In order to "get something done", I carried the USB flash drive to a produc= tion VirtualBox server that has an NEC D720201 chipset for USB 3.0 ports. There I ran the following command "sg_modes -a -vvvvv /dev/passX" against t= he latest FreeBSD 12.0-CURRENT image. I did not have any issues with the command output being truncated due to errors. I also ran the command "sg_modes -a -vvvvv /dev/sdX" on several Linux-based VM's without incident. These were LinuxMint 18.3 and CentOS EL 6.9 systems. The test machine (where the problem was originally observed) has a VIA VL805 chipset. On that machine I ran the command "sg_modes -a -vvvvv /dev/sdX" on several Linux-based VM's. Each of them displayed error(s) (similar to 12.0-CURRENT) trying to run the command. These were LinuxMint 18.3, openSU= SE Leap 42.3, and CentOS EL 7.1708 systems. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-scsi@freebsd.org Wed Feb 21 21:25:09 2018 Return-Path: Delivered-To: freebsd-scsi@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 96165F01A3E for ; Wed, 21 Feb 2018 21:25:09 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (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 0BD79740E2 for ; Wed, 21 Feb 2018 21:25:08 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lf0-x236.google.com with SMTP id g72so4415744lfg.5 for ; Wed, 21 Feb 2018 13:25:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=ZKrEotSDqTTtlMQiHx3bKiJV1zMnj3o4Hnd71CgCrKg=; b=Um5zDifKfcNtK1g2gWNvVRH/YTxCFD9neYwHTeLh+FZRUlLr45vOCJy8zoA48O4wvF uSqk5xvVmK9Ah7mATk11Q5vZA1WIO5gJoVADaBs706olTNxCzb2G5D/8BcORBEwNq0sL Uq076XpYXp350UQwgVR4I47LJtsZTFdR89FsfqfM5y6CDc+vPEbiPEcrnwYBqDdbzvto gKXNx4XrZg7s0HgAkuiPDQKz31+EuxrKBswd+KjxtlHZZ+dqgJyhPH8FMH49nv13sQ17 aeeSEWMkRyBc1MQK/z7hWBEiesdULV3BluaiyYgIUgtUUfl8yr0PT9gte9e5iDSwQqXQ Cm4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=ZKrEotSDqTTtlMQiHx3bKiJV1zMnj3o4Hnd71CgCrKg=; b=e2ZkH+mIBWMn4ScnFviEpbw/0tZ4Pi10+uis4Gpyd85OAiMRi28Gj2sxGSznD5iGiY mvjP8qmqfokDvvZqx2j0JaQ76vCzIeTPl7rnbvYw2q0lnwuSBFLX7My/vziJpCgnXrDi wAuHVzwqH36PxcNvgKWP7DlJyDsiX4OsVv4U0PSTMAcn7/cgd2/TJ2DFXYUw6Ths3u2d BWiKNGZYRXAkg/ivnvjXMD6Ag39YHXZtCB7I/qPMvroLBR92W6fnSDipTft/fcM6OC1J PTUkrM7W5ynDpgVlKWJy9sCu+AbgXNIibAvKGLHCRe/FDW3nfJX08VpG0NKnaV2HDTTd yy0w== X-Gm-Message-State: APf1xPDja2OyJ+rj0v6IeVf39jvkbzFSNoEg8P5mpfy/Qoi4LJ/QTAVX JVK0OrG/cWyg/z3ucaKYntrz28U2XSg+JDspAQkp5w== X-Google-Smtp-Source: AH8x224Bfh8P7hFHKIaMkuxiT+Mj3EBBkoh3/FgYPMe5GJ4/CIAEs+j91boZexqE8GsCTzw3+gpZL3npZ1U2nPcevTk= X-Received: by 10.46.9.150 with SMTP id 144mr1463483ljj.117.1519248307024; Wed, 21 Feb 2018 13:25:07 -0800 (PST) MIME-Version: 1.0 Sender: asomers@gmail.com Received: by 10.179.30.66 with HTTP; Wed, 21 Feb 2018 13:25:06 -0800 (PST) From: Alan Somers Date: Wed, 21 Feb 2018 14:25:06 -0700 X-Google-Sender-Auth: kEA-SwNPNCsAgwhJAb96OJvb70w Message-ID: Subject: RFT: Coverity fixes to mptutil To: FreeBSD-scsi Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 21:25:09 -0000 Are there any mptutil(8) users out there who wouldn't mind testing a change for me? I cleaned up a bunch of Coverity errors in this program, but I don't have the hardware to test it with. If you're interested, just leave your comments at https://reviews.freebsd.org/D11013 . -Alan From owner-freebsd-scsi@freebsd.org Thu Feb 22 19:59:36 2018 Return-Path: Delivered-To: freebsd-scsi@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 2702DF26710 for ; Thu, 22 Feb 2018 19:59:36 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B6F0F7685A for ; Thu, 22 Feb 2018 19:59:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id F39811CAD6 for ; Thu, 22 Feb 2018 19:59:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w1MJxYEl040856 for ; Thu, 22 Feb 2018 19:59:34 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w1MJxYtB040855 for freebsd-scsi@FreeBSD.org; Thu, 22 Feb 2018 19:59:34 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-scsi@FreeBSD.org Subject: [Bug 225794] VM images for 12.0-CURRENT have problem with USB 3.0 ports Date: Thu, 22 Feb 2018 19:59:34 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: David.Boyd49@twc.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-scsi@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 19:59:36 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D225794 --- Comment #17 from David.Boyd49@twc.com --- Created attachment 190901 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D190901&action= =3Dedit Output of camcontrol modepage commands Andriy, I ran the camcontrol modepage commands as you requested. I didn't see any significant output. I will run the same commands on the VirtualBox guest where the NEC chipset = is used to see if there is any difference. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-scsi@freebsd.org Thu Feb 22 21:58:01 2018 Return-Path: Delivered-To: freebsd-scsi@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 1C1A1F04E17 for ; Thu, 22 Feb 2018 21:58:01 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A8CEC7B5F4 for ; Thu, 22 Feb 2018 21:58:00 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id EF5E41DB6B for ; Thu, 22 Feb 2018 21:57:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w1MLvxAa005783 for ; Thu, 22 Feb 2018 21:57:59 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w1MLvx7D005782 for freebsd-scsi@FreeBSD.org; Thu, 22 Feb 2018 21:57:59 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-scsi@FreeBSD.org Subject: [Bug 225794] VM images for 12.0-CURRENT have problem with USB 3.0 ports Date: Thu, 22 Feb 2018 21:57:59 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: David.Boyd49@twc.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-scsi@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Feb 2018 21:58:01 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D225794 --- Comment #18 from David.Boyd49@twc.com --- Created attachment 190908 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D190908&action= =3Dedit Output of camcontrol modepage commands on system with NEC chipset Same USB drive Same FreeBSD 12.0-CURRENT version Different USB chipset (NEC D720201) --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-scsi@freebsd.org Fri Feb 23 15:20:53 2018 Return-Path: Delivered-To: freebsd-scsi@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 A15EEF2A34B; Fri, 23 Feb 2018 15:20:53 +0000 (UTC) (envelope-from ben.rubson@gmail.com) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 1957F85DA4; Fri, 23 Feb 2018 15:20:53 +0000 (UTC) (envelope-from ben.rubson@gmail.com) Received: by mail-wm0-x229.google.com with SMTP id t74so5336777wme.3; Fri, 23 Feb 2018 07:20:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=38E0i+Thnu+pxeDJeO5fnR8pzHlJYtmADgWAsX1vfKU=; b=M/KJiVBTtVVeNr7fg59Of43xVfBeJkjHWBLEspkHseMDK/qJHcz8RpAobx2czxZTmV 0o3LCi53PQgt/AnkyX7BKdR0iWg3ZLRgRg9yXaOW+7xyDHxMX3+QdWRcZd/SjTwKlskS mh6nnYWUnVzUoP72L6wLDSJTXskZKFeYyIGpS0owVOZoLaPaX+u7OjI91CcqEqG9wVLZ j0bvXcYQ+uN2KTGd9iuhszbaYT0a61qpULffEbhLeci4TOz5ezhOlf2ICAXp7kK97fUn po+mRQxVr3nZXxnojm7ReQXWFw9Hxmo6i6DYru8wM5QnzZxrAQdvNBLXc5kWJf0XfPZE JtPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=38E0i+Thnu+pxeDJeO5fnR8pzHlJYtmADgWAsX1vfKU=; b=O3x+uOmIbqUXe+vAksAxo1DEaVjY8ehGC9Y/dceccK3+SWmmw9ig6Z2iFTyxvl3U7u 8eyo8YPY8kvNoWTvPu31t0Fa4Zd8vGQQx0v3k0fQh+rioTsUB0Wbcv4N0nXbjCKGRb7S QGZ5K63wEoKECOkQXIMGhQQmAwWRiMFxOVjH0NuC+m7F4Q8PHqpUuQZaf7DxgH1K/DsG x/fRFNofq9vLB+Mr0H6bzeEFrIOjnVvSVMbMbj1Qxt65eeq3IgUePhowlZQ1rq3woLRl u0Tq2ezunaH5zq5bstcG4P/DV325cBifmNGhbKSXvuyLbIQnhmMi7U+8RjmHfLheI6Fs ZmrA== X-Gm-Message-State: APf1xPBntemRkWnqbn4Dt3R4A35ex88DS+OvrriUVYRfAoZnWkwCrv73 qC04lZ8d28X/nbe7cf9B5MzuC+L2 X-Google-Smtp-Source: AH8x225N71NhwjSGt0hBrA84cAgSsvRauS+dwM0WNRggV717A76/4hX3jza//2ro6H3jiHBUa9JI+Q== X-Received: by 10.28.165.12 with SMTP id o12mr1962841wme.120.1519399251741; Fri, 23 Feb 2018 07:20:51 -0800 (PST) Received: from bens-mac.home (LFbn-NIC-1-211-113.w2-15.abo.wanadoo.fr. [2.15.58.113]) by smtp.gmail.com with ESMTPSA id i12sm1736826wmc.35.2018.02.23.07.20.49 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 23 Feb 2018 07:20:50 -0800 (PST) From: Ben RUBSON Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Subject: smartmontools and kern.securelevel Message-Id: <0985ABD3-D141-4EE2-B1B3-3016B16E2B68@gmail.com> Date: Fri, 23 Feb 2018 16:20:48 +0100 To: Freebsd fs , FreeBSD-scsi Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 15:20:53 -0000 Hi, I run smartmontools on my storage servers, to launch periodic disk tests and alert on disk errors. Unfortunately, if we set sysctl kern.securelevel >=2, smartmontools does not work anymore. Certainly because it needs to write directly to raw devices. (details of the levels, -1 to 3, in security(7)) Any workaround to this ? Perhaps we could think about allowing SMART commands to be written to disks when sysctl kern.securelevel >=2 ? (I assume smartmontools writes SMART commands) Thank you very much ! Ben From owner-freebsd-scsi@freebsd.org Fri Feb 23 15:25:13 2018 Return-Path: Delivered-To: freebsd-scsi@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 276E8F2A995 for ; Fri, 23 Feb 2018 15:25:13 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (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 A91458630F for ; Fri, 23 Feb 2018 15:25:12 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x235.google.com with SMTP id o13so3399256ito.2 for ; Fri, 23 Feb 2018 07:25:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=57x6gk5u3UJ1rAgtdN2Vp5Im4GVC/PyG0iIEqWSIhME=; b=g92o57cw67c9Nq7R6nQX7mqJekafXFPobpGQTgQIwKtvEEqwrrLE7CVITwdEKn2/Db MF/GsAVL6ammm3dqzlrHUxXV2nIQYVaoTurXugLzU4sGBwP+qZOE/altEapLn2tsOlJF rKScnP2GpE8A2AtspnnSRMx+igTrhSHPyKksqdlw+/WcMguCGCb4xoNAeTqsATC5ZBLN +VVWEMqJMsNF/SlY8ctcaPnWh7NCzLaYLsQvZBjX109yFB6SEGbeXnW8okk5CkUh0NL1 pFttSI5kuow+UEF9cjP08YKK5sx9j9nm4TQX6QiEBH/ZA40b8k2xD94YesCLn5j5ooQH RRrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=57x6gk5u3UJ1rAgtdN2Vp5Im4GVC/PyG0iIEqWSIhME=; b=ZBQNWvI7GQ5Wa0dVf/UXLmWCPOh9EukJvwRQqHgrEWifGHKDJqCcEV+I3JM9GlLcF1 fdDhnDTvlU4O378fwf9KpDV7C95X3kHhNKIUnF1B2ENtX8jf+aYriv/3ENMHHhcHCcDr RghBppM5NFCRbakT1Ex3xejWoQG63hKPMpKuxT/7M14ZagYuzvxgP/K9/F73kme81K+O DmDQOmgjQmwG3Gh5GtzeUhp3K6nBJXajMZzl7NJQfmdZvz3s5tm22Kvr8Ix7DzckdoNf CCP9GQ6tk5FuVsqG3u7ljgkr7gv7PjHTS/wY1CgDaj45TzEZt2MiORKrO/KotnRPgvLJ LNdg== X-Gm-Message-State: APf1xPDjdabI+m1Xay5Fhpw2oNVHdE7wFLmZROVUdgs4zHiQoifnAg1J scPxU0nfVnaAMQSCGZy0BCZMJyFEtIHEOncyon8vug== X-Google-Smtp-Source: AH8x224LogmwLaimTZETHkR7C7qHo3MzbShtZHG5mh4djC6VyhhXEJoc328mXVnASQzhoK/SuBlR2oskfpAQl2tk+gc= X-Received: by 10.36.222.2 with SMTP id d2mr2655954itg.1.1519399511955; Fri, 23 Feb 2018 07:25:11 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.201.67 with HTTP; Fri, 23 Feb 2018 07:25:11 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <0985ABD3-D141-4EE2-B1B3-3016B16E2B68@gmail.com> References: <0985ABD3-D141-4EE2-B1B3-3016B16E2B68@gmail.com> From: Warner Losh Date: Fri, 23 Feb 2018 08:25:11 -0700 X-Google-Sender-Auth: y7xCWKcfNa74SB8xfO3E5Xk-11c Message-ID: Subject: Re: smartmontools and kern.securelevel To: Ben RUBSON Cc: Freebsd fs , FreeBSD-scsi Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 15:25:13 -0000 On Fri, Feb 23, 2018 at 8:20 AM, Ben RUBSON wrote: > Hi, > > I run smartmontools on my storage servers, to launch periodic disk tests > and alert on disk errors. > > Unfortunately, if we set sysctl kern.securelevel >=2, smartmontools does > not work anymore. > Certainly because it needs to write directly to raw devices. > (details of the levels, -1 to 3, in security(7)) > > Any workaround to this ? > > Perhaps we could think about allowing SMART commands to be written to > disks when sysctl kern.securelevel >=2 ? > (I assume smartmontools writes SMART commands) > Sending raw disks commands is inherently insecure. It's hard to create a list of those commands that are OK because of the complexity and diversity of the needed functionality. That complexity also makes it hard to put the commands into a series of ioctls which could be made more secure. Warner From owner-freebsd-scsi@freebsd.org Fri Feb 23 16:46:14 2018 Return-Path: Delivered-To: freebsd-scsi@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 A0D39F0598D; Fri, 23 Feb 2018 16:46:14 +0000 (UTC) (envelope-from ben.rubson@gmail.com) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 1604669DBA; Fri, 23 Feb 2018 16:46:14 +0000 (UTC) (envelope-from ben.rubson@gmail.com) Received: by mail-wm0-x22d.google.com with SMTP id h21so5814689wmd.1; Fri, 23 Feb 2018 08:46:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VYsHmDeeBM3VdypSFP31nKWDbMHt3av+c81AqXAbiVI=; b=tUuZFT9HIwZDC5qdlMW5OYYFaOL1vTCh/J5Lb8WlD7FSHrkn4MY3Vv4aaPICD+ma2A aefUIfGmV1B+iwryAB9U4ukO/LCfZasfZeSzRIx9ZX0PT6IcuwgB0hkwHvJaHLg55eKh 1Ugf9+CCXdsiltF91GCPdsXU4N0N6+V6Gn0sVmzhDLrDqGLSfdM+raNCoISkuajZmpL+ ptH//AqkKbjZS2r9PTeF+VRrLKh5m8csT8GNxkz1aaso7eany1J1xEKPnd+fKzVASBye 6Xr/A7pHt7nAV+raZqp4Fsu67R5avKLFi/xqKpdSaYhV7/K+va/Z8tuh1QBrBiZkZlw5 k2iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VYsHmDeeBM3VdypSFP31nKWDbMHt3av+c81AqXAbiVI=; b=jc9u62EeA9x6eHXMtqJA4j2VDhktO6DQtlSXssCo5bIfiw9DbQEQ/OvUhXiv3UP1qy 8Vy9bAqbJ5+dXWJZ1oF+eSScu/KpSSsx6v2FifC2t2t96Td+KknkCYzzEqAlzynKgD9M VX3+THGb0zz6+jmspJaHDu53gus7e7ZJzscb8drJpcmcpuMYIoDg0D+A3pn0X+Kw0XNW WLv5oC1CqZsDfWTI309K6j+g0TD/4npZj10SeMAOPiH+VpDcykXExjqWCrkP8i5kLNuT zrUtyPcJLoafzD/vW1nT04XF4bX/P17Cuf16FYK2eIvfA19DV5TL7zvVEWOG4CxVX+Wd zgCQ== X-Gm-Message-State: APf1xPCOd0gkFc3uLfMBqobLd85sv0ih/nSl4xP5gcWmLqxoEE2HhMMk o/mSM8Tritrh/eqxW2d7GdJnSn73 X-Google-Smtp-Source: AG47ELtyGnQVabfVyZ6/X9/J+6rx6fZMnOL66BhXJcQoTXb/LPPe7d49biPYLB1oQaJqRFVfsuyQ/g== X-Received: by 10.28.32.202 with SMTP id g193mr2008832wmg.99.1519404373091; Fri, 23 Feb 2018 08:46:13 -0800 (PST) Received: from bens-mac.home (LFbn-NIC-1-211-113.w2-15.abo.wanadoo.fr. [2.15.58.113]) by smtp.gmail.com with ESMTPSA id x189sm3114900wmg.23.2018.02.23.08.46.11 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 23 Feb 2018 08:46:12 -0800 (PST) Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: smartmontools and kern.securelevel From: Ben RUBSON In-Reply-To: Date: Fri, 23 Feb 2018 17:46:10 +0100 Cc: Freebsd fs , FreeBSD-scsi Content-Transfer-Encoding: 7bit Message-Id: <4C1D44AF-8247-4601-A39C-A8C0A5C8CBD8@gmail.com> References: <0985ABD3-D141-4EE2-B1B3-3016B16E2B68@gmail.com> To: Warner Losh X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 16:46:14 -0000 On 23 Feb 2018, Warner Losh wrote: > On Fri, Feb 23, 2018 at 8:20 AM, Ben RUBSON wrote: > >> Hi, >> >> I run smartmontools on my storage servers, to launch periodic disk tests >> and alert on disk errors. >> >> Unfortunately, if we set sysctl kern.securelevel >=2, smartmontools does >> not work anymore. >> Certainly because it needs to write directly to raw devices. >> (details of the levels, -1 to 3, in security(7)) >> >> Any workaround to this ? >> >> Perhaps we could think about allowing SMART commands to be written to >> disks when sysctl kern.securelevel >=2 ? >> (I assume smartmontools writes SMART commands) > > Sending raw disks commands is inherently insecure. It's hard to create a > list of those commands that are OK because of the complexity and > diversity of the needed functionality. That complexity also makes it hard > to put the commands into a series of ioctls which could be made more > secure. Thank you for your feedback Warner. Can't all SMART commands be easily identified among the others ? (when a command arrives, does kernel sees it is SMART flagged ?) Perhaps you assume some SMART commands may be dangerous for the disks' data itself ? Thank you again, Ben From owner-freebsd-scsi@freebsd.org Fri Feb 23 17:16:30 2018 Return-Path: Delivered-To: freebsd-scsi@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 64E26F07E6C for ; Fri, 23 Feb 2018 17:16:30 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (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 E67476B64E for ; Fri, 23 Feb 2018 17:16:29 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x234.google.com with SMTP id g21so10525919ioj.5 for ; Fri, 23 Feb 2018 09:16:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=rpdYpTY1jFo5DHO02OWKA4yGvynOXUqyHj6hH4g4zQA=; b=Ubn/0Q9cHimh3A4Xwy/xLkmSHuaQ/cB2IwPsL3UsT0UjIcpj5tCh8tv1B0VRdx3amp GP2i/PuyHQ/IeZb8lfXbFpdEMBvF0jYn1GBZxwdBce5TgTHulkg8cPVUh66xPzSi04c4 SN7MyBz5y1d9bJ/s9wPNLoWCGtH7JnaXzVb1RVmyt/pjpKTCu2OBe5D/r54ncLWnR1sf eYEGNGB23nNlvQVTSCoPt8f40f1qMcpjLCEGBBZtFC34Zgj/XVcxhgIevyJ1PGtW0tkb 0vSgT2zEVTSRkAjY3MA2ZHtOS/Ikhq4NAYnfp9y8avytLsoWCYci0VPAeW+KXOt0fjKj 2XRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=rpdYpTY1jFo5DHO02OWKA4yGvynOXUqyHj6hH4g4zQA=; b=czDVOkCPRMWMK4z5If9mtZCN0ER2eMfV04LbPefOMlYqSLZyCFu4niC8CX/Y6H84fU P0NUgsw0y+rTsPtA6LavzzQESwqqJWAzg9HYn6nuYeQI49TmRpcoErMKKinHGHjiP0xM qlGndOF/hNYrS/Tz6yDeZ/A1mXm8Fd3plVvnVinYHTgogFHksL2DCRG8wgaMKUq5CWGq dnDQK8stIgLM4IrDxISsy3IaqCPCJd89CA/U/PGMnozO3wDm1Zd2j4NbJeuwmthSYoo1 hX9VuK3Bfmx7fm9j1ZuEx6Ja6bJxIHR+n4RBRLZwtW/D87YXL2yegSJRL+vt93wpTx+8 He/A== X-Gm-Message-State: APf1xPBTAiKzD+VfuzMaKT1ZqSqLBi7efvzLCw69+6OMZk+h30gaYyGW j694Tv89LrVgPoTnm6GmLgNP7eP3i7RHIk/VAGa+EQ== X-Google-Smtp-Source: AG47ELsw0lk8CapVXrasDwUkuR9DjeCOKbXqPlIesvX6sCs0qmXfAIEncwNFn5gu4UQrLwi1QgCrimpSwCNonbaK3B8= X-Received: by 10.107.175.77 with SMTP id y74mr2626545ioe.37.1519406189071; Fri, 23 Feb 2018 09:16:29 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.201.67 with HTTP; Fri, 23 Feb 2018 09:16:28 -0800 (PST) X-Originating-IP: [50.253.99.174] In-Reply-To: <4C1D44AF-8247-4601-A39C-A8C0A5C8CBD8@gmail.com> References: <0985ABD3-D141-4EE2-B1B3-3016B16E2B68@gmail.com> <4C1D44AF-8247-4601-A39C-A8C0A5C8CBD8@gmail.com> From: Warner Losh Date: Fri, 23 Feb 2018 10:16:28 -0700 X-Google-Sender-Auth: pQc0FQdRfjBgXJ-PalkIU7AsvgI Message-ID: Subject: Re: smartmontools and kern.securelevel To: Ben RUBSON Cc: Freebsd fs , FreeBSD-scsi Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 17:16:30 -0000 On Fri, Feb 23, 2018 at 9:46 AM, Ben RUBSON wrote: > On 23 Feb 2018, Warner Losh wrote: > > On Fri, Feb 23, 2018 at 8:20 AM, Ben RUBSON wrote: >> >> Hi, >>> >>> I run smartmontools on my storage servers, to launch periodic disk tests >>> and alert on disk errors. >>> >>> Unfortunately, if we set sysctl kern.securelevel >=2, smartmontools does >>> not work anymore. >>> Certainly because it needs to write directly to raw devices. >>> (details of the levels, -1 to 3, in security(7)) >>> >>> Any workaround to this ? >>> >>> Perhaps we could think about allowing SMART commands to be written to >>> disks when sysctl kern.securelevel >=2 ? >>> (I assume smartmontools writes SMART commands) >>> >> >> Sending raw disks commands is inherently insecure. It's hard to create a >> list of those commands that are OK because of the complexity and diversity >> of the needed functionality. That complexity also makes it hard to put the >> commands into a series of ioctls which could be made more secure. >> > > Thank you for your feedback Warner. > > Can't all SMART commands be easily identified among the others ? (when a > command arrives, does kernel sees it is SMART flagged ?) > Perhaps you assume some SMART commands may be dangerous for the disks' > data itself ? > Yes. I do. They can be. Warner From owner-freebsd-scsi@freebsd.org Fri Feb 23 17:20:17 2018 Return-Path: Delivered-To: freebsd-scsi@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 68E3FF0955B; Fri, 23 Feb 2018 17:20:17 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0FB356BB10; Fri, 23 Feb 2018 17:20:16 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 41D0120DEF; Fri, 23 Feb 2018 12:20:16 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Fri, 23 Feb 2018 12:20:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsco.org; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=aa7E32sIwFgGFeLpavYUxwt2Crwtk qZbaz2H6Byp6PU=; b=j3f4gwivZqZ0H+3z8LkCKUpJEegYJ4e225EVCeHUPLxjg 92Q9xCCU1c0b6frcBop6OEF+J4JuVvnAgJ0656UoJSrivbJe9NCQRyQ+toozvHK5 4FyozhZKMASLDPz+mkw1rSB/si5tEeKH7WF74k2qZAlz7R+XcIAuV7QetM62BKbB 5GLhpNZ0g9Cqm1TB4as3EnB3KXoplhoaTtPA0SnYpF4OMpDcEoo0Eq/IxpcUQ199 1Z05W9eLLtyNVkcVY/vMSXh7gaGrLdcWKc81SiwqVWXrcX7d7Ka9gCUDEQbg3tY2 KvEF5Nsz16uonbF5ZMmFmBdygnjzrI3Ogp+bXmj3A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=aa7E32 sIwFgGFeLpavYUxwt2CrwtkqZbaz2H6Byp6PU=; b=cilkwhIlfhQ8iyuxaU8BRW QpKE9kFRoxlFWw/r7TS2zjXCnqXTW+rvtRuhZ6m9nK8xidANywjWkaQJLsPdm/5m 0qO7eWIvBf/60KlEcLoOvXfDdjK+zWniuHmDoTKChCOr1PhAjZ0IGF7/+U05jOJV l8BmIQQYILV/NivIRMqXaWeR01hn9xtX8tpE1WCFarA7yco2qNaQdstaFRld3QmC v9kHq1039AB3BOkwCIVtBmvob16gZbR9Eq7obfEZhmsRiOOVwWxgLPmeRhQ8xb4G 5NpSpbsWGNVI+TrUPJUgPhIcyU2Z5o60j7AeBazvl3+jaj7yQxwvi2OUxUbmqRCQ == X-ME-Sender: Received: from [192.168.0.116] (unknown [161.97.249.191]) by mail.messagingengine.com (Postfix) with ESMTPA id AC3C7240B6; Fri, 23 Feb 2018 12:20:15 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Subject: Re: smartmontools and kern.securelevel From: Scott Long In-Reply-To: <4C1D44AF-8247-4601-A39C-A8C0A5C8CBD8@gmail.com> Date: Fri, 23 Feb 2018 10:20:12 -0700 Cc: Warner Losh , Freebsd fs , FreeBSD-scsi Content-Transfer-Encoding: quoted-printable Message-Id: References: <0985ABD3-D141-4EE2-B1B3-3016B16E2B68@gmail.com> <4C1D44AF-8247-4601-A39C-A8C0A5C8CBD8@gmail.com> To: Ben RUBSON X-Mailer: Apple Mail (2.3445.4.7) X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 17:20:17 -0000 > On Feb 23, 2018, at 9:46 AM, Ben RUBSON wrote: >=20 > On 23 Feb 2018, Warner Losh wrote: >=20 >> On Fri, Feb 23, 2018 at 8:20 AM, Ben RUBSON = wrote: >>=20 >>> Hi, >>>=20 >>> I run smartmontools on my storage servers, to launch periodic disk = tests and alert on disk errors. >>>=20 >>> Unfortunately, if we set sysctl kern.securelevel >=3D2, = smartmontools does not work anymore. >>> Certainly because it needs to write directly to raw devices. >>> (details of the levels, -1 to 3, in security(7)) >>>=20 >>> Any workaround to this ? >>>=20 >>> Perhaps we could think about allowing SMART commands to be written = to disks when sysctl kern.securelevel >=3D2 ? >>> (I assume smartmontools writes SMART commands) >>=20 >> Sending raw disks commands is inherently insecure. It's hard to = create a list of those commands that are OK because of the complexity = and diversity of the needed functionality. That complexity also makes it = hard to put the commands into a series of ioctls which could be made = more secure. >=20 > Thank you for your feedback Warner. >=20 > Can't all SMART commands be easily identified among the others ? (when = a command arrives, does kernel sees it is SMART flagged ?) > Perhaps you assume some SMART commands may be dangerous for the disks' = data itself ? >=20 > Thank you again, >=20 Sure, there are a finite number of SMART commands, even when you = consider variations for SAS and SATL. The commands aren=E2=80=99t = explicitly flagged to the kernel, but they can be parsed. You could = even move the SMART logic directly into the kernel. However, issuing = the commands is often disruptive to the system; for SATA, it=E2=80=99s a = non-queueing command, so the system has to drain and serialize I/O while = it=E2=80=99s active. This can be crudely used as a DOS attack. There = are also SMART commands to do long-running diagnostics, that while = they=E2=80=99re not destructive, they can still be disruptive. Also, = SMART statistics can be used to gain insight into the operation of the = system, making it easier to predict I/O patterns and employ other = side-channel attacks. The point of securelevel=3D2 is to prevent access = to disk devices that can result in system disruption, so I=E2=80=99m = adverse to making an exception that=E2=80=99s directly counter to that = point. Scott From owner-freebsd-scsi@freebsd.org Fri Feb 23 17:49:25 2018 Return-Path: Delivered-To: freebsd-scsi@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 9E81DF0BD1B for ; Fri, 23 Feb 2018 17:49:25 +0000 (UTC) (envelope-from dgilbert@interlog.com) Received: from smtp.infotech.no (smtp.infotech.no [82.134.31.41]) by mx1.freebsd.org (Postfix) with ESMTP id 0D6F16CDF8 for ; Fri, 23 Feb 2018 17:49:24 +0000 (UTC) (envelope-from dgilbert@interlog.com) Received: from localhost (localhost [127.0.0.1]) by smtp.infotech.no (Postfix) with ESMTP id 00FDD2041BB for ; Fri, 23 Feb 2018 18:49:18 +0100 (CET) X-Virus-Scanned: by amavisd-new-2.6.6 (20110518) (Debian) at infotech.no Received: from smtp.infotech.no ([127.0.0.1]) by localhost (smtp.infotech.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rv1XlxEDivu5 for ; Fri, 23 Feb 2018 18:49:17 +0100 (CET) Received: from [10.7.0.10] (unknown [10.7.0.10]) by smtp.infotech.no (Postfix) with ESMTPA id 835A02040A6 for ; Fri, 23 Feb 2018 18:49:17 +0100 (CET) Reply-To: dgilbert@interlog.com Subject: Re: smartmontools and kern.securelevel To: freebsd-scsi@freebsd.org References: <0985ABD3-D141-4EE2-B1B3-3016B16E2B68@gmail.com> <4C1D44AF-8247-4601-A39C-A8C0A5C8CBD8@gmail.com> From: Douglas Gilbert Message-ID: <93284cad-7a4f-10ec-4a5d-e8a820c0a5fd@interlog.com> Date: Fri, 23 Feb 2018 12:49:16 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-CA Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 17:49:25 -0000 On 2018-02-23 12:16 PM, Warner Losh wrote: > On Fri, Feb 23, 2018 at 9:46 AM, Ben RUBSON wrote: > >> On 23 Feb 2018, Warner Losh wrote: >> >> On Fri, Feb 23, 2018 at 8:20 AM, Ben RUBSON wrote: >>> >>> Hi, >>>> >>>> I run smartmontools on my storage servers, to launch periodic disk tests >>>> and alert on disk errors. >>>> >>>> Unfortunately, if we set sysctl kern.securelevel >=2, smartmontools does >>>> not work anymore. >>>> Certainly because it needs to write directly to raw devices. >>>> (details of the levels, -1 to 3, in security(7)) >>>> >>>> Any workaround to this ? >>>> >>>> Perhaps we could think about allowing SMART commands to be written to >>>> disks when sysctl kern.securelevel >=2 ? >>>> (I assume smartmontools writes SMART commands) >>>> >>> >>> Sending raw disks commands is inherently insecure. It's hard to create a >>> list of those commands that are OK because of the complexity and diversity >>> of the needed functionality. That complexity also makes it hard to put the >>> commands into a series of ioctls which could be made more secure. >>> >> >> Thank you for your feedback Warner. >> >> Can't all SMART commands be easily identified among the others ? (when a >> command arrives, does kernel sees it is SMART flagged ?) >> Perhaps you assume some SMART commands may be dangerous for the disks' >> data itself ? >> > > Yes. I do. They can be. > > Warner A partial solution with big storage behind a storage switch (FC, PCIe or SAS) is to run one machine *** (preferably not accessible directly from the internet) at a lower privilege level that permits it to run smartmontools and other similar utilities (such as a management utility for that storage switch). Then all other machines, especially those that provided services to (or accessible from) the internet, can run at a higher privilege level precluding smartmontools. You might want to add wireless access (e.g. WiFi and/or Bluetooth) to the "internet" as a possible attack vector. If someone told me that I was at the keyboard of an extremely safe Linux system and I had a login, then I would check if it was running my drivers: sg and scsi_debug (a SCSI command pass-through and a pseudo SCSI low level device driver). If it was then I would suggest that machine wasn't safe enough ... Basically there is no way an OS can foresee what tricks you can get up to with a pass-through. Consider a "third party copy" (SCSI EXTENDED COPY command). That can be sent to a "copy manager" which is neither the source nor destination of that copy. Security that concentrates on the copy manager is flawed. Microsoft ban this command with their Windows pass-thru. If I was a vendor with a customer wanting the offloaded copy capability and ran a Microsoft OS, then I would just replicate the functionality of EXTENDED COPY in a vendor specific command! That wouldn't be much code. Problem solved, happy customer. Doug Gilbert *** And make that a _real_ machine, not a VM :-) With a real console. From owner-freebsd-scsi@freebsd.org Fri Feb 23 21:37:18 2018 Return-Path: Delivered-To: freebsd-scsi@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 62D3DF224A5; Fri, 23 Feb 2018 21:37:18 +0000 (UTC) (envelope-from ben.rubson@gmail.com) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (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 D1B837A284; Fri, 23 Feb 2018 21:37:17 +0000 (UTC) (envelope-from ben.rubson@gmail.com) Received: by mail-wm0-x231.google.com with SMTP id 191so6985059wmm.4; Fri, 23 Feb 2018 13:37:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=cnWj3Q4nHiIKkKAJ7SJU1rpC6L2eEmD5cnWANpg44MI=; b=HXPrXKslYF3N0dcR9usaeihl5st6ieTX8peq6fDUzZF1+Gb1dPYENSXBKHOiedgtjm 55dJmxOHIV5IvyPm4gnJj2EjBMllQ5q8UN67EFneUKetvBRLMPt3HTaiFxkfMTPVKLs8 RRreiV7UtXjZFxFmBlNMqIrFPtUze5L/xNfbLHKn2+YJsTfS8AqSZfgV+qqyAlZL6cLO dnzWJAY4yFnVZhlFDEO9KWSK1ue5yYwAn+lgR2z40Dk6+8yOLMIVKwI6T9TF3kAW7EFQ ixdZIwICUkqSLkjITRNG9QWhipxVU47iAg5ilMG1DMW4dA7vXpo4+9zuVhX0XAZm7D6i wvQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=cnWj3Q4nHiIKkKAJ7SJU1rpC6L2eEmD5cnWANpg44MI=; b=ui+uohcYsBX3XVaE+aKafDP1s+yViiiOKspgAog1TlTOcCllH5+a+fcD75gEnzwDpN a1e2kXh7QvxjgFDIa9Tzj/7NX+pkk7JMBuwjY5qyF7A3xwWYOS4zdvjI+rm1+FPrkE4f R4E6m3r1l5/akU/XuZR0ut47rzygkzeX7gLgcNVjC/k7EWpSLCEa0Ac8hSdpm3qJnbGm fCRp82ahSgrJBJs1GveEtL7faDDvWr4rwSGVbs9U2slVMG5C173mrCAK9lM2ET9d8EP4 N+EqzfXfjT55sbcnN4wGybQ4G4vR4Kc3pu3jOWVlZoSFFTODjTdxWuZrRh5WQJlKBsXC vlQA== X-Gm-Message-State: APf1xPBQxMJ5ksQ0jTYxm8Ii8q9w67T5E4fWPDHHXSvvA3usq7me7uqT IrNWMKlxiKpJVDxGmy39LrlBo7ph X-Google-Smtp-Source: AG47ELtW6FXGKeNvDimoz9uN2CiMRTQmQmb2wEzioG8l9ifxabaSPC41GXsBK5U0U0oMOYpHIayLzg== X-Received: by 10.28.144.193 with SMTP id s184mr2955670wmd.68.1519421836499; Fri, 23 Feb 2018 13:37:16 -0800 (PST) Received: from bens-mac-1.home (LFbn-NIC-1-211-113.w2-15.abo.wanadoo.fr. [2.15.58.113]) by smtp.gmail.com with ESMTPSA id u22sm3735011wrf.86.2018.02.23.13.37.14 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 23 Feb 2018 13:37:15 -0800 (PST) Content-Type: text/plain; charset=utf-8; delsp=yes; format=flowed Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: smartmontools and kern.securelevel From: Ben RUBSON In-Reply-To: Date: Fri, 23 Feb 2018 22:37:19 +0100 Content-Transfer-Encoding: 8bit Message-Id: References: <0985ABD3-D141-4EE2-B1B3-3016B16E2B68@gmail.com> <4C1D44AF-8247-4601-A39C-A8C0A5C8CBD8@gmail.com> To: Freebsd fs , FreeBSD-scsi X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Feb 2018 21:37:18 -0000 >> On Feb 23, 2018, at 9:46 AM, Ben RUBSON wrote: >> >> On 23 Feb 2018, Warner Losh wrote: >> >>> On Fri, Feb 23, 2018 at 8:20 AM, Ben RUBSON wrote: >>> >>>> Hi, >>>> >>>> I run smartmontools on my storage servers, to launch periodic disk >>>> tests and alert on disk errors. >>>> >>>> Unfortunately, if we set sysctl kern.securelevel >=2, smartmontools >>>> does not work anymore. >>>> Certainly because it needs to write directly to raw devices. >>>> (details of the levels, -1 to 3, in security(7)) >>>> >>>> Any workaround to this ? >>>> >>>> Perhaps we could think about allowing SMART commands to be written to >>>> disks when sysctl kern.securelevel >=2 ? >>>> (I assume smartmontools writes SMART commands) >>> >>> Sending raw disks commands is inherently insecure. It's hard to create >>> a list of those commands that are OK because of the complexity and >>> diversity of the needed functionality. That complexity also makes it >>> hard to put the commands into a series of ioctls which could be made >>> more secure. >> >> Thank you for your feedback Warner. >> >> Can't all SMART commands be easily identified among the others ? (when a >> command arrives, does kernel sees it is SMART flagged ?) >> Perhaps you assume some SMART commands may be dangerous for the disks' >> data itself ? >> >> Thank you again, > On 23 Feb 2018, Scott Long wrote: > Sure, there are a finite number of SMART commands, even when you consider > variations for SAS and SATL. The commands aren’t explicitly flagged to > the kernel, but they can be parsed. You could even move the SMART logic > directly into the kernel. However, issuing the commands is often > disruptive to the system; for SATA, it’s a non-queueing command, so the > system has to drain and serialize I/O while it’s active. This can be > crudely used as a DOS attack. There are also SMART commands to do > long-running diagnostics, that while they’re not destructive, they can > still be disruptive. Also, SMART statistics can be used to gain insight > into the operation of the system, making it easier to predict I/O > patterns and employ other side-channel attacks. The point of > securelevel=2 is to prevent access to disk devices that can result in > system disruption, so I’m adverse to making an exception that’s directly > counter to that point. Thank you Scott. securelevel=2 really makes sense, as (IMO) SMART error reports / statistics and diagnostics. Hard to combine both actually. Perhaps a solution could be the SMART logic into the kernel, with the ability to disable it (compilation option ?). On 23 Feb 2018, Douglas Gilbert wrote: > A partial solution with big storage behind a storage switch (FC, PCIe or > SAS) is to run one machine *** (preferably not accessible directly from the > internet) at a lower privilege level that permits it to run smartmontools > and other similar utilities (such as a management utility for that > storage switch). Thank you Douglas, yes you're right, SAS shared JBODs would do the trick. Mine are SAS, but unfortunately local / not shared. Theses disks are parts of ZFS pools. Instead of running zpool scrubs each 2 weeks and SMART long self tests the other 2 weeks, I could run weekly zpool scrubs. But I think I will loose the opportunity to be notified by smartmontools about a pre-dying disk, in addition sectors not yet used by ZFS would not be tested. Thank you again, Ben