Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 17 Aug 2018 08:51:20 +0800
From:      Marcelo Araujo <araujobsdport@gmail.com>
To:        Brooks Davis <brooks@freebsd.org>
Cc:        Warner Losh <imp@bsdimp.com>, "Rodney W. Grimes" <rgrimes@freebsd.org>,  John-Mark Gurney <jmg@funkthat.com>, src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org,  svn-src-head@freebsd.org
Subject:   Re: svn commit: r337887 - head/usr.sbin/bhyve
Message-ID:  <CAOfEmZgDaww6KJBgYJVj0ncSF2fNEg2ct6Ka83NEY9TBVRjw7Q@mail.gmail.com>
In-Reply-To: <20180816233314.GA11357@spindle.one-eyed-alien.net>
References:  <CANCZdfqQea=vrJPJ1mafjuX8ZTyx6bFW=WpawdVfyq45v40hAw@mail.gmail.com> <201808161929.w7GJTWfS055411@pdx.rh.CN85.dnsmgr.net> <CAOfEmZjtObzMzp6pa2QY5105t82jC155bXOjb9DKn9=pTnwYEQ@mail.gmail.com> <20180816231630.GA10866@spindle.one-eyed-alien.net> <CANCZdfq5_hkAstQKCJJiGAYgM8Zeaz_3GMhegpR06OTowihJNw@mail.gmail.com> <20180816233314.GA11357@spindle.one-eyed-alien.net>

next in thread | previous in thread | raw e-mail | index | archive | help
2018-08-17 7:33 GMT+08:00 Brooks Davis <brooks@freebsd.org>:

> On Thu, Aug 16, 2018 at 05:23:26PM -0600, Warner Losh wrote:
> > On Thu, Aug 16, 2018 at 5:16 PM, Brooks Davis <brooks@freebsd.org>
> wrote:
> >
> > > On Fri, Aug 17, 2018 at 07:04:05AM +0800, Marcelo Araujo wrote:
> > > > 2018-08-17 3:29 GMT+08:00 Rodney W. Grimes
> <freebsd@pdx.rh.cn85.dnsmgr.
> > > net>:
> > > >
> > > > > > On Thu, Aug 16, 2018 at 11:06 AM, John-Mark Gurney <
> jmg@funkthat.com
> > > >
> > > > > wrote:
> > > > > >
> > > > > > > Marcelo Araujo wrote this message on Thu, Aug 16, 2018 at 06:31
> > > +0000:
> > > > > > > > Author: araujo
> > > > > > > > Date: Thu Aug 16 06:31:54 2018
> > > > > > > > New Revision: 337887
> > > > > > > > URL: https://svnweb.freebsd.org/changeset/base/337887
> > > > > > > >
> > > > > > > > Log:
> > > > > > > >   Add a comment explaining how the PSN works and why there
> is no
> > > > > need for
> > > > > > > >   a null terminator. Also mark CID 1394825 as intentional.
> > > > > > > >
> > > > > > > >   Reported by:        Coverity
> > > > > > > >   CID:                1394825
> > > > > > > >   MFC after:  1 week
> > > > > > > >   Sponsored by:       iXsystems Inc.
> > > > > > > >
> > > > > > > > Modified:
> > > > > > > >   head/usr.sbin/bhyve/pci_nvme.c
> > > > > > > >
> > > > > > > > Modified: head/usr.sbin/bhyve/pci_nvme.c
> > > > > > > > ============================================================
> > > > > > > ==================
> > > > > > > > --- head/usr.sbin/bhyve/pci_nvme.c    Thu Aug 16 06:20:25
> 2018
> > > > > > > (r337886)
> > > > > > > > +++ head/usr.sbin/bhyve/pci_nvme.c    Thu Aug 16 06:31:54
> 2018
> > > > > > > (r337887)
> > > > > > > > @@ -1714,6 +1714,11 @@ pci_nvme_parse_opts(struct
> pci_nvme_softc
> > > *sc,
> > > > > > > char *o
> > > > > > >
> > > > > > > [...]
> > > > > > >
> > > > > > > >                       memset(sc->ctrldata.sn, 0, sizeof(sc->
> > > > > ctrldata.sn
> > > > > > > ));
> > > > > > > >                       strncpy(sc->ctrldata.sn, config,
> > > > > > > >                               sizeof(sc->ctrldata.sn));
> > > > > > >
> > > > > > > This memset is unneeded, as strncpy will write NUL bytes to
> fill
> > > out
> > > > > > > the buffer:
> > > > > > > If src is less than len characters long, the remainder of
> > > > > > >      dst is filled with `\0' characters.
> > > > > > >
> > > > > >
> > > > > > It also looks like the comment was wrong. The newest NVMe
> standards
> > > say
> > > > > > these fields should be 7-bit and space-padded.
> > > > >
> > > > > lol, which is what the vendor that caused me grief with
> > > > > ata serial numbers did decades ago.
> > > > >
> > > > > --
> > > > > Rod Grimes
> > > > > rgrimes@freebsd.org
> > > > >
> > > >
> > > > I have discussed a bit with imp@, but I will drop the patch here to
> get
> > > > other peoples opinion too.
> > > > So, name space and firmware number also need to be padded with
> spaces.
> > > >
> > > > I couldn't think in any other better way to do that.
> > > >
> > > > Does this patch looks reasonable?
> > > > https://people.freebsd.org/~araujo/pci_nvme.diff
> > >
> > > You should check that len<=dst_size and at least truncate rather than
> > > overflowing.  If the strings from userspace you need to return or log
> an
> > > error, if they come from the kernel, you can panic.
> >
> > Help me understand, I thought that the strnlen bounded what was copied.
>
> Apparently the standard calls for ' ' rather than '\0' padding.  The
> prop memcpy+memset does the job, but contains potential overflows.
>
> -- Brooks
>

Maybe I missed something, but when I call cpywithpad() I pass the dst_size,
even if the 'src' is bigger than the 'dst' it will be truncated because
with strnlen(src, dst_size) the src will be reduced to dst_size length.

I made couple tests and could not overflow it(example):

cd->fr maximum length is 8:
cpywithpad((char *)cd->fr, sizeof(cd->fr), "1.00000090000000000000\0", ' ');

the output of cpywithpad:
len: 8 is <= dst_size: 8

Same tests I made with mn that has length of 40 adding a string with 244
characters.
Sorry my ignorance, but could you give me a better example?

Best,
-- 

-- 
Marcelo Araujo            (__)araujo@FreeBSD.org
\\\'',)http://www.FreeBSD.org <http://www.freebsd.org/>;   \/  \ ^
Power To Server.         .\. /_)



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOfEmZgDaww6KJBgYJVj0ncSF2fNEg2ct6Ka83NEY9TBVRjw7Q>