<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/s390/crypto/ap_queue.c, branch v6.6.133</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.6.133</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.6.133'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2023-11-20T10:59:28+00:00</updated>
<entry>
<title>s390/ap: re-init AP queues on config on</title>
<updated>2023-11-20T10:59:28+00:00</updated>
<author>
<name>Harald Freudenberger</name>
<email>freude@linux.ibm.com</email>
</author>
<published>2023-09-12T07:54:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a03b8ab0291e3c14a2b21b3c6c9af29f143e76c5'/>
<id>urn:sha1:a03b8ab0291e3c14a2b21b3c6c9af29f143e76c5</id>
<content type='text'>
[ Upstream commit 32d1d9204f8db3360be55e65bd182a1a68f93308 ]

On a state toggle from config off to config on and on the
state toggle from checkstop to not checkstop the queue's
internal states was set but the state machine was not
nudged. This did not care as on the first enqueue of a
request the state machine kick ran.

However, within an Secure Execution guest a queue is
only chosen by the scheduler when it has been bound.
But to bind a queue, it needs to run through the initial
states (reset, enable interrupts, ...). So this is like
a chicken-and-egg problem and the result was in fact
that a queue was unusable after a config off/on toggle.

With some slight rework of the handling of these states
now the new function _ap_queue_init_state() is called
which is the core of the ap_queue_init_state() function
but without locking handling. This has the benefit that
it can be called on all the places where a (re-)init
of the AP queue's state machine is needed.

Fixes: 2d72eaf036d2 ("s390/ap: implement SE AP bind, unbind and associate")
Signed-off-by: Harald Freudenberger &lt;freude@linux.ibm.com&gt;
Reviewed-by: Holger Dengler &lt;dengler@linux.ibm.com&gt;
Signed-off-by: Vasily Gorbik &lt;gor@linux.ibm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>s390/zcrypt: remove CEX2 and CEX3 device drivers</title>
<updated>2023-07-24T10:12:22+00:00</updated>
<author>
<name>Harald Freudenberger</name>
<email>freude@linux.ibm.com</email>
</author>
<published>2023-06-28T10:36:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5ac8c72462cdad56e37981eb2172c5baa1ea40d6'/>
<id>urn:sha1:5ac8c72462cdad56e37981eb2172c5baa1ea40d6</id>
<content type='text'>
Remove the legacy device driver code for CEX2 and CEX3 cards.

The last machines which are able to handle CEX2 crypto cards
are z10 EC first available 2008 and z10 BC first available 2009.
The last machines able to handle a CEX3 crypto card are
z196 first available 2010 and z114 first available 2011.

Please note that this does not imply to drop CEX2 and CEX3
support in general. With older kernels on hardware up to the
aforementioned machine models these crypto cards will get
support by IBM.

The removal of the CEX2 and CEX3 device drivers code opens up
some simplifications, for example support for crypto cards
without rng support can be removed also.

Signed-off-by: Harald Freudenberger &lt;freude@linux.ibm.com&gt;
Acked-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
Signed-off-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>s390/zcrypt: cleanup some debug code</title>
<updated>2023-07-03T09:19:41+00:00</updated>
<author>
<name>Harald Freudenberger</name>
<email>freude@linux.ibm.com</email>
</author>
<published>2023-06-19T14:55:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0fdcc88bb93f8200386d5d3015115b747d3391ae'/>
<id>urn:sha1:0fdcc88bb93f8200386d5d3015115b747d3391ae</id>
<content type='text'>
This patch removes most of the debug code which
is build in when CONFIG_ZCRYPT_DEBUG is enabled.
There is no real exploiter for this code any more and
at least one ioctl fails with this code enabled.

The CONFIG_ZCRYPT_DEBUG kernel config option still
makes sense as some debug sysfs entries can get
enabled with this and maybe long term a new better
designed debug and error injection way will get
introduced.

This patch only removes code surrounded by the named
kernel config option. This option should by default
always be off anyway. The structs and defines removed
by the patch have been used only by code surrounded
by a CONFIG_ZCRYPT_DEBUG ifdef and thus can be removed
also.

In the end this patch removes all the failure-injection
possibilities which had been available when the kernel
had been build with CONFIG_ZCRYPT_DEBUG. It has never
been used that much and was too unflexible anyway.

Signed-off-by: Harald Freudenberger &lt;freude@linux.ibm.com&gt;
Reviewed-by: Holger Dengler &lt;dengler@linux.ibm.com&gt;
Signed-off-by: Alexander Gordeev &lt;agordeev@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>s390/ap: add ap status asynch error support</title>
<updated>2023-03-20T10:12:49+00:00</updated>
<author>
<name>Harald Freudenberger</name>
<email>freude@linux.ibm.com</email>
</author>
<published>2023-02-15T14:08:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=038c5bedbc313b55f66b26fda5a7808727c2f177'/>
<id>urn:sha1:038c5bedbc313b55f66b26fda5a7808727c2f177</id>
<content type='text'>
Review and extend the low level AP code to be able to
deal with asynchronous reported errors on APQNs.

