Re: svn commit: r355430 - head/sys/cam/scsi
At some point, we used to replace bad chars with spaces, but that may have been two ata stacks ago.. Warner On Wed, Dec 11, 2019, 9:35 AM Alan Somers wrote: > 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’t 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: >> > >> > 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 >> > >> > On Fri, Dec 6, 2019 at 2:40 AM Steven Hartland < >> steven.hartl...@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 >> 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 "". >> > >> > This patch fixes "sesutil --libxo xml" on such systems. Previously >> it 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 >> > >> == >> > --- head/sys/cam/scsi/scsi_enc_ses.cThu Dec 5 19:39:51 2019 >> (r355429) >> > +++ head/sys/cam/scsi/scsi_enc_ses.cFri 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 = ""; >> > + int i; >> > + >> > + for (i = 0; i < *len; i++) { >> > + if (desc[i] < 0x20 || desc[i] > 0x7e) { >> > + *len = strlen(invalid); >> > + return (invalid); >> > + } else if (desc[i] == 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 = element->elm_private; >> > elmpriv->descr_len = length; >> > - elmpriv->descr = &buf[offset]; >> > + elmpriv->descr = >> ses_sanitize_elm_desc(&buf[offset], >> > + &elmpriv->descr_len); >> > } >> > >> > /* skip over the descriptor itself */ >> >> ___ sv
Re: svn commit: r355430 - head/sys/cam/scsi
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’t 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: > > > > 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 > > > > On Fri, Dec 6, 2019 at 2:40 AM Steven Hartland < > steven.hartl...@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 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 "". > > > > This patch fixes "sesutil --libxo xml" on such systems. Previously it > 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 > > > == > > --- head/sys/cam/scsi/scsi_enc_ses.cThu Dec 5 19:39:51 2019 > (r355429) > > +++ head/sys/cam/scsi/scsi_enc_ses.cFri 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 = ""; > > + int i; > > + > > + for (i = 0; i < *len; i++) { > > + if (desc[i] < 0x20 || desc[i] > 0x7e) { > > + *len = strlen(invalid); > > + return (invalid); > > + } else if (desc[i] == 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 = element->elm_private; > > elmpriv->descr_len = length; > > - elmpriv->descr = &buf[offset]; > > + elmpriv->descr = > ses_sanitize_elm_desc(&buf[offset], > > + &elmpriv->descr_len); > > } > > > > /* skip over the descriptor itself */ > > ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r355430 - head/sys/cam/scsi
U+FFFD doesn’t 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: > > 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 > > 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? > > 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 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 "". > > This patch fixes "sesutil --libxo xml" on such systems. Previously it 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 > == > --- head/sys/cam/scsi/scsi_enc_ses.cThu Dec 5 19:39:51 2019 > (r355429) > +++ head/sys/cam/scsi/scsi_enc_ses.cFri 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 = ""; > + int i; > + > + for (i = 0; i < *len; i++) { > + if (desc[i] < 0x20 || desc[i] > 0x7e) { > + *len = strlen(invalid); > + return (invalid); > + } else if (desc[i] == 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 = element->elm_private; > elmpriv->descr_len = length; > - elmpriv->descr = &buf[offset]; > + elmpriv->descr = ses_sanitize_elm_desc(&buf[offset], > + &elmpriv->descr_len); > } > > /* skip over the descriptor itself */ ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r355430 - head/sys/cam/scsi
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 On Fri, Dec 6, 2019 at 2:40 AM Steven Hartland < steven.hartl...@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 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 "". >> >> This patch fixes "sesutil --libxo xml" on such systems. Previously it >> 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 >> >> == >> --- head/sys/cam/scsi/scsi_enc_ses.cThu Dec 5 19:39:51 2019 >> (r355429) >> +++ head/sys/cam/scsi/scsi_enc_ses.cFri 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 = ""; >> + int i; >> + >> + for (i = 0; i < *len; i++) { >> + if (desc[i] < 0x20 || desc[i] > 0x7e) { >> + *len = strlen(invalid); >> + return (invalid); >> + } else if (desc[i] == 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 = element->elm_private; >> elmpriv->descr_len = length; >> - elmpriv->descr = &buf[offset]; >> + elmpriv->descr = >> ses_sanitize_elm_desc(&buf[offset], >> + &elmpriv->descr_len); >> } >> >> /* skip over the descriptor itself */ >> > ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r355430 - head/sys/cam/scsi
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 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 "". > > This patch fixes "sesutil --libxo xml" on such systems. Previously it > 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 > > == > --- head/sys/cam/scsi/scsi_enc_ses.cThu Dec 5 19:39:51 2019 > (r355429) > +++ head/sys/cam/scsi/scsi_enc_ses.cFri 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 = ""; > + int i; > + > + for (i = 0; i < *len; i++) { > + if (desc[i] < 0x20 || desc[i] > 0x7e) { > + *len = strlen(invalid); > + return (invalid); > + } else if (desc[i] == 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 = element->elm_private; > elmpriv->descr_len = length; > - elmpriv->descr = &buf[offset]; > + elmpriv->descr = > ses_sanitize_elm_desc(&buf[offset], > + &elmpriv->descr_len); > } > > /* skip over the descriptor itself */ > ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r355430 - head/sys/cam/scsi
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 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 "". This patch fixes "sesutil --libxo xml" on such systems. Previously it 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 == --- head/sys/cam/scsi/scsi_enc_ses.cThu Dec 5 19:39:51 2019 (r355429) +++ head/sys/cam/scsi/scsi_enc_ses.cFri 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 = ""; + int i; + + for (i = 0; i < *len; i++) { + if (desc[i] < 0x20 || desc[i] > 0x7e) { + *len = strlen(invalid); + return (invalid); + } else if (desc[i] == 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 = element->elm_private; elmpriv->descr_len = length; - elmpriv->descr = &buf[offset]; + elmpriv->descr = ses_sanitize_elm_desc(&buf[offset], + &elmpriv->descr_len); } /* skip over the descriptor itself */ ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"