Re: [PATCH v6 00/14] x86: Trenchboot secure dynamic launch Linux kernel support
On Thu, May 04, 2023 at 02:50:09PM +, Ross Philipson wrote: > This patchset provides detailed documentation of DRTM, the approach used for > adding the capbility, and relevant API/ABI documentation. In addition to the > documentation the patch set introduces Intel TXT support as the first platform > for Linux Secure Launch. I'd like to apply this series, but on what commit it is based on? I don't see any branch containing this series version in trenchboot tree [1]. Thanks. [1]: https://github.com/TrenchBoot/linux -- An old man doll... just what I always wanted! - Clara signature.asc Description: PGP signature ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v6 02/14] Documentation/x86: Secure Launch kernel documentation
prepare the CPU and the TPM for the launch. > + - The secure launch is then initiated with the GETSET[SENTER] instruction. > + > +Post-launch: *Phase where control is passed from the ACM to the MLE and the > secure > +kernel begins execution.* > + > + - Entry from the dynamic launch jumps to the SL stub. > + - SL stub fixes up the world on the BSP. > + - For TXT, SL stub wakes the APs, fixes up their worlds. > + - For TXT, APs are left halted waiting for an NMI to wake them. > + - SL stub jumps to startup_32. > + - SL main does validation of buffers and memory locations. It sets > + the boot parameter loadflag value SLAUNCH_FLAG to inform the main > + kernel that
Re: [PATCH v6 00/14] x86: Trenchboot secure dynamic launch Linux kernel support
On 5/5/23 22:45, Ross Philipson wrote: > Sorry about that. In the future I will include a base-commit field. It is > based off of torvolds/master as of 5/1/2023. The branch where the patches > came from is now pushed to the TrenchBoot repository here: > > https://github.com/TrenchBoot/linux/tree/linux-sl-master-5-1-23-v6 > Pulled, thanks! -- An old man doll... just what I always wanted! - Clara ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v5 3/3] kexec: Introduce sysctl parameters kexec_load_limit_*
On Wed, Dec 21, 2022 at 08:45:59PM +0100, Ricardo Ribalda wrote: > += = > +-1 Unlimited calls to kexec. This is the default setting. > +N Number of calls left. > += = > + > +kexec_load_limit_reboot > +== > + You need to match the length of table borders and section underline: >8 diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst index a3922dffbd474b..a64b340c3ae509 100644 --- a/Documentation/admin-guide/sysctl/kernel.rst +++ b/Documentation/admin-guide/sysctl/kernel.rst @@ -469,13 +469,13 @@ This parameter specifies a limit to the number of times the syscalls image. It can only be set with a more restrictive value than the current one. -= = --1 Unlimited calls to kexec. This is the default setting. -N Number of calls left. -= = +== = +-1 Unlimited calls to kexec. This is the default setting. +N Number of calls left. +== = kexec_load_limit_reboot -== +=== Similar functionality as ``kexec_load_limit_panic``, but for a crash image. Thanks. -- An old man doll... just what I always wanted! - Clara signature.asc Description: PGP signature ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH V2 2/2] Documentation: kdump: describe VMCOREINFO export for RISCV64
On Fri, Oct 14, 2022 at 09:41:39PM +0800, Xianting Tian wrote: > The following interrelated definitions and ranges are needed by the kdump > crash tool, they are exported by "arch/riscv/kernel/crash_core.c": Better say "..., which are exported by ..." > diff --git a/Documentation/admin-guide/kdump/vmcoreinfo.rst > b/Documentation/admin-guide/kdump/vmcoreinfo.rst > index 6726f439958c..8e2e164cf3db 100644 > --- a/Documentation/admin-guide/kdump/vmcoreinfo.rst > +++ b/Documentation/admin-guide/kdump/vmcoreinfo.rst > @@ -595,3 +595,33 @@ X2TLB > - > > Indicates whether the crashed kernel enabled SH extended mode. > + > +RISCV64 > +=== > + > +VA_BITS > +--- > + > +The maximum number of bits for virtual addresses. Used to compute the > +virtual memory ranges. > + > +PAGE_OFFSET > +--- > + > +Indicates the virtual kernel start address of direct-mapped RAM region. > + > +phys_ram_base > +- > + > +Indicates the start physical RAM address. > + > +MODULES_VADDR|MODULES_END|VMALLOC_START|VMALLOC_END|VMEMMAP_START|VMEMMAP_END|KASAN_SHADOW_START|KASAN_SHADOW_END|KERNEL_LINK_ADDR|ADDRESS_SPACE_END > + > + > +Used to get the correct ranges: > + > + * MODULES_VADDR ~ MODULES_END : Kernel module space. > + * VMALLOC_START ~ VMALLOC_END : vmalloc() / ioremap() space. > + * VMEMMAP_START ~ VMEMMAP_END : vmemmap region, used for struct page array. > + * KASAN_SHADOW_START ~ KASAN_SHADOW_END : kasan shadow space. > + * KERNEL_LINK_ADDR ~ ADDRESS_SPACE_END : Kernel link and BPF space. The documentation LGTM, thanks. When the patch subject is fixed, Reviewed-by: Bagas Sanjaya -- An old man doll... just what I always wanted! - Clara signature.asc Description: PGP signature ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH V4 2/2] Documentation: kdump: describe VMCOREINFO export for RISCV64
On 10/19/22 17:36, Xianting Tian wrote: > The following interrelated definitions and ranges are needed by the kdump > crash tool, which are exported by "arch/riscv/kernel/crash_core.c": > VA_BITS, > PAGE_OFFSET, > phys_ram_base, > KERNEL_LINK_ADDR, > MODULES_VADDR ~ MODULES_END, > VMALLOC_START ~ VMALLOC_END, > VMEMMAP_START ~ VMEMMAP_END, > > Document these RISCV64 exports above. > > Signed-off-by: Xianting Tian Hi Xianting, Seems like you forgot to keep carrying my Reviewed-by from v3 [1]. Anyway, here it goes... Reviewed-by: Bagas Sanjaya Thanks. [1]: https://lore.kernel.org/linux-doc/20221018081755.6214-3-xianting.t...@linux.alibaba.com/ -- An old man doll... just what I always wanted! - Clara ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH V2 2/2] Documentation: kdump: describe VMCOREINFO export for RISCV64
On 10/18/22 13:06, Xianting Tian wrote: > > 在 2022/10/18 上午11:19, Bagas Sanjaya 写道: >> On Fri, Oct 14, 2022 at 09:41:39PM +0800, Xianting Tian wrote: >>> The following interrelated definitions and ranges are needed by the kdump >>> crash tool, they are exported by "arch/riscv/kernel/crash_core.c": >> Better say "..., which are exported by ..." >> >>> diff --git a/Documentation/admin-guide/kdump/vmcoreinfo.rst >>> b/Documentation/admin-guide/kdump/vmcoreinfo.rst >>> index 6726f439958c..8e2e164cf3db 100644 >>> --- a/Documentation/admin-guide/kdump/vmcoreinfo.rst >>> +++ b/Documentation/admin-guide/kdump/vmcoreinfo.rst >>> @@ -595,3 +595,33 @@ X2TLB >>> - >>> Indicates whether the crashed kernel enabled SH extended mode. >>> + >>> +RISCV64 >>> +=== >>> + >>> +VA_BITS >>> +--- >>> + >>> +The maximum number of bits for virtual addresses. Used to compute the >>> +virtual memory ranges. >>> + >>> +PAGE_OFFSET >>> +--- >>> + >>> +Indicates the virtual kernel start address of direct-mapped RAM region. >>> + >>> +phys_ram_base >>> +- >>> + >>> +Indicates the start physical RAM address. >>> + >>> +MODULES_VADDR|MODULES_END|VMALLOC_START|VMALLOC_END|VMEMMAP_START|VMEMMAP_END|KASAN_SHADOW_START|KASAN_SHADOW_END|KERNEL_LINK_ADDR|ADDRESS_SPACE_END >>> + >>> + >>> +Used to get the correct ranges: >>> + >>> + * MODULES_VADDR ~ MODULES_END : Kernel module space. >>> + * VMALLOC_START ~ VMALLOC_END : vmalloc() / ioremap() space. >>> + * VMEMMAP_START ~ VMEMMAP_END : vmemmap region, used for struct page >>> array. >>> + * KASAN_SHADOW_START ~ KASAN_SHADOW_END : kasan shadow space. >>> + * KERNEL_LINK_ADDR ~ ADDRESS_SPACE_END : Kernel link and BPF space. >> The documentation LGTM, thanks. >> >> When the patch subject is fixed, > Could you tell me what patch subject should be changed to ? thanks I mean the description, not subject (as in email). That is, fix the description (see above). The subject shouldn't be changed. Sorry for inconvenience. Thanks. -- An old man doll... just what I always wanted! - Clara ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 2/2] Documentation: kdump: describe VMCOREINFO export for RISCV64
On Fri, Oct 14, 2022 at 03:48:10PM +0800, Xianting Tian wrote: > The following interrelated definitions and ranges are needed by the kdump > crash tool, they are exported by "arch/riscv/kernel/crash_core.c": > VA_BITS, > PAGE_OFFSET, > phys_ram_base, > MODULES_VADDR ~ MODULES_END, > VMALLOC_START ~ VMALLOC_END, > VMEMMAP_START ~ VMEMMAP_END, > KASAN_SHADOW_START ~ KASAN_SHADOW_END, > KERNEL_LINK_ADDR ~ ADDRESS_SPACE_END > > Document these RISCV64 exports above. > The patch description LGTM, thanks. > + > +MODULES_VADDR|MODULES_END|VMALLOC_START|VMALLOC_END|VMEMMAP_START|VMEMMAP_END|KASAN_SHADOW_START|KASAN_SHADOW_END|KERNEL_LINK_ADDR|ADDRESS_SPACE_END > + The overline above header text is unnecessary, so I have to strip it: >8 diff --git a/Documentation/admin-guide/kdump/vmcoreinfo.rst b/Documentation/admin-guide/kdump/vmcoreinfo.rst index 6c7a1728de220e..8e2e164cf3db49 100644 --- a/Documentation/admin-guide/kdump/vmcoreinfo.rst +++ b/Documentation/admin-guide/kdump/vmcoreinfo.rst @@ -615,7 +615,6 @@ phys_ram_base Indicates the start physical RAM address. - MODULES_VADDR|MODULES_END|VMALLOC_START|VMALLOC_END|VMEMMAP_START|VMEMMAP_END|KASAN_SHADOW_START|KASAN_SHADOW_END|KERNEL_LINK_ADDR|ADDRESS_SPACE_END Thanks. -- An old man doll... just what I always wanted! - Clara signature.asc Description: PGP signature ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 2/2] Documentation: kdump: describe VMCOREINFO export for RISCV64
On 10/14/22 20:10, Conor Dooley wrote: > Without whitespace highlighting, your change threw me for a sec.. But > yeah, having the overline is inconsistent with other headings in the > doc. > > What I wanted to ask about was the linelength as I don't know anything > about rst. Is it possible to avoid having the ~150 character line or is > that a necessary evil? > I think the section describes correct range exports; however since there are many such ranges with distinct purposes, it is better to split the section into multiple sections describing each range. If we go without splitting, the 150-character header is necessary (I don't know how to split the header text line without trigger any warnings). Thanks. -- An old man doll... just what I always wanted! - Clara ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH V6 6/6] Documentation: kdump: describe VMCOREINFO export for RISCV64
On 8/11/22 14:41, Xianting Tian wrote: > The following interrelated definitions and ranges are needed by the kdump > crash tool, they are exported by "arch/riscv/kernel/crash_core.c": > VA_BITS, PAGE_OFFSET, phys_ram_base > MODULES_VADDR ~ MODULES_END, > VMALLOC_START ~ VMALLOC_END, > VMEMMAP_START ~ VMEMMAP_END > KASAN_SHADOW_START ~ KASAN_SHADOW_END, > KERNEL_LINK_ADDR ~ ADDRESS_SPACE_END > > This patch just add the description of VMCOREINFO export for RISCV64. > Better say "Document these RISCV64 exports above". -- An old man doll... just what I always wanted! - Clara ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH V5 5/6] riscv: crash_core: Export kernel vm layout, phys_ram_base
On Tue, Aug 02, 2022 at 08:18:17PM +0800, Xianting Tian wrote: > These infos are needed by the kdump crash tool. Since these values change > from time to time, it is preferable to export them via vmcoreinfo than to > change the crash's code frequently. > I have to agree with Conor.Dooley, that this patch is misleading (I see documentation instead of real export). So IMO, the patch subject should be "Documentation: kdump: describe VMCOREINFO export for RISCV64". For MODULES_VADDR and friends, the doc can be improved, like: diff --git a/Documentation/admin-guide/kdump/vmcoreinfo.rst b/Documentation/admin-guide/kdump/vmcoreinfo.rst index 6b76284a503ca5..6694acc32c3588 100644 --- a/Documentation/admin-guide/kdump/vmcoreinfo.rst +++ b/Documentation/admin-guide/kdump/vmcoreinfo.rst @@ -615,14 +615,13 @@ phys_ram_base Indicates the start physical RAM address. -MODULES_VADDR|MODULES_END|VMALLOC_START|VMALLOC_END|VMEMMAP_START|VMEMMAP_END -- -KASAN_SHADOW_START|KASAN_SHADOW_END|KERNEL_LINK_ADDR|ADDRESS_SPACE_END --- +MODULES_VADDR|MODULES_END|VMALLOC_START|VMALLOC_END|VMEMMAP_START|VMEMMAP_END|KASAN_SHADOW_START|KASAN_SHADOW_END|KERNEL_LINK_ADDR|ADDRESS_SPACE_END + Used to get the correct ranges: - MODULES_VADDR ~ MODULES_END : Kernel module space. - VMALLOC_START ~ VMALLOC_END : vmalloc() / ioremap() space. - VMEMMAP_START ~ VMEMMAP_END : vmemmap region, used for struct page array. - KASAN_SHADOW_START ~ KASAN_SHADOW_END : kasan shadow space. - KERNEL_LINK_ADDR ~ ADDRESS_SPACE_END : Kernel link and BPF space. + + * MODULES_VADDR ~ MODULES_END : Kernel module space. + * VMALLOC_START ~ VMALLOC_END : vmalloc() / ioremap() space. + * VMEMMAP_START ~ VMEMMAP_END : vmemmap region, used for struct page array. + * KASAN_SHADOW_START ~ KASAN_SHADOW_END : kasan shadow space. + * KERNEL_LINK_ADDR ~ ADDRESS_SPACE_END : Kernel link and BPF space. Thanks. -- An old man doll... just what I always wanted! - Clara ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
