mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: David Howells <dhowells@redhat.com>
To: mtk.manpages@gmail.com
Cc: dhowells@redhat.com, Michael Kerrisk <mtk@man7.org>,
	lkml <linux-kernel@vger.kernel.org>,
	Eugene Syromyatnikov <evgsyr@gmail.com>,
	keyrings@vger.kernel.org, linux-man <linux-man@vger.kernel.org>
Subject: Re: Revised keyrings(7) man page for review
Date: Tue, 13 Dec 2016 13:38:16 +0000	[thread overview]
Message-ID: <26913.1481636296@warthog.procyon.org.uk> (raw)
In-Reply-To: <CAKgNAkh9JLN4P+Fu+yRCNo96E3VwjYLRquuaf43XRWeuC7gnNw@mail.gmail.com>

Michael Kerrisk (man-pages) <mtk.manpages@gmail.com> wrote:

> So, I've updated this piece a couple of times since the draft that you
> reviewed, and by now it reads:
> 
>        "big_key" (since Linux 3.13)
>               This key type is similar to the "user" key type, but it may
>               hold  a  payload  of up to 1 MiB in size.  This key type is
>               useful for tasks such as holding Kerberos ticket caches.

I'm not sure that "tasks" is quite the word I'd use here (it's overloaded).
Perhaps "purposes"?

>               The payload data may be stored in  the  swap  space  rather
>               than in kernel memory if the data size exceeds the overhead
>               of storing the data encrypted in swap space.  (A tmpfs file
>               is  used,  which requires filesystem structures to be allo‐
>               cated in the kernel; The size of  these  structures  deter‐
>               mines  the  size  threshold  above  which the tmpfs storage
>               method  is  used.)   Since  Linux  4.8,  payload  data   is
>               encrypted,  to  prevent  it  being written unencrypted into
>               swap space.

I would either drop the first "encrypted" ("storing the data encrypted") since
you mention this later or move it earlier to be after the word "stored" ("may
be stored encrypted").

Note that with the "Since Linux 4.8 ..." sentence, the encryption is only
applied if it is stored into tmpfs.

Also, the payload isn't directly stored into swapspace, but is rather stored
into tmpfs, from where it can be swapped.  This is important since you can use
this type of key without any swapspace available to your system.

David

  parent reply	other threads:[~2016-12-13 13:38 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-04 15:47 Michael Kerrisk
2016-11-26 12:51 ` Michael Kerrisk (man-pages)
2016-12-13 11:35 ` David Howells
2016-12-13 12:43   ` Michael Kerrisk (man-pages)
2016-12-13 12:57     ` Michael Kerrisk (man-pages)
2016-12-13 13:38     ` David Howells [this message]
2016-12-13 13:52       ` Michael Kerrisk (man-pages)
2016-12-13 14:20       ` David Howells
2016-12-14  7:27         ` Michael Kerrisk (man-pages)
2016-12-13 13:31   ` David Howells
2016-12-13 13:41     ` Michael Kerrisk (man-pages)

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=26913.1481636296@warthog.procyon.org.uk \
    --to=dhowells@redhat.com \
    --cc=evgsyr@gmail.com \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-man@vger.kernel.org \
    --cc=mtk.manpages@gmail.com \
    --cc=mtk@man7.org \
    /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

Powered by JetHome