From: Mike Snitzer <snitzer@redhat.com>
To: AliOS system security <alios_sys_security@linux.alibaba.com>
Cc: dm-devel@redhat.com, Alasdair Kergon <agk@redhat.com>
Subject: Re: dm crypt: use unsigned long long instead of sector_t to store iv_offset
Date: Thu, 1 Nov 2018 16:06:42 -0400 [thread overview]
Message-ID: <20181101200642.GA29073@redhat.com> (raw)
In-Reply-To: <1541062439-55558-1-git-send-email-alios_sys_security@linux.alibaba.com>
On Thu, Nov 01 2018 at 4:53am -0400,
AliOS system security <alios_sys_security@linux.alibaba.com> wrote:
> The iv_offset in the mapping table of crypt target is a 64bit number
> when iv mode is plain64 or plain64be. It will be assigned to iv_offset of
> struct crypt_config, cc_sector of struct convert_context and iv_sector of
> struct dm_crypt_request. These structures members are defined as a sector_t.
> But sector_t is 32bit when CONFIG_LBDAF is not set in 32bit kernel. In this
> situation sector_t is not big enough to store the 64bit iv_offset.
I really don't think this is needed.
cc->iv_offset can only address a the address space used to access the
device. Which is expressed in terms of sectors. Therefore if
CONFIG_LBDAF is not set in 32bit kernel then there is no need to address
beyond that which 'sector_t' addresses.
Please show proof to the contrary if you still think this change is
needed.
Mike
next prev parent reply other threads:[~2018-11-01 20:06 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-01 8:53 [PATCH] dm crypt: use unsigned long long instead of sector_t to store iv_offset AliOS system security
2018-11-01 20:06 ` Mike Snitzer [this message]
2018-11-02 4:31 ` AliOS system security
2018-11-02 16:11 ` Mike Snitzer
2018-11-02 7:36 ` Milan Broz
2018-11-03 3:53 ` [PATCH] " AliOS system security
2018-11-04 13:39 ` Milan Broz
2018-11-05 7:31 ` [PATCH v2] dm crypt: use u64 " AliOS system security
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=20181101200642.GA29073@redhat.com \
--to=snitzer@redhat.com \
--cc=agk@redhat.com \
--cc=alios_sys_security@linux.alibaba.com \
--cc=dm-devel@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.