All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cornelia Huck <cohuck@redhat.com>
To: Stefan Haberland <sth@linux.ibm.com>
Cc: axboe@kernel.dk, linux-block@vger.kernel.org,
	hoeppner@linux.ibm.com, linux-s390@vger.kernel.org,
	heiko.carstens@de.ibm.com, gor@linux.ibm.com,
	borntraeger@de.ibm.com, vneethv@linux.ibm.com
Subject: Re: [PATCH 02/10] s390/cio: Provide Endpoint-Security Mode per CU
Date: Wed, 7 Oct 2020 18:13:57 +0200	[thread overview]
Message-ID: <20201007181357.7550dcb1.cohuck@redhat.com> (raw)
In-Reply-To: <3b721a6b-202e-d7e4-d4f2-2a3954f74609@linux.ibm.com>

On Wed, 7 Oct 2020 16:24:06 +0200
Stefan Haberland <sth@linux.ibm.com> wrote:

> Am 06.10.20 um 16:46 schrieb Cornelia Huck:
> > On Fri,  2 Oct 2020 21:39:32 +0200
> > Stefan Haberland <sth@linux.ibm.com> wrote:
> >  
> >> From: Vineeth Vijayan <vneethv@linux.ibm.com>
> >>
> >> Add an interface in the CIO layer to retrieve the information about the
> >> Endpoint-Security Mode (ESM) of the specified CU. The ESM values are
> >> defined as 0-None, 1-Authenticated or 2, 3-Encrypted.
> >>
> >> Reference-ID: IO1812
> >> Signed-off-by: Sebastian Ott <sebott@linux.ibm.com>
> >> [vneethv@linux.ibm.com: cleaned-up and modified description]
> >> Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
> >> Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
> >> Acked-by: Vasily Gorbik <gor@linux.ibm.com>
> >> Signed-off-by: Stefan Haberland <sth@linux.ibm.com>
> >> ---
> >>  arch/s390/include/asm/cio.h |  1 +
> >>  drivers/s390/cio/chsc.c     | 83 +++++++++++++++++++++++++++++++++++++
> >>  2 files changed, 84 insertions(+)  
> >  
> > (...)
> >  
> >> +/**
> >> + * chsc_scud() - Store control-unit description.
> >> + * @cu:		number of the control-unit
> >> + * @esm:	8 1-byte endpoint security mode values
> >> + * @esm_valid:	validity mask for @esm
> >> + *
> >> + * Interface to retrieve information about the endpoint security
> >> + * modes for up to 8 paths of a control unit.
> >> + *
> >> + * Returns 0 on success.
> >> + */
> >> +int chsc_scud(u16 cu, u64 *esm, u8 *esm_valid)
> >> +{
> >> +	struct chsc_scud *scud = chsc_page;
> >> +	int ret;
> >> +  
> > I'm wondering if it would make sense to check in the chsc
> > characteristics whether that chsc is actually installed (if there's
> > actually a bit for it, although I'd expect so). Some existing chscs
> > check for bits in the characteristics, others don't. (Don't know
> > whether QEMU is the only platform that doesn't provide this chsc.)  
> 
> I don't see any benefit in checking upfront if the CHSC is supported -
> we'll get
> a corresponding CHSC response code and since no error message is logged
> for this
> case, the outcome would be the same as if we checked for the
> characteristics bit
> beforehand.

Yes, that's probably fine, then.

> 
> 
> >> +	spin_lock_irq(&chsc_page_lock);
> >> +	memset(chsc_page, 0, PAGE_SIZE);
> >> +	scud->request.length = SCUD_REQ_LEN;
> >> +	scud->request.code = SCUD_REQ_CMD;
> >> +	scud->fmt = 0;
> >> +	scud->cssid = 0;
> >> +	scud->first_cu = cu;
> >> +	scud->last_cu = cu;
> >> +
> >> +	ret = chsc(scud);
> >> +	if (!ret)
> >> +		ret = chsc_error_from_response(scud->response.code);
> >> +
> >> +	if (!ret && (scud->response.length <= 8 || scud->fmt_resp != 0
> >> +			|| !(scud->cudb[0].flags & 0x80)
> >> +			|| scud->cudb[0].cu != cu)) {
> >> +
> >> +		CIO_MSG_EVENT(2, "chsc: scud failed rc=%04x, L2=%04x "
> >> +			"FMT=%04x, cudb.flags=%02x, cudb.cu=%04x",
> >> +			scud->response.code, scud->response.length,
> >> +			scud->fmt_resp, scud->cudb[0].flags, scud->cudb[0].cu);
> >> +		ret = -EINVAL;
> >> +	}
> >> +
> >> +	if (ret)
> >> +		goto out;
> >> +
> >> +	memcpy(esm, scud->cudb[0].esm, sizeof(*esm));
> >> +	*esm_valid = scud->cudb[0].esm_valid;
> >> +out:
> >> +	spin_unlock_irq(&chsc_page_lock);
> >> +	return ret;
> >> +}
> >> +EXPORT_SYMBOL_GPL(chsc_scud);  
> 

FWIW,
Acked-by: Cornelia Huck <cohuck@redhat.com>


  reply	other threads:[~2020-10-07 16:14 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-02 19:39 [PATCH 00/10] DASD FC endpoint security Stefan Haberland
2020-10-02 19:39 ` [PATCH 01/10] s390/cio: Export information about Endpoint-Security Capability Stefan Haberland
2020-10-06  9:46   ` Cornelia Huck
2020-10-06 14:23     ` Stefan Haberland
2020-10-06 14:37       ` Cornelia Huck
2020-10-02 19:39 ` [PATCH 02/10] s390/cio: Provide Endpoint-Security Mode per CU Stefan Haberland
2020-10-06 14:46   ` Cornelia Huck
2020-10-07 14:24     ` Stefan Haberland
2020-10-07 16:13       ` Cornelia Huck [this message]
2020-10-02 19:39 ` [PATCH 03/10] s390/cio: Add support for FCES status notification Stefan Haberland
2020-10-02 19:39 ` [PATCH 04/10] s390/dasd: Remove unused parameter from dasd_generic_probe() Stefan Haberland
2020-10-02 19:39 ` [PATCH 05/10] s390/dasd: Move duplicate code to separate function Stefan Haberland
2020-10-02 19:39 ` [PATCH 06/10] s390/dasd: Store path configuration data during path handling Stefan Haberland
2020-10-02 19:39 ` [PATCH 07/10] s390/dasd: Fix operational path inconsistency Stefan Haberland
2020-10-02 19:39 ` [PATCH 08/10] s390/dasd: Display FC Endpoint Security information via sysfs Stefan Haberland
2020-10-06 10:26   ` Cornelia Huck
2020-10-06 16:57     ` Jan Höppner
2020-10-07  9:49       ` Cornelia Huck
2020-10-07 14:33         ` Jan Höppner
2020-10-07 16:40           ` Cornelia Huck
2020-10-07 20:10             ` Jan Höppner
2020-10-08  7:03               ` Cornelia Huck
2020-10-08 11:04                 ` Stefan Haberland
2020-10-02 19:39 ` [PATCH 09/10] s390/dasd: Prepare for additional path event handling Stefan Haberland
2020-10-02 19:39 ` [PATCH 10/10] s390/dasd: Process FCES path event notification Stefan Haberland

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=20201007181357.7550dcb1.cohuck@redhat.com \
    --to=cohuck@redhat.com \
    --cc=axboe@kernel.dk \
    --cc=borntraeger@de.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=hoeppner@linux.ibm.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=sth@linux.ibm.com \
    --cc=vneethv@linux.ibm.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.