The hypervisor and the SE guest may be confronted with
an asynchronously reported error at return of an AP
instruction. So all places where AP instructions are
called need review and may eventually need extensions.
However, not all places need rework. As together with
the AP status and the enabled asynch bit there is always
a response code set. The asynch error reporting comes
with new response codes which may be simple handled in
the default case of a switch statement.

The idea behind this patch is to report asynch errors
as -EPERM (read this as "Operation not permitted") which
reflects the fact that only a rapq (with F bit enabled)
is a valid AP instruction when an asynch error is flagged.

The AP queue state machine functions return
AP_SM_WAIT_NONE when a asynch error is detected to reflect
the fact, that the state machine can't do anything with
such an error as long as the queue is reset.

Unfortunately the ap bus scan function needed some
update as the ap_queue_info() now needs to return
3 states: 1 if an APQN exists and info is available,
-1 if it is assumed an APQN does not exist and the new
return value 0 without any info values filled. This 0
returncode is handled as "there is an APQN but we currently
don't know any more hw info about this, so please use
your previous info and try again later".

Signed-off-by: Harald Freudenberger &lt;freude@linux.ibm.com&gt;
Reviewed-by: Holger Dengler &lt;dengler@linux.ibm.com&gt;
Signed-off-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>s390/ap: implement SE AP bind, unbind and associate</title>
<updated>2023-03-20T10:12:49+00:00</updated>
<author>
<name>Harald Freudenberger</name>
<email>freude@linux.ibm.com</email>
</author>
<published>2023-03-10T16:46:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2d72eaf036d2f2b7ec16cda2d0e7ce292537dad9'/>
<id>urn:sha1:2d72eaf036d2f2b7ec16cda2d0e7ce292537dad9</id>
<content type='text'>
Implementation of the new functions for SE AP support:
bind, unbind and associate. There are two new sysfs
attributes for this:

/sys/devices/ap/cardxx/xx.yyyy/se_bind
/sys/devices/ap/cardxx/xx.yyyy/se_associate

Writing a 1 into the se_bind attribute triggers the
SE AP bind for this AP queue, writing a 0 into does
an unbind - that's a reset (RAPQ) with the F bit enabled.

The se_associate attribute needs an integer value in
range 0...2^16-1 written in. This is the index into a
secrets table feed into the ultravisor. For more details
please see the Architecture documents.

These both new ap queue attributes are only visible
inside a SE guest with SB (Secure Binding) available.

Signed-off-by: Harald Freudenberger &lt;freude@linux.ibm.com&gt;
Reviewed-by: Holger Dengler &lt;dengler@linux.ibm.com&gt;
Signed-off-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>s390/ap: introduce low frequency polling possibility</title>
<updated>2023-03-20T10:12:49+00:00</updated>
<author>
<name>Harald Freudenberger</name>
<email>freude@linux.ibm.com</email>
</author>
<published>2022-10-21T13:41:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=263c8454dbffd4b878ea9bb403e157a56de98aca'/>
<id>urn:sha1:263c8454dbffd4b878ea9bb403e157a56de98aca</id>
<content type='text'>
For some events the ap bus needs to poll. For example
when an AP queue is reset until the reset is through.
Also when no interrupt support is available (e.g. zVM)
there is a need to poll until all requests have been
processed and all replies have been delivered.

Polling is done with a high resolution timer by default
run with a rate of 4kHz (LPAR) or 666Hz (zVM guest).

For some events (wait for reset complete, wait for irq
enabled complete) this is a much too high poll rate
which triggers a lot of TAPQ invocations.

This patch introduces the possibility for the state
machine functions to return a new wait enum
AP_SM_WAIT_LOW_TIMEOUT which gives a hint to the
ap_wait() function to eventually set up the timer
with a more relaxed timeout value of 25Hz.

This patch also includes a slight rework of the sysfs
functions parsing the timer related stuff: Use of
kstrtobool and kstrtoul instead of sscanf.

