From patchwork Wed Jan 22 15:13:48 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ryan Grimm X-Patchwork-Id: 1227324 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 482prl6Dpsz9sR1 for ; Thu, 23 Jan 2020 02:16:07 +1100 (AEDT) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=linux.ibm.com Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 482prk3LrmzDqPR for ; Thu, 23 Jan 2020 02:16:06 +1100 (AEDT) X-Original-To: skiboot@lists.ozlabs.org Delivered-To: skiboot@lists.ozlabs.org Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=linux.ibm.com (client-ip=148.163.158.5; helo=mx0b-001b2d01.pphosted.com; envelope-from=grimm@linux.ibm.com; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=linux.ibm.com Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 482prZ46jtzDqSq for ; Thu, 23 Jan 2020 02:15:58 +1100 (AEDT) Received: from pps.filterd (m0127361.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 00MFCsx9045450 for ; Wed, 22 Jan 2020 10:15:55 -0500 Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 2xkwq92wxe-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 22 Jan 2020 10:15:54 -0500 Received: from m0127361.ppops.net (m0127361.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.36/8.16.0.36) with SMTP id 00MFD6wH046029 for ; Wed, 22 Jan 2020 10:15:06 -0500 Received: from ppma02wdc.us.ibm.com (aa.5b.37a9.ip4.static.sl-reverse.com [169.55.91.170]) by mx0a-001b2d01.pphosted.com with ESMTP id 2xkwq92w65-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 22 Jan 2020 10:15:06 -0500 Received: from pps.filterd (ppma02wdc.us.ibm.com [127.0.0.1]) by ppma02wdc.us.ibm.com (8.16.0.27/8.16.0.27) with SMTP id 00MF9pxk025965; Wed, 22 Jan 2020 15:14:19 GMT Received: from b03cxnp07028.gho.boulder.ibm.com (b03cxnp07028.gho.boulder.ibm.com [9.17.130.15]) by ppma02wdc.us.ibm.com with ESMTP id 2xksn6p3x4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 22 Jan 2020 15:14:19 +0000 Received: from b03ledav005.gho.boulder.ibm.com (b03ledav005.gho.boulder.ibm.com [9.17.130.236]) by b03cxnp07028.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 00MFEHlL44499334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 22 Jan 2020 15:14:17 GMT Received: from b03ledav005.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0CF73BE04F; Wed, 22 Jan 2020 15:14:17 +0000 (GMT) Received: from b03ledav005.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 028FEBE051; Wed, 22 Jan 2020 15:14:15 +0000 (GMT) Received: from alain.ibm.com (unknown [9.85.182.18]) by b03ledav005.gho.boulder.ibm.com (Postfix) with ESMTP; Wed, 22 Jan 2020 15:14:15 +0000 (GMT) From: Ryan Grimm To: oohall@gmail.com Date: Wed, 22 Jan 2020 10:13:48 -0500 Message-Id: <20200122151354.23683-1-grimm@linux.ibm.com> X-Mailer: git-send-email 2.21.0 MIME-Version: 1.0 X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-17_05:2020-01-16, 2020-01-17 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 malwarescore=0 suspectscore=3 phishscore=0 adultscore=0 priorityscore=1501 mlxscore=0 lowpriorityscore=0 mlxlogscore=999 impostorscore=0 spamscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-2001220136 Subject: [Skiboot] [RFC PATCH v3 0/6] Ultravisor support in skiboot X-BeenThere: skiboot@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mailing list for skiboot development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: janani@us.ibm.com, suka@us.ibm.com, skiboot@lists.ozlabs.org Errors-To: skiboot-bounces+incoming=patchwork.ozlabs.org@lists.ozlabs.org Sender: "Skiboot" Oliver, You commented on the patches back in mid-November, so I'll summarize what I did here instead of replying to those threads. 1) Ditch abuse of reserves and create secure-memory@ device tree nodes. Example: secure-memory@100fe00000000 { device_type = "secure_memory"; compatible = "ibm,secure_memory"; ibm,chip-id = <0>; reg = < 0x100fe 0x0 0x2 0x0>; } This was discussed in the previous thread and is described in doc/opal-uv-api.rst. These nodes are created from HDAT on hostboot. Mambo's tcl and BML's python creates them. 2) Fix up device tree node to include unit address, address and size cells, tested with dtc and no warning or errors given. Example: ibm,ultravisor { compatible = "ibm,ultravisor"; #address-cells = <0x02>; #size-cells = <0x01>; firmware@200000000 { compatible = "ibm,uv-firmware"; reg = <0x02 0x00 0xf677f>; memcons = <0x00 0x3022d030>; sys-fdt = <0x00 0x30509068>; uv-fdt = <0x02 0x200000>; }; }; I included the values for memory console, system device tree, and uv device tree, which are consumed by the ultravisor. These are also in uv-opal struct. If we want to get rid of the uv-opal struct, the two problems are the ultravisor inits its console early on, so it needs the memcons address. Also, it needs to pointer to the system device tree. Here it is: struct uv_opal { __be32 magic; /**< 'OPUV' 0x4F505556 OPUV_MAGIC */ __be32 version; /**< uv_opal struct version */ __be32 uv_api_ver; /**< Current uv api version. */ __be64 uv_base_addr; /**< Base address of UV in secure memory. */ __be64 sys_fdt; /**< System FDT. */ __be64 uv_fdt; /**< UV FDT in secure memory. */ __be64 uv_mem; /**< struct memcons */ }; uv_base_addr: We don't need it, Skiboot could keep track of it without sharing with ultravisor uv_fdt: could be gotten from system fdt for memcons addr and system fdt pointer, could we pass these via registers and get everything else from system fdt? 3) Fix up doc XSCOM description. Include finer-grained return codes. 4) Ditch OCC whack-a-mole patch. I included it b/c I thought it was useful but, now we have stop state support in our internal tree, and I will include those in v4. 5) Make Mambo and BML behave the same way. If you look at init_uv, we now have an if statement with the HB path and the Mambo/BML path. Mambo and BML both provide secure-memory nodes and skiboot copies the UV from regular to secure memory. I think the code is simpler and more straightforward this way. Previously, we had a special case for HB, Mambo and BML. 6) use local_alloc for structures. If things fail, attempt to free and provide a local_free function in core/mem_region.c 7) Make unit tests work. "make check" now works. 8) Make sure this runs with MSR_S = 0. Tested in Mambo and we get some messages in the skiboot log: [ 0.002768226,7] UV: Init starting^M [ 0.002772055,7] UV: S bit not set^M and later [ 0.008892631,7] UV: No ibm,ultravisor found, won't start ultravisor 9) Reserve the uv firmware in Mambo and BML. Tcl and python can do this, so we don't need anything in skiboot. 10) Don't check msr bit in xscom_read/write >> +static inline bool can_access_xscom(void) >> +{ >> + return (is_msr_bit_set(MSR_S) || !is_uv_present()); >I'd prefer we didn't open-code MSR checks since it makes testing >awkward. Check if we can do XSCOMs directly in xscom_init() and clear >that flag after we've started the UV. We can always do xscoms directly before uv_init, and bit 15 is set in the xscom address given by hostboot. It's also set in Cronus as well. Bit 15 indicates the XSCOM is "secure". So, I changed the code to just check the uv_present flag in xscom read/write. We don't need to look at MSR at all. 11) General cleanups and improving of code. Number of lines reduced by 18%. I included stubs for the wrapping key and tpm_nv_init b/c we have those working internally but they are dependent on the tss code, which is large, and AFAIK is currently being upstreamed. TODOs for v4: -include OCC patches. -deal with start_ultravisor, it's awkward in that it's load_and_boot_kernel. -define what recovery means Thanks, -Ryan Claudio Carvalho (1): libstb/trustedboot: Map UV image measurement to PCR4 Madhavan Srinivasan (3): Add memcons support for ultravisor xscoms: read/write xscoms using ucall skiboot/imc: Disable IMC node when UV enabled Ryan Grimm (2): doc/opal-uv-api.rst Add ultravisor support in OPAL asm/head.S | 54 +++++ core/flash.c | 1 + core/init.c | 11 + core/mem_region.c | 32 +++ doc/opal-uv-api.rst | 441 ++++++++++++++++++++++++++++++++++++ hdata/memory.c | 23 +- hdata/test/hdata_to_dt.c | 1 + hw/Makefile.inc | 1 + hw/fsp/fsp.c | 2 + hw/imc.c | 11 + hw/ultravisor.c | 413 +++++++++++++++++++++++++++++++++ include/console.h | 3 + include/debug_descriptor.h | 1 + include/mem-map.h | 16 +- include/mem_region-malloc.h | 3 + include/platform.h | 1 + include/processor.h | 12 + include/ultravisor-api.h | 19 ++ include/ultravisor.h | 49 ++++ include/xscom.h | 11 +- libstb/trustedboot.c | 1 + 21 files changed, 1092 insertions(+), 14 deletions(-) create mode 100644 doc/opal-uv-api.rst create mode 100644 hw/ultravisor.c create mode 100644 include/ultravisor-api.h create mode 100644 include/ultravisor.h