On Thu, Oct 19, 2017 at 07:49:06AM +0200, Jason A. Donenfeld wrote:
> A small detail carried over from the other thread:
>
> >
> > but a bigger problem might the following thing:
> >
> > vscnprintf()
> > pointer()
> > ptr_to_id()
> >initialize_ptr_secret()
> > get_random_bytes()
> >
> Tangent: why is the random_ready API designed with -EALREADY? Couldn't
> add_random_ready_callback() just perform the call itself and avoid
> needing all the callers to check for -EALREADY?
Absolutely. I can submit a patch for this soon, though to avoid merge
dependencies, and given the usual de
On Wed, Oct 18, 2017 at 10:49 PM, Jason A. Donenfeld wrote:
> static void fill_random_ptr_key(struct random_ready_callback *rdy)
> {
> get_random_bytes(&ptr_secret, sizeof(ptr_secret));
> static_branch_disable(&no_ptr_secret);
> }
>
> static struct random_ready_callback random_ready = {
>
A small detail carried over from the other thread:
>
> but a bigger problem might the following thing:
>
> vscnprintf()
> pointer()
> ptr_to_id()
>initialize_ptr_secret()
> get_random_bytes()
> _get_random_bytes()
> extract_crng()
>_extract_crng()
> spin_lock_
On Thu, Oct 19, 2017 at 03:36:20AM +0200, Jason A. Donenfeld wrote:
> On Thu, Oct 19, 2017 at 3:31 AM, Sergey Senozhatsky
> wrote:
> > On (10/19/17 03:03), Jason A. Donenfeld wrote:
> > [..]
> >> 1) Go back to the spinlock yourself.
> >
> > so we ruled out NMI deadlocks?
>
> Oh, right. No, I have
On Thu, Oct 19, 2017 at 3:31 AM, Sergey Senozhatsky
wrote:
> On (10/19/17 03:03), Jason A. Donenfeld wrote:
> [..]
>> 1) Go back to the spinlock yourself.
>
> so we ruled out NMI deadlocks?
Oh, right. No, I haven't thought through this enough to rule it out.
Indeed if that's an issue, the locks i
On (10/19/17 03:03), Jason A. Donenfeld wrote:
[..]
> 1) Go back to the spinlock yourself.
so we ruled out NMI deadlocks?
-ss
On Wed, Oct 18, 2017 at 11:30 PM, Tobin C. Harding wrote:
> +static siphash_key_t ptr_secret __read_mostly;
> +static atomic_t have_key = ATOMIC_INIT(0);
> +
> +static void initialize_ptr_secret(void)
> +{
> + if (atomic_read(&have_key) == 1)
> + return;
> +
> + get_rando
On Wed, Oct 18, 2017 at 03:31:16PM -0700, Kees Cook wrote:
> On Wed, Oct 18, 2017 at 2:30 PM, Tobin C. Harding wrote:
> > Currently there are many places in the kernel where addresses are being
> > printed using an unadorned %p. Kernel pointers should be printed using
> > %pK allowing some control
On Wed, Oct 18, 2017 at 2:30 PM, Tobin C. Harding wrote:
> Currently there are many places in the kernel where addresses are being
> printed using an unadorned %p. Kernel pointers should be printed using
> %pK allowing some control via the kptr_restrict sysctl. Exposing addresses
> gives attackers
Currently there are many places in the kernel where addresses are being
printed using an unadorned %p. Kernel pointers should be printed using
%pK allowing some control via the kptr_restrict sysctl. Exposing addresses
gives attackers sensitive information about the kernel layout in memory.
We can
11 matches
Mail list logo
