[Skiboot] [PATCH 1/2] Add infrastructure for pointer validation

Stewart Smith stewart at linux.vnet.ibm.com
Tue Aug 9 17:17:31 AEST 2016


Balbir Singh <bsingharora at gmail.com> writes:
> If the kernel called an OPAL API with vmalloc'd address
> or any other address range in real mode, we would hit
> a problem with aliasing. Since the top 4 bits are ignored
> in real mode, pointers from 0xc.. and 0xd.. (and other ranges)
> could collide and lead to hard to solve bugs. This patch
> adds the infrastructure for pointer validation and a simple
> test case for testing the API
>
> Signed-off-by: Balbir Singh <bsingharora at gmail.com>
> ---
>  core/test/Makefile.check |  1 +
>  core/test/run-api-test.c | 51 ++++++++++++++++++++++++++++++++++++++++++++++++
>  include/opal-api.h       | 23 ++++++++++++++++++++++
>  3 files changed, 75 insertions(+)
>  create mode 100644 core/test/run-api-test.c

Finally got a chance to poke at this and think about it.

I like it.

I have a few thoughts that'd be great to address before merging,
although I'm rather keen to merge.

> --- /dev/null
> +++ b/core/test/run-api-test.c
> @@ -0,0 +1,51 @@
> +/* Copyright 2014-2015 IBM Corp.

Should be to 2016.

> diff --git a/include/opal-api.h b/include/opal-api.h
> index c86244b..e717ca3 100644
> --- a/include/opal-api.h
> +++ b/include/opal-api.h
> @@ -213,6 +213,9 @@
>
>  #ifndef __ASSEMBLY__
>
> +#include <stdbool.h>
> +#include <types.h>
> +
>  /* Other enums */
>  enum OpalVendorApiTokens {
>  	OPAL_START_VENDOR_API_RANGE = 1000, OPAL_END_VENDOR_API_RANGE = 1999
> @@ -1043,6 +1046,26 @@ enum {
>  	OPAL_PCI_TCE_KILL_ALL,
>  };
>
> +extern unsigned long top_of_ram;
> +
> +/*
> + * Returns true if the address is valid, false otherwise
> + *
> + * Checks if the passed address belongs to real address space
> + * or 0xc000... kernel address space. It also checks that
> + * addr <= total physical memory
> + */
> +static inline bool opal_addr_valid(const void *addr)
> +{
> +	unsigned long val = (unsigned long)addr;
> +	if ((val >> 60) != 0xc && (val >> 60) != 0x0)

I think it would be good to point to section 5.7 of the ISA as to where
the 60 comes from. We *could* check for a implementation specific value
too, P8 seems to be 50 bits (although other procs are
different). Although I'm not sure if there's any real value to be had
from that?

> +		return false;
> +	val &= ~0xf000000000000000;
> +	if (val > top_of_ram)
> +		return false;
> +	return true;
> +}

I'm wondering how we can hook this up to prlog(PR_ERROR) or something,
and then have FWTS annotation for it so that fwts would pick it up from
the skiboot log... maybe a macro around it?

-- 
Stewart Smith
OPAL Architect, IBM.



More information about the Skiboot mailing list