[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH qemu v2] spapr: Kill SLOF

From: David Gibson
Subject: Re: [PATCH qemu v2] spapr: Kill SLOF
Date: Tue, 7 Jan 2020 16:54:36 +1100

On Tue, Jan 07, 2020 at 03:44:35PM +1100, Alexey Kardashevskiy wrote:
> On 06/01/2020 15:19, David Gibson wrote:
> >> +
> >> +static uint32_t client_package_to_path(const void *fdt, uint32_t phandle,
> >> +                                       uint32_t buf, uint32_t len)
> >> +{
> >> +    char tmp[256];
> > 
> > Fixed sized buffers are icky.  You could either dynamically allocate
> > this based on the size the client gives, or you could use
> > memory_region_get_ram_ptr() to read the data from the tree directly
> > into guest memory.
> @len comes from the guest, I am really not comfortable with allocating
> whatever (broken) guest requested. And if I limit @len by 1024 or
> similar, then a fixed size buffer will do too, no?

I see your point.  Does this call have a way to report failure?  In
that case you could outright fail the call if it requests too long a

> btw how exactly can I use memory_region_get_ram_ptr()?
> get_system_memory() returns a root MR which is not RAM, RAM is a
> "spapr.ram" sub-MR.

Right, but you know that RAM is always at offset 0 within that root
MR.  That said, it doesn't look like it's that easy to bounds check
that pointer, so maybe that's not a good idea after all.

David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!

Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]