svn commit: r315653 - in head: lib/libstand sys/boot/common sys/boot/i386/libi386

[Rodney W. Grimes]

> On 3/21/17 11:53 AM, Toomas Soome wrote:
> >
> >> On 21. m?rts 2017, at 17:15, Ian Lepore <ian at freebsd.org> wrote:
> >>
> >> On Tue, 2017-03-21 at 15:35 +0300, Slawa Olhovchenkov wrote:
> >>> On Mon, Mar 20, 2017 at 10:20:17PM +0000, Toomas Soome wrote:
> >>>
> >>>>
> >>>> Author: tsoome
> >>>> Date: Mon Mar 20 22:20:17 2017
> >>>> New Revision: 315653
> >>>> URL: https://svnweb.freebsd.org/changeset/base/315653
> >>>>
> >>>> Log:
> >>>>   loader: verify the value from dhcp.interface-mtu and use snprintf
> >>>> to set mtu
> >>>>
> >>>>   Since the uset can set dhcp.interface-mtu, we need to try to
> >>>> validate the
> >>>>   value. So we verify if the conversion to int is successful and we
> >>>> will not
> >>>>   allow to set value greater than max IPv4 packet size.
> >>>>
> >>>> +				    tmp > USHRT_MAX) {
> >>>> +					printf("%s: bad value:
> >>>> \"%s\", "
> >>>> +					    "ignoring\n",
> >>>> +					    "dhcp.interface-mtu",
> >>>> val);
> >>> ===
> >>> USHRT_MAX	Maximum value for an object of type unsigned short
> >>> int
> >>> 65535 (216-1) or greater*
> >>>
> >>> * the actual value depends on the particular system and library
> >>> implementation, but shall reflect the limits of these types in the
> >>> target platform.
> >>> ===
> >>>
> >>> I mean IF_MAXMTU more correct.
> >>>
> >>
> >> The context here is libstand; because it is standalone by design, the
> >> code doesn't have access to IF_MAXMTU or other kernel/userland
> >> constants.  There is also no question that a short is 16 bits or that
> >> USHRT_MAX will be anything other than 65535 in that environment.  If
> >> some platform did appear that had a different-sized short by default,
> >> we would add whatever flags are necessary to force it back to 16 bits
> >> in src/share/mk/bsd.stand.mk.
> >>
> >
> >
> > Also note the ?upper? value is entirely fictional - we felt we need
> > to  pick some ?sane? default, with current (common 1Gb/s) ethernet hardware
> > you will be in trouble long before reaching that value;)
> 
> All the world is not an VAX, nor is every network Ethernet.
> 
> HIPPI, not that you see much of it nowadays, had a MTU for
> switched networks of 65280 (64K - 216 bytes of overhead).
> Using USHRT_MAX is exactly the right thing here.

USHRT_MAX _could_ easily be >16 bits in the not too distant future,
though this code doesnt seem to be able to include the proper header
to get to a proper define it should probably just localally #define
it to be 65535 to avoid the breakage 10 years from now.

> -Kurt
-- 
Rod Grimes                                                 rgrimes at freebsd.org