lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87v8rbsn9j.ffs@tglx>
Date:   Mon, 01 Aug 2022 22:48:56 +0200
From:   Thomas Gleixner <tglx@...utronix.de>
To:     "Jason A. Donenfeld" <Jason@...c4.com>,
        linux-kernel@...r.kernel.org
Cc:     "Jason A. Donenfeld" <Jason@...c4.com>,
        linux-crypto@...r.kernel.org, x86@...nel.org,
        Nadia Heninger <nadiah@...ucsd.edu>,
        Thomas Ristenpart <ristenpart@...nell.edu>,
        Theodore Ts'o <tytso@....edu>,
        Vincenzo Frascino <vincenzo.frascino@....com>,
        Adhemerval Zanella Netto <adhemerval.zanella@...aro.org>,
        Florian Weimer <fweimer@...hat.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH RFC v2] random: implement getrandom() in vDSO

On Sun, Jul 31 2022 at 03:31, Jason A. Donenfeld wrote:

> +vobjs-y := vdso-note.o vclock_gettime.o vgetcpu.o vgetrandom.o

You clearly forgot to tell people that they need a special config to
make this compile.

I don't even have to try to see that this cannot build with a defconfig:

Lacks -pg for that file and the included chacha.c contains
EXPORT_SYMBOL() which is not really working in the VDSO.

> +DECLARE_VVAR_SINGLE(640, struct vdso_rng_data, _vdso_rng_data)
...
> +#define __vdso_rng_data (VVAR(_vdso_rng_data))
> +
> +static __always_inline const struct vdso_rng_data *__arch_get_vdso_rng_data(void)
> +{
> +	return &__vdso_rng_data;
> +}

That's not working with time name spaces.

> +static __always_inline ssize_t
> +__cvdso_getrandom(void *opaque_state, void *buffer, size_t len, unsigned int flags)
> +{
> +	struct getrandom_state *state = opaque_state;
> +	const struct vdso_rng_data *rng_info = __arch_get_vdso_rng_data();

This gives you vvar__vdso_rng_data and that points to the VVAR page at
offset 640. That works up to the point where a task is part of a
non-root time name space.

The kernel side mapping (the one which is updated) looks like this:

    VVAR_PAGE
    VIRT_CLOCK_PAGE[S]
    TIMENS_PAGE

If time namespaces are disabled or the task is in the root time
namespace then the user mapping is in the same order.

If the task is in the non-root time namespace, then the user mapping is:

    TIMENS_PAGE
    VIRT_CLOCK_PAGE[S]
    VVAR_PAGE

So your user space looks at offset 640 in the TIMENS_PAGE, which has
rand_data->ready and rand_data->generation == 0 forever.

See the comment above timens_setup_vdso_data() and look at the way how
e.g. __cvdso_time_data() deals with that.

VDSO hacking is special and not a sunday evening project. :)

Thanks,

        tglx

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