From owner-svn-src-all@freebsd.org Wed Dec 11 17:19:08 2019 Return-Path: Delivered-To: svn-src-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EB6A31DB8B6; Wed, 11 Dec 2019 17:19:08 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (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 47Y3Z45zZpz4MQx; Wed, 11 Dec 2019 17:19:08 +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 A4DE321FFC; Wed, 11 Dec 2019 12:19:07 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Wed, 11 Dec 2019 12:19:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsco.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=4 JoQMowbmZwlniK/YMHFG9hsxQhTN5XQd1Hh//k9520=; b=ZX82ONZrTG2crS/wo rjPf+jB3/b0FCGAVdowP1lbLDXsaT0t49niTVb/ybAe/tb8tJI/3ow5e98LtxToD 29PUcUQwIJdG7a20sk0foaEkXgINy56AnruqO8z/cCZB4y2cCOp7ZGnu8Ukzo9fJ Fk+iEe5jvc3+62HPWZY7q9maVN8FRPQgZg5cZdGfualqMgVdX8h0XdFGflVwmfey xfGtdRlRri0FqS53er7zqtILaPVJLLQ/LeF/evMu3+d4JsHBKk7/jFuWRXJb1Z4K chRZ6FJFOdLCPGwvHck2mOLMbLS4tVqcbJ5fF5uid6KcAUrUIELWOLp4M5zsQAGt qseRA== 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-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=4JoQMowbmZwlniK/YMHFG9hsxQhTN5XQd1Hh//k95 20=; b=xGmppGTNGHjUFDS/mDnGjulVB4K0RJen3obLFLdPmlUCBKz3jYVuaWEXa S5FQdnFJBPF+shz87e0EaxK2UWohMvLPoM0L06riLwukjhh1lX4B3SUloeT/5VtB /cLSYWJhi3TVn1+x2KSutpZNXJjRT8vylHJQIVYUE+rxWo7QLQ8EIY11srpy1uwK 0hoZti2nQgpeZU3FS/CeNqHt4DYqFxcT5KuHusfETyNirYJMBYHNFRXSz3jS4GLd Aolkqvnj1L6RfhpLDVM2J0Obl0xIZvuPSLPlfJtFWWnp/TRTqj7any/qnSecjpa5 jRSu2Gr/SefyQzP+MyAPSIS497Mgg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudelhedgleegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtjeenucfhrhhomhepufgtohht thcunfhonhhguceoshgtohhtthhlsehsrghmshgtohdrohhrgheqnecuffhomhgrihhnpe hfrhgvvggsshgurdhorhhgnecukfhppeekrdegiedrkeelrddvudefnecurfgrrhgrmhep mhgrihhlfhhrohhmpehstghothhtlhesshgrmhhstghordhorhhgnecuvehluhhsthgvrh fuihiivgeptd X-ME-Proxy: Received: from [192.168.0.114] (unknown [8.46.89.213]) by mail.messagingengine.com (Postfix) with ESMTPA id A92FF3060132; Wed, 11 Dec 2019 12:19:06 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Subject: Re: svn commit: r355430 - head/sys/cam/scsi From: Scott Long In-Reply-To: Date: Wed, 11 Dec 2019 10:19:05 -0700 Cc: Steven Hartland , src-committers , svn-src-all , svn-src-head Content-Transfer-Encoding: quoted-printable Message-Id: <820BE55B-AE32-44E7-8AC7-245EF6F86F8B@samsco.org> References: <201912060006.xB6066qR058963@repo.freebsd.org> To: Alan Somers X-Mailer: Apple Mail (2.3601.0.10) X-Rspamd-Queue-Id: 47Y3Z45zZpz4MQx X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-5.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.997,0]; NEURAL_HAM_LONG(-1.00)[-0.996,0]; REPLY(-4.00)[] X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2019 17:19:09 -0000 U+FFFD doesn=E2=80=99t make sense for an ASCII string, but 0x3F might. = Any idea what Windows shows for this device? Scott > On Dec 11, 2019, at 8:42 AM, Alan Somers wrote: >=20 > In this case the offending descriptor is solid 0xFF, so replacing = individual characters wouldn't accomplish anything. I can imagine a = different buggy expander that has just one or two bad characters. In = that case, it would make sense to replace them. But replace them with = what? The UTF replacement character 0xFFFD isn't an option, because the = result is supposed to be ASCII. There's no other obvious choice, which = is why I chose to replace the whole thing. > -Alan >=20 > On Fri, Dec 6, 2019 at 2:40 AM Steven Hartland = wrote: > If the illegal chars where removed or replaced would the result be = useful, if so might that be a better approach? >=20 > On Fri, 6 Dec 2019 at 00:06, Alan Somers wrote: > Author: asomers > Date: Fri Dec 6 00:06:05 2019 > New Revision: 355430 > URL: https://svnweb.freebsd.org/changeset/base/355430 >=20 > Log: > ses: sanitize illegal strings in SES element descriptors >=20 > The SES4r3 standard requires that element descriptors may only = contain ASCII > characters in the range 0x20 to 0x7e. Some SuperMicro expanders = violate > that rule. This patch adds a sanity check to ses(4). Descriptors = in > violation will be replaced by "". >=20 > This patch fixes "sesutil --libxo xml" on such systems. Previously = it would > generate non-well-formed XML output. >=20 > PR: 241929 > Reviewed by: allanjude > MFC after: 2 weeks > Sponsored by: Axcient >=20 > Modified: > head/sys/cam/scsi/scsi_enc_ses.c >=20 > Modified: head/sys/cam/scsi/scsi_enc_ses.c > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > --- head/sys/cam/scsi/scsi_enc_ses.c Thu Dec 5 19:39:51 2019 = (r355429) > +++ head/sys/cam/scsi/scsi_enc_ses.c Fri Dec 6 00:06:05 2019 = (r355430) > @@ -110,7 +110,7 @@ typedef struct ses_addl_status { > typedef struct ses_element { > uint8_t eip; /* eip bit is set */ > uint16_t descr_len; /* length of the descriptor */ > - char *descr; /* descriptor for this object = */ > + const char *descr; /* descriptor for this object = */ > struct ses_addl_status addl; /* additional status info */ > } ses_element_t; >=20 > @@ -1977,6 +1977,35 @@ ses_publish_cache(enc_softc_t *enc, struct = enc_fsm_sta > return (0); > } >=20 > +/* > + * \brief Sanitize an element descriptor > + * > + * The SES4r3 standard, sections 3.1.2 and 6.1.10, specifies that = element > + * descriptors may only contain ASCII characters in the range 0x20 to = 0x7e. > + * But some vendors violate that rule. Ensure that we only expose = compliant > + * descriptors to userland. > + * > + * \param desc SES element descriptor as reported by the = hardware > + * \param len Length of desc in bytes, not necessarily = including > + * trailing NUL. It will be modified if desc is = invalid. > + */ > +static const char* > +ses_sanitize_elm_desc(const char *desc, uint16_t *len) > +{ > + const char *invalid =3D ""; > + int i; > + > + for (i =3D 0; i < *len; i++) { > + if (desc[i] < 0x20 || desc[i] > 0x7e) { > + *len =3D strlen(invalid); > + return (invalid); > + } else if (desc[i] =3D=3D 0) { > + break; > + } > + } > + return (desc); > +} > + > /** > * \brief Parse the descriptors for each object. > * > @@ -2061,7 +2090,8 @@ ses_process_elm_descs(enc_softc_t *enc, struct = enc_fsm > if (length > 0) { > elmpriv =3D element->elm_private; > elmpriv->descr_len =3D length; > - elmpriv->descr =3D &buf[offset]; > + elmpriv->descr =3D = ses_sanitize_elm_desc(&buf[offset], > + &elmpriv->descr_len); > } >=20 > /* skip over the descriptor itself */