public inbox for kernel-hardening@lists.openwall.com
 help / color / mirror / Atom feed
From: Solar Designer <solar@openwall.com>
To: kernel-hardening@lists.openwall.com
Subject: Re: [kernel-hardening] [RFC] x86, mm: start mmap allocation for libs from low addresses
Date: Wed, 7 Sep 2011 13:30:36 +0400	[thread overview]
Message-ID: <20110907093036.GA17693@openwall.com> (raw)
In-Reply-To: <20110907090900.GA3910@albatros>

Vasiliy,

On Wed, Sep 07, 2011 at 01:09:00PM +0400, Vasiliy Kulikov wrote:
> I've updated patch description, code comments, and "if" condition.  If
> no other objection, I'll post it as RFCv2 on LKML.

I've included some minor corrections below.  Please make changes
accordingly and post to LKML.

> +#ifdef CONFIG_VM86
> +/*
> + * Don't touch any memory that can be addressed by vm86 apps.
> + * Reserve the first 1 MiB + 64 kb.
> + */
> +#define ASCII_ARMOR_MIN_ADDR 0x00110000
> +#else
> +/* No special users of low addresses.  Start just after mmap_min_addr. */
> +#define ASCII_ARMOR_MIN_ADDR 0
> +#endif

What if mmap_min_addr set really low, or is even 0?  I think we want to
skip low addresses even if processes are permitted to use those.
(Permitted does not mean encouraged.)  So how about ASCII_ARMOR_MIN_ADDR
0x19000 (100 KB) when !CONFIG_VM86?

> +	/* We ALWAYS start from the beginning as base addresses
> +	 * with zero high bits is a valued resource */

s/valued/scarce and valuable/

> +		 * If kernel.randomize_va_space < 2, the executable is build as

s/build/built/

Thanks,

Alexander

  reply	other threads:[~2011-09-07  9:30 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-12 10:29 [kernel-hardening] [RFC] x86, mm: start mmap allocation for libs from low addresses Vasiliy Kulikov
2011-08-12 10:58 ` Solar Designer
2011-08-12 11:05   ` Vasiliy Kulikov
2011-08-25 17:19   ` Vasiliy Kulikov
2011-08-25 17:39     ` Solar Designer
2011-09-02 18:29     ` Solar Designer
2011-09-03 11:18       ` Vasiliy Kulikov
2011-09-03 23:57         ` Solar Designer
2011-09-05 12:46           ` Vasiliy Kulikov
2011-09-06  5:05             ` Solar Designer
2011-09-07  9:09               ` Vasiliy Kulikov
2011-09-07  9:30                 ` Solar Designer [this message]
2011-09-07  9:34                   ` Vasiliy Kulikov
2011-09-07  9:43                     ` Solar Designer
2011-09-07  9:55                       ` Vasiliy Kulikov
2011-09-07 10:16                         ` Solar Designer
2011-09-07 11:01                           ` Vasiliy Kulikov
2011-09-02 23:34     ` Solar Designer
2011-09-03 12:12       ` Vasiliy Kulikov
2011-09-03 23:40         ` Solar Designer
2011-09-04  7:21         ` Vasiliy Kulikov
2011-08-12 23:19 ` [kernel-hardening] " H. Peter Anvin
2011-08-13  6:26   ` Vasiliy Kulikov
2011-08-16  9:05   ` Vasiliy Kulikov
2011-08-22 10:17     ` Vasiliy Kulikov
2011-08-22 17:24       ` H. Peter Anvin
2011-08-22 20:14         ` Vasiliy Kulikov
2011-08-22 20:17           ` H. Peter Anvin
2011-08-23  6:41             ` Vasiliy Kulikov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110907093036.GA17693@openwall.com \
    --to=solar@openwall.com \
    --cc=kernel-hardening@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox