Re: Brainy: bug in x86/cpu_ucode_intel.c

[Maxime Villard <max%m00nbsd.net@localhost>]

Le 03/10/2015 16:29, Jean-Yves Migeon a écrit :
> Le 03/10/2015 15:45, Joerg Sonnenberger a écrit :
> > On Sat, Oct 03, 2015 at 02:46:26PM +0200, Maxime Villard wrote:
> > > You can see that the pointer given to kmem_free() is not the one kmem_alloc
> > > returned. Actually, I don't understand at all what this code is supposed to
> > > do. Found by Brainy.
> >
> > It tries to make sure the pointer has a certain alignment.

Yes, I understood that. What I don't understand is *why* it allocates
memory and wants it to be aligned; 'uh' is not used in the rest of the
function.

> > ...which
> > likely is something we do by default, so this is not really visible.
>
> Regarding kmem_alloc(9) this is not necessarily true, the allocator
> "steals" the first few bytes of the allocation to store the requested
> size (see the KMEM_SIZE option in [1] which is enabled under DIAGNOSTIC).

Yes. But these "stolen" bytes are 8-byte-aligned, which is the
guaranteed alignment for kmem_alloc(). So they don't create any
inconsistency from a kmem POV.

However, KMEM_SIZE gives a look at ptr[-1] when freeing memory. If ptr
is offset, ptr[-1] won't be a kmem_size structure, and the kernel will
panic.

Since kmem allocations are 8-byte-aligned, that roundup2 will do +0 or
+8. ISTR that pool_put() retrieves the pool item header by truncating
the pointer given as argument, to then put the item into the free list.
Since the offset is only 8 bytes here, it may not be visible.

Still, this is risky behavior.

> The only way I know of to guarantee alignement on a specific boundary is
> through uvm_km_alloc or pool_cache.
>
> [1] http://nxr.netbsd.org/xref/src/sys/kern/subr_kmem.c#63