From owner-svn-src-all@freebsd.org Wed Dec 11 17:35:51 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 E601D1DBECE; Wed, 11 Dec 2019 17:35:51 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oi1-f194.google.com (mail-oi1-f194.google.com [209.85.167.194]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47Y3xL62xyz4Ngm; Wed, 11 Dec 2019 17:35:50 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oi1-f194.google.com with SMTP id 6so13976377oix.7; Wed, 11 Dec 2019 09:35:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1gvdYU+4UxOcSQlkjZtzAOE5OTxpo67Lju8j82HSDhA=; b=dZOmB62pn9qGK9svDmb9N4k4zLaFfIaTiveztb2ElNf2In1TI1tOAd6MchtbnRldYH mZOFVwV9tB9I+1sKQHB+qJinD/7ybQFusDcPKSMa8gOr3gyygBR5jF8s7ie33BZQLDS8 GH0tYAqDHubSj93kJxxfgbWOlJ9ntuYGh45kMPooYMzVcsGUeiz5aWjfdaxxs/h/2Dek 9DYkEtk5w+8Ej+eytY0UYp6gX+YSZhX1PiuVYA4qg4EAMphOoHjnosGv7DC59+WOoITa Fu0p9/1+Jar7dqfBOseO5XPdoXDK49WbRNO26igprMEG0U/utE4uc1R9HlSSLEtqw9Pp bn9g== X-Gm-Message-State: APjAAAV21hecaMKvPoDmrPV6aIxmFniA1tCiY1CiS9xwaRvRSfmuqKs/ DsU5lG9qcbDzGMa0ZMSVRumwWKAkGEKikTA4wGUG9Q== X-Google-Smtp-Source: APXvYqwl/cisMYrxNFD5eO7+I7W4AKylyp7qg+wz+lMH6l4pZUWNMs6d63ZqHxIXS/VtVlpJjpxGmwC45o8B0xgkCGw= X-Received: by 2002:a05:6808:6c5:: with SMTP id m5mr3521717oih.143.1576085749488; Wed, 11 Dec 2019 09:35:49 -0800 (PST) MIME-Version: 1.0 References: <201912060006.xB6066qR058963@repo.freebsd.org> <820BE55B-AE32-44E7-8AC7-245EF6F86F8B@samsco.org> In-Reply-To: <820BE55B-AE32-44E7-8AC7-245EF6F86F8B@samsco.org> From: Alan Somers Date: Wed, 11 Dec 2019 10:35:38 -0700 Message-ID: Subject: Re: svn commit: r355430 - head/sys/cam/scsi To: Scott Long Cc: Steven Hartland , src-committers , svn-src-all , svn-src-head X-Rspamd-Queue-Id: 47Y3xL62xyz4Ngm X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.167.194 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-1.98 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.988,0]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; NEURAL_HAM_LONG(-0.98)[-0.975,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[freebsd.org]; RCPT_COUNT_FIVE(0.00)[5]; URI_COUNT_ODD(1.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[194.167.85.209.list.dnswl.org : 127.0.5.0]; IP_SCORE(-1.02)[ipnet: 209.85.128.0/17(-3.13), asn: 15169(-1.92), country: US(-0.05)]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[194.167.85.209.rep.mailspike.net : 127.0.0.17]; MIME_TRACE(0.00)[0:+,1:+,2:~]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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:35:52 -0000 No, and there's no possibility of connecting a Windows host to this particular device. We have some Oracle Solaris servers hooked up to these expanders, but it looks like Solaris completely ignores the offending element type. -Alan On Wed, Dec 11, 2019 at 10:19 AM Scott Long wrote: > U+FFFD doesn=E2=80=99t make sense for an ASCII string, but 0x3F might. A= ny idea > what Windows shows for this device? > > Scott > > > On Dec 11, 2019, at 8:42 AM, Alan Somers wrote: > > > > 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 tha= t > 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 > > > > On Fri, Dec 6, 2019 at 2:40 AM Steven Hartland < > steven.hartland@multiplay.co.uk> wrote: > > If the illegal chars where removed or replaced would the result be > useful, if so might that be a better approach? > > > > 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 > > > > Log: > > ses: sanitize illegal strings in SES element descriptors > > > > The SES4r3 standard requires that element descriptors may only contai= n > 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 "". > > > > This patch fixes "sesutil --libxo xml" on such systems. Previously i= t > would > > generate non-well-formed XML output. > > > > PR: 241929 > > Reviewed by: allanjude > > MFC after: 2 weeks > > Sponsored by: Axcient > > > > Modified: > > head/sys/cam/scsi/scsi_enc_ses.c > > > > 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; > > > > @@ -1977,6 +1977,35 @@ ses_publish_cache(enc_softc_t *enc, struct > enc_fsm_sta > > return (0); > > } > > > > +/* > > + * \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); > > } > > > > /* skip over the descriptor itself */ > >