machine/param.h Leak of non-standard methods to Application Space

Joel Sherrill joel at rtems.org
Thu Oct 18 15:31:07 UTC 2018


On Thu, Oct 18, 2018 at 12:08 AM Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:

> On 17/10/2018 17:04, Joel Sherrill wrote:
> > Hi
> >
> > We are updating the port of a large third party framework and ran
> > into an issue where what I would think are BSD kernel methods
> > leak into application space. All but one of the methods is used
> > by rtems-libbsd code.
> >
> > I think the following in <machine/param.h> needs to be protected by
> > an _KERNEL ifdef.
> >
> > Does that sound OK?
> >
> > ============================
> > /*
> >  * Mach derived conversion macros
> >  */
> > #define round_page(x)           (((unsigned long)(x) + PAGE_MASK) &
> > ~PAGE_MASK)
> > #define trunc_page(x)           ((unsigned long)(x) & ~PAGE_MASK)
> >
> > #define atop(x)                 ((unsigned long)(x) >> PAGE_SHIFT)
> > #define ptoa(x)                 ((unsigned long)(x) << PAGE_SHIFT)
> >
> > #define pgtok(x)                ((unsigned long)(x) * (PAGE_SIZE / 1024))
> > ============================
>
> In FreeBSD they are always present:
>
>
> https://github.com/freebsd/freebsd/blob/master/sys/riscv/include/param.h#L97
>
> The <sys/param.h> is not a POSIX header file. Unfortunately it is
> included in <sys/_cpuset.h> and thus in <rtems.h>. I think we should fix.
>
> Are these macros only used in kernel-space files in libbsd?
>

Looks that way to me:

[joel at rtbf64c rtems-libbsd]$ for s in round_page trunc_page atop ptoa pgtok
; do grep -r $s; done | grep -v catopen
freebsd/sys/kern/sys_pipe.c:    size = round_page(size);
freebsd/sys/kern/subr_uio.c:    *addr =
round_page((vm_offset_t)vms->vm_daddr +
freebsd/sys/kern/subr_uio.c:    size = (vm_size_t)round_page(sz);
freebsd/sys/kern/subr_uio.c:    size = (vm_size_t)round_page(sz);
freebsd/sys/vm/uma_core.c:          atomic_fetchadd_long(&keg->uk_offset,
round_page(bytes));
freebsd/contrib/tcpdump/print-atm.c:            /* SCCOP with some unknown
protocol atop it */
freebsd/contrib/tcpdump/print-ip6.c:                     * which payload
can be piggybacked atop a
freebsd/sys/kern/init_main.c:   pageablemem =
ptoa((vm_paddr_t)vm_cnt.v_free_count);
freebsd/usr.bin/vmstat/vmstat.c:#define vmstat_pgtok(a) ((a) *
(sum.v_page_size >> 10))
freebsd/usr.bin/vmstat/vmstat.c:
vmstat_pgtok(total.t_avm));
freebsd/usr.bin/vmstat/vmstat.c:
vmstat_pgtok(total.t_free));

freebsd/usr.bin/vmstat/vmstat.c defines its own vmstat_pgtok() so I think
this is a clean change.

Going to proceed with assuming it is OK for us.

Is this something that we may need to discuss with upstream FreeBSD?

--joel


> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax     : +49 89 189 47 41-09
> E-Mail  : sebastian.huber at embedded-brains.de
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20181018/fb06f2bb/attachment.html>


More information about the devel mailing list