lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 21 Aug 2018 17:53:09 +0200
From:   Cornelia Huck <>
To:     Harald Freudenberger <>
Cc:     Tony Krowiak <>,,,,,,,,,,,,,,,,,,,,,, Tony Krowiak <>
Subject: Re: [PATCH v9 22/22] s390: doc: detailed specifications for AP

On Tue, 21 Aug 2018 11:00:00 +0200
Harald Freudenberger <> wrote:

> On 20.08.2018 18:03, Cornelia Huck wrote:
> > On Mon, 13 Aug 2018 17:48:19 -0400
> > Tony Krowiak <> wrote:

> >> +* AP Instructions:
> >> +
> >> +  There are three AP instructions:
> >> +
> >> +  * NQAP: to enqueue an AP command-request message to a queue
> >> +  * DQAP: to dequeue an AP command-reply message from a queue
> >> +  * PQAP: to administer the queues  
> > So, NQAP/DQAP need usage domains, while PQAP needs a control domain? Or
> > is it that all of them need usage domains, but PQAP can target a control
> > domain as well?
> >
> > [I don't want to dive deeply into the AP architecture here, just far
> > enough to really understand the design implications.]  
> Well, to be honest, nobody ever tried this under Linux. Theoretically
> one should be able to send a CPRB to a usage domain where inside
> the CPRB another domain (the control domain) is addressed. However,
> as of now I am only aware of applications controlling the same usage
> domain. I don't know any application which is able to address another
> control domain and I am not sure if the zcrypt device driver would
> handle such a CPRB correctly. NQAP, DQAP and PQAP always address
> a usage domain. But the CPRB send down the pipe via NQAP may
> address some control thing on another domain. I am not sure which
> code and where do the sorting out here. There are two candidates:
> the firmware layer in the CEC and the crypto card code.

OK, so it's possible as by the architecture, but at least Linux does
not (currently) do it?

Perhaps we should simply not overthink that whole control domain
thingy :) It's mostly yet another knob, and as long as the design does
not go against the general architecture, it's probably fine, I guess.

Powered by blists - more mailing lists