History log of /fuchsia/zircon/system/utest/vdso-variant/helper/rules.mk
Revision Date Author Comments
# 008b27ed 15-Sep-2017 Roland McGrath <mcgrathr@google.com>

[build] Make MODULE_GROUP mandatory for user modules

Make sure everything in the manifest has a group tag.

Change-Id: Id33e8ef34c148d6b18e34acc7a59466a3e18daf2


# f3e2126c 12-Sep-2017 Roland McGrath <mcgrathr@google.com>

[zx] Magenta -> Zircon

The Great Renaming is here!

Change-Id: I3229bdeb2a3d0e40fb4db6fec8ca7d971fbffb94


# 4d682aee 26-May-2017 Roland McGrath <mcgrathr@google.com>

[kernel][vdso][userboot][devmgr] Machinery for variant vDSOs

This provides machinery to implement multiple variants of the vDSO.
Each variant can blacklist some of the functions so their symbols
are not visible to dynamic linking and their code gets blacked out
so there's no secret jump targets to use.

Because all the variants are just subsets of the full-featured vDSO,
all the code addresses still match across all variants and the
syscall entry enforcement machinery doesn't need to care which
variant is being used.

All the available vDSO VMOs are attached at /boot/vdso/<name>, where
<name> is "full" for the primary vDSO and other names will be used
for variants. Currently, only some test variants are implemented.

Each variant can blacklist one or more category of syscalls. A
category is any attribute name used in syscalls.sysgen. A new
variant is added by adding an element to the VDso::Variant enum and
adding a case for that to VDso::CreateVariant that sets the name
and calls blacklist_<category>_syscalls for each category to be
blacklisted in that variant.

Change-Id: I32e5ee658a903365fff234e22738f7127622ed33