Signed-off-by: Harald Freudenberger &lt;freude@linux.ibm.com&gt;
Reviewed-by: Holger Dengler &lt;dengler@linux.ibm.com&gt;
Signed-off-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>s390/ap: provide F bit parameter for ap_rapq() and ap_zapq()</title>
<updated>2023-03-20T10:12:49+00:00</updated>
<author>
<name>Harald Freudenberger</name>
<email>freude@linux.ibm.com</email>
</author>
<published>2022-09-07T16:04:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4bdf3c3956d863b6823daa185ee3ce3e3a432cf3'/>
<id>urn:sha1:4bdf3c3956d863b6823daa185ee3ce3e3a432cf3</id>
<content type='text'>
Extent the ap inline functions ap_rapq() (calls PQAP(RAPQ))
and ap_zapq() (calls PQAP(ZAPQ)) with a new parameter to
enable the new architectured F bit which forces an
unassociate and/or unbind on a secure execution associated
and/or bound queue.

Signed-off-by: Harald Freudenberger &lt;freude@linux.ibm.com&gt;
Reviewed-by: Tony Krowiak &lt;akrowiak@linux.ibm.com&gt;
Reviewed-by: Holger Dengler &lt;dengler@linux.ibm.com&gt;
Signed-off-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>s390/ap: filter ap card functions, new queue functions attribute</title>
<updated>2023-03-20T10:12:48+00:00</updated>
<author>
<name>Harald Freudenberger</name>
<email>freude@linux.ibm.com</email>
</author>
<published>2022-09-07T15:25:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=088174960ebc197fab8af9b99e039bc5c0aa34e7'/>
<id>urn:sha1:088174960ebc197fab8af9b99e039bc5c0aa34e7</id>
<content type='text'>
With SE SB (Secure Binding) some currently unused and thus always
zero bits in the TAPQ GR2 result are now used to show the binding
state of a queue. So to check if a card has changed the comparing
base is exactly this GR2 value shown as 'ap_function' in sysfs
(/sys/devices/ap/cardxx/ap_functions). Now there is some queue
specific info in this info and so a new mask TAPQ_CARD_FUNC_CMP_MASK
is used to filter out only the relevant bits for card compare.

For the same reason now the function bits (including exactly this
bind/associate information) need to be exposed to user space now.
So tools like lszcrypt can evaluate binding/association state on a
queue base. So here comes a new sysfs attribute

  /sys/devices/ap/cardxx/xx.yyyy/ap_functions

This sysfs attribute is similar to the already existing
ap_functions attribute at ap card level. It shows the
upper 32 bits of GR2 from an invocation of TAPQ for this
AP queue.

Signed-off-by: Harald Freudenberger &lt;freude@linux.ibm.com&gt;
Reviewed-by: Holger Dengler &lt;dengler@linux.ibm.com&gt;
Signed-off-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>s390/zcrypt: replace scnprintf with sysfs_emit</title>
<updated>2023-03-20T10:12:48+00:00</updated>
<author>
<name>Harald Freudenberger</name>
<email>freude@linux.ibm.com</email>
</author>
<published>2023-02-06T09:53:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=964d581daf46a1e65af220786104c6db88f833aa'/>
<id>urn:sha1:964d581daf46a1e65af220786104c6db88f833aa</id>
<content type='text'>
Replace scnprintf() with sysfs_emit() and friends
where possible.

Signed-off-by: Harald Freudenberger &lt;freude@linux.ibm.com&gt;
Reviewed-by: Holger Dengler &lt;dengler@linux.ibm.com&gt;
Reviewed-by: Tony Krowiak &lt;akrowiak@linux.ibm.com&gt;
Signed-off-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>s390/zcrypt: rework length information for dqap</title>
<updated>2023-03-20T10:12:47+00:00</updated>
<author>
<name>Harald Freudenberger</name>
<email>freude@linux.ibm.com</email>
</author>
<published>2023-02-14T16:13:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8794c5961394b7fb8a69f43eaad9566e5496c0c8'/>
<id>urn:sha1:8794c5961394b7fb8a69f43eaad9566e5496c0c8</id>
<content type='text'>
The inline ap_dqap function does not return the number of
bytes actually written into the message buffer. The calling
code inspects the AP message header to figure out what kind
of AP message has been received and pulls the length
information from this header. This processing may not work
correctly in cases where only a fragment of the reply is
received.

With this patch the ap_dqap inline function now returns
the number of actually written bytes in the *length parameter.
So the calling function has a chance to compare the number of
received bytes against what the AP message header length
field states. This is especially useful in cases where a
message could only get partially received.

The low level reply processing functions needed some rework
to be able to catch this new length information and compare
it the right way. The rework also deals with some situations
where until now the reply length was not correctly calculated
and/or set.

All this has been heavily tested as the modifications on
the reply length information may affect crypto load.

Signed-off-by: Harald Freudenberger &lt;freude@linux.ibm.com&gt;
Reviewed-by: Holger Dengler &lt;dengler@linux.ibm.com&gt;
Signed-off-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
</content>
</entry>
</feed>
