public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
From: Cyril Hrubis <chrubis@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] [RFC PATCH 2/9] lib: Add a canary for guarded buffers
Date: Thu, 1 Aug 2019 13:54:18 +0200	[thread overview]
Message-ID: <20190801115418.GB23916@rei> (raw)
In-Reply-To: <1516778317.3992530.1564656190448.JavaMail.zimbra@redhat.com>

Hi!
> > In a case that the buffer size is not a multiple of a page size there is
> > unused space before the start of the buffer. Let's fill that with
> > center mirrored random bytes and check that the buffer wasn't modified
> > before we unmap it.
> > 
> >  void *tst_alloc(size_t size)
> >  {
> >  	size_t page_size = getpagesize();
> > @@ -34,9 +61,13 @@ void *tst_alloc(size_t size)
> >  	maps = map;
> >  
> >  	if (size % page_size)
> > -		ret += page_size - (size % page_size);
> > +		map->buf_shift = page_size - (size % page_size);
> > +	else
> > +		map->buf_shift = 0;
> > +
> > +	setup_canary(map);
> >  
> > -	return ret;
> > +	return ret + map->buf_shift;
> 
> My concern here is alignment.

I'm aware of that. My reasoning here is that:

* The end of the page is aligned by definition to 2^page_order

* Any primitive types such as integer, etc. are hence aligned

* Structures are padded so that the total size is multiple of
  the largest alignment required (because otherwise arrays of
  structures would end up causing unaligned access as well).

That leaves out things such as buffers for direct I/O, the only way to
allocate aligned buffers there is to make the size to be multiple of
the block size.

-- 
Cyril Hrubis
chrubis@suse.cz

  reply	other threads:[~2019-08-01 11:54 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-01  9:26 [LTP] [RFC PATCH 0/9] Introduce guarded buffers Cyril Hrubis
2019-08-01  9:26 ` [LTP] [RFC PATCH 1/9] lib: Add support for " Cyril Hrubis
2019-08-01 10:39   ` Jan Stancek
2019-08-01 11:45     ` Cyril Hrubis
2019-08-02 14:03       ` Richard Palethorpe
2019-08-02 13:57     ` Richard Palethorpe
2019-08-02 13:59       ` Cyril Hrubis
2019-08-02 14:23         ` Cyril Hrubis
2019-08-02 14:36         ` Richard Palethorpe
2019-08-02 14:50           ` Cyril Hrubis
2019-08-02 14:20   ` Cyril Hrubis
2019-08-03 12:55   ` Li Wang
2019-08-06  7:36     ` Richard Palethorpe
2019-08-06  9:03   ` Richard Palethorpe
2019-08-08  9:06     ` Cyril Hrubis
2019-08-08  9:13       ` Li Wang
2019-08-08 15:41       ` Richard Palethorpe
2019-08-01  9:26 ` [LTP] [RFC PATCH 2/9] lib: Add a canary " Cyril Hrubis
2019-08-01 10:43   ` Jan Stancek
2019-08-01 11:54     ` Cyril Hrubis [this message]
2019-08-01 16:32       ` Jan Stancek
2019-08-02  9:47         ` Cyril Hrubis
2019-08-02 10:54           ` Jan Stancek
2019-08-03 13:02   ` Li Wang
2019-08-08  9:27     ` Cyril Hrubis
2019-08-01  9:26 ` [LTP] [RFC PATCH 3/9] syscalls/preadv01: Make use of " Cyril Hrubis
2019-08-01  9:26 ` [LTP] [RFC PATCH 4/9] syscalls/accept4_01: " Cyril Hrubis
2019-08-01  9:26 ` [LTP] [RFC PATCH 5/9] syscalls/add_key04: " Cyril Hrubis
2019-08-01  9:26 ` [LTP] [RFC PATCH 6/9] syscalls/adjtimex: " Cyril Hrubis
2019-08-01  9:26 ` [LTP] [RFC PATCH 7/9] syscalls/clock_getres01: " Cyril Hrubis
2019-08-01  9:26 ` [LTP] [RFC PATCH 8/9] syscalls/clock_settime01: " Cyril Hrubis
2019-08-01  9:26 ` [LTP] [RFC PATCH 9/9] syscalls/sendmmsg01: " Cyril Hrubis
2019-08-06  9:47 ` [LTP] [PATCH v3 0/4] eBPF tests using guarded buffers API Richard Palethorpe
2019-08-06  9:47   ` [LTP] [PATCH v3 1/4] BPF: Essential headers for map creation Richard Palethorpe
2019-08-06  9:47   ` [LTP] [PATCH v3 2/4] BPF: Sanity check creating and updating maps Richard Palethorpe
2019-08-06  9:47   ` [LTP] [PATCH v3 3/4] BPF: Essential headers for a basic program Richard Palethorpe
2019-08-06  9:47   ` [LTP] [PATCH v3 4/4] BPF: Sanity check creating a program Richard Palethorpe

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=20190801115418.GB23916@rei \
    --to=chrubis@suse.cz \
    --cc=ltp@lists.linux.it \
    /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