[tboot-devel] Error code on Q45 and apparently outdated info in tboot-1.6/docs/txt-info.txt
0xc0002cd1 TBOOT: AC module error : acm_type=0x1, progress=0x0d, error=0xb TBOOT: TXT.ESTS: 0x1 TBOOT: TXT.E2STS: 0x TBOOT: IA32_FEATURE_CONTROL_MSR: ff07 TBOOT: CPU is SMX-capable TBOOT: CPU is VMX-capable TBOOT: SMX is enabled TBOOT: TXT chipset and all needed capabilities present TBOOT: TXT_RESET.STS is set and SENTER is disabled (0x01) TBOOT: SMX not supported. TBOOT: v2 LCP policy data found TBOOT: Error: ELF magic number is not matched. TBOOT: assuming kernel is Linux format TBOOT: Initrd from 0x7fd85000 to 0x703d TBOOT: Kernel (protected mode) from 0x10 to 0x3d9780 TBOOT: Kernel (real mode) from 0x9 to 0x93400 TBOOT: transfering control to kernel @0x10... - -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ tboot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tboot-devel
Re: [tboot-devel] Location of the MLE Developers Guide
Thanks! That was embarrassingly simple... (-; As for my tboot issue, I added vga_delay=5 to the tboot command line allowing me to read more of the diagnostic output. On hard boot, tboot appears to find everything in order and executes SENTER, and that's what causes a soft reboot... Curiously. "BIOS sinit size" appears to be 0... --andraxin On Tue, Dec 13, 2011 at 11:41:36AM -0700, [email protected] wrote: > > The MLE Developers guide in on the Intel site. It is located at: > > http://www.intel.com/content/www/us/en/software-developers/intel-txt-sof > tware-development-guide.html > > > > The trick is to search for Measured Launch Environment (not MLE) > Developers Guide. > > > > Hope this helps. > > > > Charles > > -- > Systems Optimization Self Assessment > Improve efficiency and utilization of IT resources. Drive out cost and > improve service delivery. Take 5 minutes to use this Systems Optimization > Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/ > ___ > tboot-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/tboot-devel -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ tboot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tboot-devel
Re: [tboot-devel] tboot + TPM 2.0 + TXT (boot with grub2)
since that will be important in making further > progress. > > Good luck wih your efforts and have a good remainder of the week. > > Greg > > As always, > Dr. G.W. Wettstein, Ph.D. Enjellic Systems Development, LLC. > 4206 N. 19th Ave. Specializing in information infra-structure > Fargo, ND 58102development. > PH: 701-281-1686 > FAX: 701-281-3949 EMAIL: [email protected] > -------- > -- > "... remember that innovation is saying 'no' to 1000 things." > -- Moxie Marlinspike > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______ > tboot-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/tboot-devel > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ tboot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tboot-devel
Re: [tboot-devel] suspend problem since kernel 5.15
Hi Derek On Mon, 2022-01-31 at 17:26 +, Derek Dolney wrote: > I am using tboot 1.10.3 and all was working fine with Linux kernel > 5.10.88. However, I upgraded to kernel 5.15.16 and, while booting seems > to happen properly, suspend is broken. I am using a Lenovo T460p. > Usually when suspending the power button LED will blink 8 times and then > it goes into a sleep state. With the newer kernel I get power LED and > caps lock LED blinking, cpu fan runs fast, and can't get out of that > state. Need to hard powerdown. > > Attaching a txt-stat output. Any ideas what may be happening? Seems like > I maybe need to report to the kernel devs, but let me know if you have > some other suggestions. I could do a git bisect of the kernel source and > probably find the kernel code changes that broke suspend for me. Please > advise Without serial console, I guess that as you have a laptop you don't have RS232 port, it will not be an easy task to debug the issue. During S3 suspend Linux kernel is jumping to tboot's shutdown entry point to seal RAM content. You can try to comment out this behavior in Linux kernel to see if still you can see the issue. This experiment may tell us if hang is related to tboot's shutdown handler or not. Lukasz _______ tboot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tboot-devel
Re: [tboot-devel] status of the grub patch to support multiple SINIT modules?
Hi Timo On Fri, 2022-03-11 at 09:09 +0200, Timo Lindfors wrote: > Hi, > > in https://sourceforge.net/p/tboot/mailman/message/37340469/ there was a > discussion about needing to get grub to accept a patch to reliably support > multiple SINIT modules. Any idea what's the status of this patch? > > Using multiple SINIT modules is useful if you want to have a single image > that works on multiple devices. The intel-acm package in Debian non-free > provides these in /boot and it is very convenient that tboot can > choose the matching SINIT module at runtime. As I left Intel and nobody has taken care about this patch, it has been abandoned. As far as I remember, there were some minor changes requested by GRUB maintainers, but overall idea has been accepted. > > I was reminded of this issue since I hit it again on different hardware. > > I've attached two serial console logs for tboot mercurial tip > (9c625ab2035b): > > tboot_9c625ab2035b_2_SINIT_working.txt: > - two SINIT ACMs are specified and the system boots correctly. > > tboot_9c625ab2035b_26_SINIT_reboot.txt: > - 26 SINIT ACMs are specified and the system enters an infinïte reboot > loop. > > I do not see this problem on my BIOS system, only UEFI system, but it is > is difficult to say if this is actually related to the issue. > > You can see more logs at > https://lindi.iki.fi/lindi/tboot/smoketest/results.html > The attached logs are all from test run 1646942019. > In few words - when multiple SINITs is loaded, there is a chance that one (or more) of them will be overwritten by some TBOOT data structures that have hardcoded addresses. In most cases it is memory log, but this is not a rule. Everything depends on system memory map and where GRUB decided to put SINITs. On some platforms you can load as many SINTIs as you want, on other - only 2 or 3. So that's platform specific issue, fortunately, I didn't come across a platform where this problem happens even with 1 SINIT loaded. I will try to find some time to dig into grub-devel archive, find the patch, fix it and resubmit it once again. However, it depends on OS vendors when they will merge it to their distro. > As a workaround, would you accept a patch that modifies > tboot/20_linux_tboot to use txt-acminfo to include only matching SINIT > modules in grub configuration? I could make this configurable in > /etc/default/grub-tboot. We could for example support the following three > options: > > GRUB_TBOOT_SINIT=all > - include all SINIT modules that are found, current behavior > > GRUB_TBOOT_SINIT=detect > - use txt-acminfo to find SINIT modules that match the current system. > > GRUB_TBOOT_SINIT_LIST="module1 module2 module3" > - use only the listed SINIT modules. > That's sounds great to me. I am sure that Intel will accept this change. It is much better to select proper SINIT during installation that loads all possible ones every boot, only to always choose the same right one. Thanks, Lukasz ___ tboot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tboot-devel
Re: [tboot-devel] status of the grub patch to support multiple SINIT modules?
On Fri, 2022-03-11 at 11:23 +0200, Timo Lindfors wrote: > Hi, > > On Fri, 11 Mar 2022, Łukasz Hawryłko wrote: > > In few words - when multiple SINITs is loaded, there is a chance that > > one (or more) of them will be overwritten by some TBOOT data structures > > that have hardcoded addresses. In most cases it is memory log, but this > > is not a rule. > > This sounds annoying indeed. Would it help if we could somehow embed > or append the SINIT modules to tboot.gz itself? I'm trying to make the > technology as easy to use and robust as possible. Being able to use e.g. > the same Live CD on all pieces of hardware would be a huge win. > That could help, but I can't give you a definite answer. There is also a risk that bigger tboot.gz will cause some other memory corruption errors. Keep in mind that besides tboot.gz and SINITs, GRUB loads also kernel image and initrd. The best way to fix all possible problems is to instruct GRUB not to load anything in memory regions occupied by tboot's hardcoded structures. I see that you have quite complex environment for testing tboot, if I find my old GRUB patch and prepare patch for tboot that combined should fix the issue, will you be able to run tests? Thanks, Lukasz _______ tboot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tboot-devel
Re: [tboot-devel] status of the grub patch to support multiple SINIT modules?
E_HIGH:
+ grub_multiboot2_mlp.preference = GRUB_RELOCATOR_PREFERENCE_HIGH;
+ break;
+
+ default:
+ grub_multiboot2_mlp.preference = GRUB_RELOCATOR_PREFERENCE_NONE;
+ }
+ break;
+
/* GRUB always page-aligns modules. */
case MULTIBOOT_HEADER_TAG_MODULE_ALIGN:
break;
diff -r 30c0c2ae5167 -r e774651a58f4 include/grub/multiboot2.h
--- a/include/grub/multiboot2.h Wed Mar 09 15:31:51 2022 -0500
+++ b/include/grub/multiboot2.h Mon Aug 16 12:02:52 2021 +0200
@@ -92,6 +92,15 @@
};
typedef struct mbi_load_data mbi_load_data_t;
+struct module_load_preferences
+{
+ int relocatable;
+ grub_uint32_t min_addr;
+ grub_uint32_t max_addr;
+ grub_uint32_t align;
+ grub_uint32_t preference;
+};
+
/* Load ELF32 or ELF64. */
grub_err_t
grub_multiboot2_load_elf (mbi_load_data_t *mld);
@@ -99,6 +108,7 @@
extern grub_size_t grub_multiboot2_pure_size;
extern grub_size_t grub_multiboot2_alloc_mbi;
extern grub_uint32_t grub_multiboot2_payload_eip;
+extern struct module_load_preferences grub_multiboot2_mlp;
#endif /* ! GRUB_MULTIBOOT_HEADER */
diff -r 30c0c2ae5167 -r e774651a58f4 include/multiboot2.h
--- a/include/multiboot2.h Wed Mar 09 15:31:51 2022 -0500
+++ b/include/multiboot2.h Mon Aug 16 12:02:52 2021 +0200
@@ -74,6 +74,7 @@
#define MULTIBOOT_HEADER_TAG_EFI_BS 7
#define MULTIBOOT_HEADER_TAG_ENTRY_ADDRESS_EFI64 9
#define MULTIBOOT_HEADER_TAG_RELOCATABLE 10
+#define MULTIBOOT_HEADER_TAG_MODULE_LOAD_PREFERENCES 11
#define MULTIBOOT2_ARCHITECTURE_I386 0
#define MULTIBOOT2_ARCHITECTURE_MIPS32 4
@@ -178,6 +179,17 @@
multiboot_uint32_t preference;
};
+struct multiboot_header_tag_module_load_preferences
+{
+ multiboot_uint16_t type;
+ multiboot_uint16_t flags;
+ multiboot_uint32_t size;
+ multiboot_uint32_t min_addr;
+ multiboot_uint32_t max_addr;
+ multiboot_uint32_t align;
+ multiboot_uint32_t preference;
+};
+
struct multiboot_color
{
multiboot_uint8_t red;
# HG changeset patch
# User Łukasz Hawryłko
# Date 1629375460 -7200
# Thu Aug 19 14:17:40 2021 +0200
# Node ID b8d18df5adc26c39a8cbfc5b6babe946b762e741
# Parent 8ab1cfa6301f1f892d7d8e82532c6609e136765c
Use multiboot2 module load preference tag
This is new a tag added recently to GRUB that allows to specify memory region
where GRUB should load multiboot2 modules. Thanks to this, TBOOT can now be sure
that none of the modules overlaps memory intended for memory log.
This patch, together with new GRUB version, fixes issue when multiple SINITs
has been loaded in multiboot2 and some of them may get overwritten by TBOOT's
memory log.
Signed-off-by: Lukasz Hawrylko
diff -r 8ab1cfa6301f -r b8d18df5adc2 tboot/common/boot.S
--- a/tboot/common/boot.S Sun Dec 12 01:55:53 2021 +0100
+++ b/tboot/common/boot.S Thu Aug 19 14:17:40 2021 +0200
@@ -113,6 +113,13 @@
FB_MAX_VRES, /* height */ \
FB_BPP /* depth */
+/* Module load preference tag */
+mb2ht_init MB2_HDR_TAG_MOD_LOAD_PREFERENCE, MB2_HDR_TAG_OPTIONAL, \
+ 0x90, /* min_addr */ \
+ 0x,/* max_addr */ \
+ 0x1000,/* align */ \
+ 0 /* preference */
+
/* Multiboot2 header end tag. */
mb2ht_init MB2_HDR_TAG_END, MB2_HDR_TAG_REQUIRED
diff -r 8ab1cfa6301f -r b8d18df5adc2 tboot/include/multiboot.h
--- a/tboot/include/multiboot.h Sun Dec 12 01:55:53 2021 +0100
+++ b/tboot/include/multiboot.h Thu Aug 19 14:17:40 2021 +0200
@@ -77,6 +77,7 @@
#define MB2_HDR_TAG_CONSOLE_FLAGS 4
#define MB2_HDR_TAG_FRAMEBUFFER 5
#define MB2_HDR_TAG_MOD_ALIGN 6
+#define MB2_HDR_TAG_MOD_LOAD_PREFERENCE 11
#define MB2_HDR_TAG_REQUIRED 0
#define MB2_HDR_TAG_OPTIONAL 1
___
tboot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tboot-devel
Re: [tboot-devel] [PATCH] 20_linux_tboot: efi logic was inverted
Hi Tony
On Thu, 2022-06-09 at 15:04 -0400, Tony Camuso wrote:
> # HG changeset patch
> # User Tony Camuso
> # Date 1654800659 14400
> # Thu Jun 09 14:50:59 2022 -0400
> # Node ID be868f53407d4460491a0e77e5165025153b0329
> # Parent 206a47f3e9d2c18c8a3db082216ee6fc3c5d475c
> 20_linux_tboot: efi logic was inverted
>
> There was a RAID0 system that could boot normally, but not through
> a tboot launch. The problem was that the logic in this script
> incorrectly appended 'noefi' to the grub.cfg module2 kernel stanza.
>
> When 'noefi' was removed from that stanza, the system could boot
> through a tboot launch. This patch corrects the logic in the script.
>
> diff -r 206a47f3e9d2 -r be868f53407d tboot/20_linux_tboot
> --- a/tboot/20_linux_tbootThu Mar 17 23:58:50 2022 +0200
> +++ b/tboot/20_linux_tbootThu Jun 09 14:50:59 2022 -0400
> @@ -105,11 +105,11 @@
> if [ -d /sys/firmware/efi ] ; then
> mb_directive="multiboot2"
> mb_mod_directive="module2"
> - mb_extra_kernel="noefi"
> + mb_extra_kernel=""
> else
> mb_directive="multiboot2"
> mb_mod_directive="module2"
> - mb_extra_kernel=""
> + mb_extra_kernel="noefi"
> fi
>
> printf "menuentry '${title}' ${CLASS} {\n" "${os}" "${tboot_version}"
> "${version}"
>
'noefi' flag tells the kernel that even if current system is EFI based
it must not use EFI services (to be precisely EFI Runtime Services).
This is required because EFI is not a part of TXT TCB. After system
enters TXT environment it must execute only the code that is measured.
As EFI (and BIOS in general) is not measured from TXT perspective you
are not allowed to use it. That's why 'noefi' flag is added.
Logic is correct in the original version. When EFI capable system is
detected it adds 'noefi' flag to prevent kernel from using EFI. On
non-EFI systems this flag is pointless because kernel can't use EFI
services if they do not exist.
If removing 'noefi' flag solves your issue, you should find out why.
Maybe there is some information that kernel retrieves from EFI Runtime
Services that is required to properly boot the platform. If this is the
case, the only way to fix this correctly is to get this information in
tboot, before GETSEC[SENTER], and that in some way pass it to the
kernel.
Thanks,
Lukasz
___
tboot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tboot-devel
Re: [tboot-devel] [PATCH] Correct IDT exception handler addresses
Hi Alex
On Mon, 2022-07-11 at 13:00 -0500, Alex Olson wrote:
> # HG changeset patch
> # User Alex Olson
> # Date 1657558891 18000
> # Mon Jul 11 12:01:31 2022 -0500
> # Node ID 0552b7ac10e28b378dd139e5ca3838039c472827
> # Parent fa60b63892e8f9d4278950b44ed136d2b12d19cc
> Correct IDT exception handler addresses
>
> The exception handlers configured in the IDT weren't properly executed
> during exceptions as _start/TBOOT_START are not 64K aligned (0x804000).
>
> This revision corrects the arithmetic so that the "int_handler" routine
> gets properly executed instead of "int_handler - 0x4000".
>
> NOTE: A simple way to test this is to insert 'asm volatile("ud2");' in
> begin_launch().
>
Thank you for the patch.
Lukasz
___
tboot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tboot-devel
Re: [tboot-devel] TBOOT on a PowerEdge R730 with a TPM2.0
Hi Miguel On Fri, 2022-10-07 at 14:30 +, Miguel Mota wrote: > If I change either the kernel or the initrd the system still boots as > expected (since I have policy of continue instead of halt) and the > PCR will have different values (as expected) but the TBOOT tool says > the "TXT Measured Launch: True" when I expected it to to be false. Am > I miss-interpreting the normal behaviour of TXT here? Also, is this > VLP (without the LCP) enough for remote attestation? I'd say yes > since pcr 17-20 have all the required information and they can't be > altered by an bad actor due to their locality requirements. "TXT Measured Launch: True" means that system was successfully booted with TXT. Measured launch is a process where measures of boot components are collected and stored to TPM PCRs, but not verified. This is the standard behaviour of TXT. For remote attestation you don't have to provision LCP or VLP, because default policies already collect measurements. You can use LCP or VLP to configure what PCRs will be extended with particular boot components, but in general this is not required. To sum up, you are right, your system is ready to enable remote attestation. Thanks, Lukasz _______ tboot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tboot-devel
Re: [tboot-devel] [Tboot-changelog] changeset in code: Extend low memory range reserved for logs
Hi Paweł On Thu, 2022-12-22 at 15:13 +, Pawel Randzio wrote: > changeset b06289220ef8 in /hg/p/tboot/code > details: > http://hg.code.sf.net/p/tboot/code/code?cmd=changeset;node=b06289220ef8 > description: > Extend low memory range reserved for logs > > Some platforms with higher core count had the issue of logs > overflowing the memory range reserved for them, and thus > overwriting themselves, leaving just a bit of last lines > of logs to be later read. > > Before range was 32KB, now it is 200KB which HOPEFULLY > won't need further extensions > This patch adds at least two memory overlap issues. Real mode part of Linux kernel (and cmdline args) has starting address limited in TBOOT to max 0x9. After this patch, memory assigned to logs overlaps with this address. In my testing system - i5-7300U, Linux kernel does not start after applying the patch. Secondly, address of TBOOT's S3 wakeup handler is hardcoded to 0x8a000, that also is covered by the new logs region. I am not XEN expert, but there is also a comment in config.h that suggest that XEN has some trampoline code at 0x8c000, this may also conflict with logs. As I said, my testing system does not boot with this patch, I expect that this is not the only one. I don't know the exact motivation on expanding space for logs, but you should consider to do this in another way. Thanks, Lukasz _______ tboot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tboot-devel
[tboot-devel] Missing "rootflags=subvol=root" for Btrfs
All GRUB configurations generated for tboot misses "rootflags=subvol=root" and
causes boot failure:
if [ -z "${kernelopts}" ]; then
set kernelopts="root=UUID=f4131454-9e14-4af9-b28e-93afc232a8b2 ro
rootflags=subvol=root rd.luks.uuid=luks-3fc85411-b08c-4185-b41d-bc0950877aeb
rhgb quiet "
fi
……
submenu "tboot 1.10.5" {
menuentry 'Fedora GNU/Linux, with tboot 1.10.5 and Linux
6.4.10-100.fc37.x86_64' --class fedora --class gnu-linux --class gnu --class os
--class tboot {
insmod multiboot2
insmod part_gpt
insmod ext2
set root='hd1,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd1,gpt2
--hint-efi=hd1,gpt2 --hint-baremetal=ahci1,gpt2
85215e34-eff0-4cba-9f44-f9c485483800
else
search --no-floppy --fs-uuid --set=root
85215e34-eff0-4cba-9f44-f9c485483800
fi
echo'Loading tboot 1.10.5 ...'
multiboot2 /tboot.gz logging=serial,memory,vga
echo'Loading Linux 6.4.10-100.fc37.x86_64 ...'
module2 /vmlinuz-6.4.10-100.fc37.x86_64
root=UUID=f4131454-9e14-4af9-b28e-93afc232a8b2 ro
rd.luks.uuid=luks-3fc85411-b08c-4185-b41d-bc0950877aeb rhgb quiet
intel_iommu=on noefi
echo'Loading initial ramdisk ...'
module2 /initramfs-6.4.10-100.fc37.x86_64.img
echo'Loading sinit SNB_IVB_SINIT_20190708_PW.bin ...'
module2 /SNB_IVB_SINIT_20190708_PW.bin
}
smime.p7s
Description: S/MIME cryptographic signature
___
tboot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tboot-devel
Re: [tboot-devel] tboot-devel Digest, Vol 160, Issue 1
Mark, Michael, Has this patch been submitted upstream yet? If so, to what branch? Thanks On 10/17/2025 8:14 AM, [email protected] wrote: Send tboot-devel mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/tboot-devel or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of tboot-devel digest..." Today's Topics: 1. [PATCH 1/1] Disable CET when calling tboot shutdown procedure. (Michal Camacho Romero) -- Message: 1 Date: Fri, 17 Oct 2025 09:36:19 +0200 From: Michal Camacho Romero To: [email protected], [email protected] Cc: [email protected], Mark Gross , Mark Gross , Michal Camacho Romero Subject: [tboot-devel] [PATCH 1/1] Disable CET when calling tboot shutdown procedure. Message-ID: <[email protected]> From: Mark Gross The tboot->shutdown_entry is effectively bios code and CET needs to be disabled before calling it. It resolves TBOOT shutdown failure bug, reported on the SLES (SUSE Linux Enterprise Server) 16.0 OS. OS power off, called by the "init 0" command, was failing, due to activated Intel Control-Flow Enforcement Technology (CET). Disabling CET has allowed to execute OS and TBOOT shutdown properly. Closes: https://bugzilla.suse.com/show_bug.cgi?id=1247950 Signed-off-by: Mark Gross Signed-off-by: Michal Camacho Romero --- arch/x86/kernel/tboot.c | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/x86/kernel/tboot.c b/arch/x86/kernel/tboot.c index 46b8f1f16676..73396c43a7ad 100644 --- a/arch/x86/kernel/tboot.c +++ b/arch/x86/kernel/tboot.c @@ -28,6 +28,7 @@ #include #include #include +#include #include "../realmode/rm/wakeup.h" @@ -247,6 +248,10 @@ void tboot_shutdown(u32 shutdown_type) switch_to_tboot_pt(); + /* +* toggle off CET while we call shutdown_entry in bios +*/ + cet_disable(); shutdown = (void(*)(void))(unsigned long)tboot->shutdown_entry; shutdown(); _______ tboot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tboot-devel
Re: [tboot-devel] [PATCH 1/1] Disable CET when calling tboot shutdown procedure.
89/0x160 [ 169.752143] ? __count_memcg_events+0xdf/0x170 [ 169.756645] ? handle_mm_fault+0x256/0x370 [ 169.760813] ? do_user_addr_fault+0x347/0x640 [ 169.765235] ? exc_page_fault+0x73/0x160 [ 169.769228] ? entry_SYSCALL_64_after_hwframe+0x76/0x7e _______ tboot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tboot-devel
Re: [tboot-devel] [PATCH 1/1] Disable CET when calling tboot shutdown procedure.
d_op+0x50/0x70 [ 169.614715] ? exc_control_protection+0x18c/0x190 [ 169.619482] ? asm_exc_invalid_op+0x1a/0x20 [ 169.623728] ? exc_control_protection+0x18c/0x190 [ 169.628496] ? exc_control_protection+0x14f/0x190 [ 169.633263] asm_exc_control_protection+0x26/0x30 [ 169.638030] RIP: 0010:0x8041d0 [ 169.641142] Code: Unable to access opcode bytes at 0x8041a6. [ 169.646857] RSP: 0018:ff55b3cba167fb50 EFLAGS: 00010007 [ 169.652144] RAX: 008041d0 RBX: RCX: 0005 [ 169.659341] RDX: 00c6e8a7c000 RSI: 0001 RDI: ff1ff000 [ 169.666525] RBP: 0005 R08: R09: [ 169.673709] R10: R11: R12: 2001 [ 169.680906] R13: a5ae02c8 R14: R15: [ 169.688091] ? tboot_shutdown+0x5b/0x140 [ 169.692084] ? tboot_sleep+0x12c/0x140 [ 169.695890] ? acpi_os_enter_sleep+0x2b/0x60 [ 169.700221] ? acpi_hw_legacy_sleep+0x140/0x1c0 [ 169.704816] ? acpi_power_off+0x16/0x40 [ 169.708715] ? sys_off_notify+0x48/0x70 [ 169.712615] ? notifier_call_chain+0x5a/0xd0 [ 169.716943] ? atomic_notifier_call_chain+0x32/0x50 [ 169.721885] ? do_kernel_power_off+0x3e/0x50 [ 169.726213] ? native_machine_power_off+0x21/0x40 [ 169.730983] ? __do_sys_reboot+0x1d2/0x240 [ 169.735151] ? do_syscall_64+0x7d/0x160 [ 169.739053] ? syscall_exit_work+0xf3/0x120 [ 169.743302] ? syscall_exit_to_user_mode+0x32/0x190 [ 169.748243] ? do_syscall_64+0x89/0x160 [ 169.752143] ? __count_memcg_events+0xdf/0x170 [ 169.756645] ? handle_mm_fault+0x256/0x370 [ 169.760813] ? do_user_addr_fault+0x347/0x640 [ 169.765235] ? exc_page_fault+0x73/0x160 [ 169.769228] ? entry_SYSCALL_64_after_hwframe+0x76/0x7e _______ tboot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tboot-devel
Re: [tboot-devel] [PATCH 1/1] Disable CET when calling tboot shutdown procedure.
RSI: 0001 RDI: ff1ff000 [ 169.666525] RBP: 0005 R08: R09: [ 169.673709] R10: R11: R12: 2001 [ 169.680906] R13: a5ae02c8 R14: R15: [ 169.688091] ? tboot_shutdown+0x5b/0x140 [ 169.692084] ? tboot_sleep+0x12c/0x140 [ 169.695890] ? acpi_os_enter_sleep+0x2b/0x60 [ 169.700221] ? acpi_hw_legacy_sleep+0x140/0x1c0 [ 169.704816] ? acpi_power_off+0x16/0x40 [ 169.708715] ? sys_off_notify+0x48/0x70 [ 169.712615] ? notifier_call_chain+0x5a/0xd0 [ 169.716943] ? atomic_notifier_call_chain+0x32/0x50 [ 169.721885] ? do_kernel_power_off+0x3e/0x50 [ 169.726213] ? native_machine_power_off+0x21/0x40 [ 169.730983] ? __do_sys_reboot+0x1d2/0x240 [ 169.735151] ? do_syscall_64+0x7d/0x160 [ 169.739053] ? syscall_exit_work+0xf3/0x120 [ 169.743302] ? syscall_exit_to_user_mode+0x32/0x190 [ 169.748243] ? do_syscall_64+0x89/0x160 [ 169.752143] ? __count_memcg_events+0xdf/0x170 [ 169.756645] ? handle_mm_fault+0x256/0x370 [ 169.760813] ? do_user_addr_fault+0x347/0x640 [ 169.765235] ? exc_page_fault+0x73/0x160 [ 169.769228] ? entry_SYSCALL_64_after_hwframe+0x76/0x7e _______ tboot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tboot-devel
[tboot-devel] [RFC] tboot: kernel signature verification
Hello, I've been working on adding PECOFF/kernel signature verification to tboot and now that I have a rough working prototype I wanted to bring it to the list to see if this is something the tboot community would be interested in eventually merging (once the work is more complete and polished). The patchset is quite large, mostly due to the inclusion of libtomcrypt and libtomfastmath to the tboot repository, so I'm going to refrain from spamming the list with the full patchset at this early stage. The current patchset can be found on GitHub at the URL below (look in the "working-txtsig" branch): * https://github.com/pcmoore/misc-tboot/tree/working-txtsig The prototype doesn't actually enforce any policy or change the PCR measurements based on the kernel signatures (both are planned work items), but it does demonstrate the ability to parse and verify a signed PECOFF image. The individual patch descriptions provide some additional information on some of the planned work to take this from a prototype to a proper implementation. My motivation for this work is to create a mechanism that is capable of generating a stable set of PCR values across multiple kernels that can be used to seal TPM NVRAM secrets on both legacy BIOS and UEFI systems. Imagine being able to store a storage encryption key in the TPM, and restricting access to that key to only authorized kernels in such a way that didn't require changing the tboot policy when booting different kernels. I imagine I'm not along in thinking this would be a nice capability to have, especially on systems that don't support UEFI Secure Boot. For those who are interested, I gave a presentation on this work at the Linux Security Summit last month, the video and sldies are available at the links below: * https://www.youtube.com/watch?v=Qbjz_5jUE9o * https://www.paul-moore.com/docs/lss-securing_tpm_with_txt-pmoore-201909-r2.pdf Thoughts? Is this capability something the TXT/tboot community would be interested in merging into the main tboot repository once it is more complete? ___________ tboot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tboot-devel
Re: [tboot-devel] [RFC] tboot: kernel signature verification
Hi Lukasz, Thanks for taking a look, I know it is a lot to ask. When looking at the patches I'm mostly concerned about feedback on the general concepts at this stage; the patches are still very much a work in progress. My goal in posting this on-list was to get some feedback now to see if this is something that would be of interest to the project. I would hate to spend a few more months on this only to find out that tboot has not interest in signature verification :) As far as changes to the VLP are concerned, if you look at the patch titled "tboot: add PECOFF signature verification hooks" you will see that two of the TODO items are ... - Support for kernel signature verification in the tboot policy. This probably means specifying a signing certificate as part of the policy. We want to support certificate chains. Backwards compatibility is a must. - If the tboot policy can not be easily extended to support signature verification, we could consider embedding the certificate into the tboot binary at build time, similar to what is done with the UEFI Secure Boot shim. I would obviously prefer to add a signing certificate or CA to the VLP, but I haven't done enough investigation into the VLP format to know if that is practical. As a fallback I could envision embedding the certificate into the binary (as the current prototype does), but that is something I would like to avoid if possible. As far as attestation and PCR values are concerned, my current thought is to hash the signing certificate into one PCR (say PCR A) (assuming the kernel signature is valid) and a combined hash of the kernel/initrd/cmdline into a different PCR (say PCR B). My thinking is that this would allow admins to seal/attest to either a specific kernel/initrd/cmdline using PCR B or to the signing authority which has validated the kernel/etc. using PCR A. However, I am open to other ideas if you have suggestions - this effort is still in the early stages. This is one of the reasons I wanted to bring this effort to the list as soon as the basic idea (PECOFF signature verification in tboot) was working. Thanks again, -Paul On Fri, 2019-09-27 at 13:43 +0200, Lukasz Hawrylko wrote: > Hi Paul > > Thank you for sharing your work. I will look at this patch and check > how > it works, idea of measuring kernel signature instead of whole binary > is > very interesting. I hope that next week I will find some time for > that, > as you said patch is quite big. > > Do you plan to add ability to verify public key using VLP? If I > understand correctly your current goal is to verify kernel binary with > signature and extend PCRs with signature's public key hash, am I > right? > In this approach tboot is not able to verify if kernel is signed by > proper authority, this need to be done be local/remote attestation in > further boot process. > > Thanks, > Lukasz > > On Thu, 2019-09-19 at 15:39 +, Paul Moore (pmoore2) via tboot- > devel > wrote: > > Hello, > > > > I've been working on adding PECOFF/kernel signature verification to > > tboot and now that I have a rough working prototype I wanted to > > bring > > it to the list to see if this is something the tboot community would > > be interested in eventually merging (once the work is more complete > > and polished). > > > > The patchset is quite large, mostly due to the inclusion of > > libtomcrypt and libtomfastmath to the tboot repository, so I'm going > > to refrain from spamming the list with the full patchset at this > > early > > stage. The current patchset can be found on GitHub at the URL below > > (look in the "working-txtsig" branch): > > > > * > > https://github.com/pcmoore/misc-tboot/tree/working-txtsig > > > > > > The prototype doesn't actually enforce any policy or change the PCR > > measurements based on the kernel signatures (both are planned work > > items), but it does demonstrate the ability to parse and verify a > > signed PECOFF image. The individual patch descriptions provide some > > additional information on some of the planned work to take this from > > a prototype to a proper implementation. > > > > My motivation for this work is to create a mechanism that is capable > > of generating a stable set of PCR values across multiple kernels > > that > > can be used to seal TPM NVRAM secrets on both legacy BIOS and UEFI > > systems. Imagine being able to store a storage encryption key in > > the > > TPM, and restricting access to that key to only authorized kernels > > in > > such a way that didn't require changing the tboot policy when > > booting > > different kernels. I imagine I'm
Re: [tboot-devel] [RFC] tboot: kernel signature verification
ure Boot shim. > > > > I would obviously prefer to add a signing certificate or CA to the > > VLP, > > but I haven't done enough investigation into the VLP format to know > > if > > that is practical. As a fallback I could envision embedding the > > certificate into the binary (as the current prototype does), but > > that > > is > > something I would like to avoid if possible. > > > > As far as attestation and PCR values are concerned, my current > > thought > > is to hash the signing certificate into one PCR (say PCR A) > > (assuming > > the kernel signature is valid) and a combined hash of the > > kernel/initrd/cmdline into a different PCR (say PCR B). My thinking > > is > > that this would allow admins to seal/attest to either a specific > > kernel/initrd/cmdline using PCR B or to the signing authority which > > has > > validated the kernel/etc. using PCR A. However, I am open to other > > ideas if you have suggestions - this effort is still in the early > > stages. This is one of the reasons I wanted to bring this effort to > > the > > list as soon as the basic idea (PECOFF signature verification in > > tboot) > > was working. > > > > Thanks again, > > -Paul > > > > On Fri, 2019-09-27 at 13:43 +0200, Lukasz Hawrylko wrote: > > > Hi Paul > > > > > > Thank you for sharing your work. I will look at this patch and > > > check > > > how > > > it works, idea of measuring kernel signature instead of whole > > > binary > > > is > > > very interesting. I hope that next week I will find some time for > > > that, > > > as you said patch is quite big. > > > > > > Do you plan to add ability to verify public key using VLP? If I > > > understand correctly your current goal is to verify kernel binary > > > with > > > signature and extend PCRs with signature's public key hash, am I > > > right? > > > In this approach tboot is not able to verify if kernel is signed > > > by > > > proper authority, this need to be done be local/remote attestation > > > in > > > further boot process. > > > > > > Thanks, > > > Lukasz > > > > > > On Thu, 2019-09-19 at 15:39 +, Paul Moore (pmoore2) via tboot- > > > devel > > > wrote: > > > > Hello, > > > > > > > > I've been working on adding PECOFF/kernel signature verification > > > > to > > > > tboot and now that I have a rough working prototype I wanted to > > > > bring > > > > it to the list to see if this is something the tboot community > > > > would > > > > be interested in eventually merging (once the work is more > > > > complete > > > > and polished). > > > > > > > > The patchset is quite large, mostly due to the inclusion of > > > > libtomcrypt and libtomfastmath to the tboot repository, so I'm > > > > going > > > > to refrain from spamming the list with the full patchset at this > > > > early > > > > stage. The current patchset can be found on GitHub at the URL > > > > below > > > > (look in the "working-txtsig" branch): > > > > > > > > * > > > > https://github.com/pcmoore/misc-tboot/tree/working-txtsig > > > > > > > > > > > > > > > > The prototype doesn't actually enforce any policy or change the > > > > PCR > > > > measurements based on the kernel signatures (both are planned > > > > work > > > > items), but it does demonstrate the ability to parse and verify > > > > a > > > > signed PECOFF image. The individual patch descriptions provide > > > > some > > > > additional information on some of the planned work to take this > > > > from > > > > a prototype to a proper implementation. > > > > > > > > My motivation for this work is to create a mechanism that is > > > > capable > > > > of generating a stable set of PCR values across multiple kernels > > > > that > > > > can be used to seal TPM NVRAM secrets on both legacy BIOS and > > > > UEFI > > > > systems. Imagine being able to store a storage encryption key > > > > in > > > > the > > > > TPM, and restricting access to that key to only authorized > > > > kernels > > > > in > > > > such a way that didn't require changing the tboot policy when > > > > booting > > > > different kernels. I imagine I'm not along in thinking this > > > > would > > > > be a nice capability to have, especially on systems that don't > > > > support > > > > UEFI Secure Boot. > > > > > > > > For those who are interested, I gave a presentation on this work > > > > at > > > > the Linux Security Summit last month, the video and sldies are > > > > available at the links below: > > > > > > > > * > > > > https://www.youtube.com/watch?v=Qbjz_5jUE9o > > > > > > > > > > > > * > > > > https://www.paul-moore.com/docs/lss-securing_tpm_with_txt-pmoore-201909-r2.pdf > > > > > > > > > > > > > > > > Thoughts? Is this capability something the TXT/tboot community > > > > would > > > > be interested in merging into the main tboot repository once it > > > > is > > > > more complete? > > > > > > > > ___ > > > > tboot-devel mailing list > > > > [email protected] > > > > > > > > > > > > https://lists.sourceforge.net/lists/listinfo/tboot-devel > > > > > > > > > > > > ___ tboot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tboot-devel
Re: [tboot-devel] [RFC] tboot: kernel signature verification
On Thu, 2019-09-19 at 15:39 +, Paul Moore (pmoore2) via tboot-devel wrote: > Hello, > > I've been working on adding PECOFF/kernel signature verification to > tboot and now that I have a rough working prototype I wanted to bring > it to the list to see if this is something the tboot community would > be interested in eventually merging (once the work is more complete > and polished). > > The patchset is quite large, mostly due to the inclusion of > libtomcrypt and libtomfastmath to the tboot repository, so I'm going > to refrain from spamming the list with the full patchset at this early > stage. The current patchset can be found on GitHub at the URL below > (look in the "working-txtsig" branch): > > * https://github.com/pcmoore/misc-tboot/tree/working-txtsig > I've updated the working-txtsig branch with a number of fixes relating to the ASN.1/PKCS parsing code as well as improved signing/hash algorithm support (previously limited to SHA256) and the ability to verify kernels using variable length certificate chains (previously limited to the immediate signer). Work on adding certificate support to the tboot launch control policy is ongoing (it's the next major work item), but the prototype contains a hard coded Fedora CA which should be able to verify any modern Fedora kernel. Just as before, if you have any questions, concerns, or feedback please get in touch on-list or privately. I'll be giving an updated presentation on this effort at the Linux Security Summit EU later this month, if you are in the area please stop by and introduce yourself - I'd love to talk about TXT/tboot! https://events19.linuxfoundation.org/events/linux-security-summit-europe-2019 Thanks, -Paul ___ tboot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tboot-devel
[tboot-devel] Creating a TXT/tboot policy suitable for a modern system with TXT+TPM2
Hi Lukasz, others, I'm in the process of working on the TXT/sig extensions to the LCP but I'm running into problems using the tboot tools to create a working LCP as a baseline. Simply put, the instructions I've been able to find either in the sources, the mailing list archives, or through Google searches do not produce a working LCP on my test system. The tools/arguments are either wrong, or the resulting LCP is bogus. Before I start hacking away at the tools to get them to create a functional LCP that tboot understands, does anyone have a working how-to for creating a LCP using the current sources? Thanks, -Paul _______ tboot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tboot-devel
Re: [tboot-devel] Creating a TXT/tboot policy suitable for a modern system with TXT+TPM2
On Tue, 2019-11-05 at 23:02 +, [email protected] wrote: > > -Original Message- > > From: Paul Moore (pmoore2) via tboot-devel > [email protected]> > > Sent: Tuesday, November 5, 2019 16:50 > > To: [email protected]; > > [email protected] > > Subject: [tboot-devel] Creating a TXT/tboot policy suitable for a > > modern > > system with TXT+TPM2 > > > > > > > > Hi Lukasz, others, > > > > I'm in the process of working on the TXT/sig extensions to the LCP > > but I'm > > running into problems using the tboot tools to create a working LCP > > as a > > baseline. Simply put, the instructions I've been able to find > > either in the > > sources, the mailing list archives, or through Google searches do > > not produce > > a working LCP on my test system. The tools/arguments are either > > wrong, or > > the resulting LCP is bogus. > > I had to patch lcptools-v2 because I found the same problem. Nothing > would produce a good LCP. > > > Before I start hacking away at the tools to get them to create a > > functional LCP > > that tboot understands, does anyone have a working how-to for > > creating a > > LCP using the current sources? > > When I patched lcptools-v2, I added a simple how-to for an MLE LCP, > it's in the mailing list archives at the link below. If you need more, > I have a few other examples. > > https://sourceforge.net/p/tboot/mailman/message/35976955/ Thanks Travis, that got me going in the right direction; I needed to add a tboot policy element to make my system happy, but that was a trivial addition to your instructions above. If you're willing to share your other examples, I'd love to see them, and I'm sure others would as well. Thanks again. ___ tboot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tboot-devel
Re: [tboot-devel] Creating a TXT/tboot policy suitable for a modern system with TXT+TPM2
On Wed, 2019-11-06 at 20:12 +, [email protected] wrote: > > -Original Message- > > From: Paul Moore (pmoore2) > > Sent: Tuesday, November 5, 2019 19:28 > > To: Gilbert, Travis > > Cc: [email protected] > > Subject: Re: Creating a TXT/tboot policy suitable for a modern > > system with > > TXT+TPM2 > > > > On Tue, 2019-11-05 at 23:02 +, [email protected] wrote: > > > > -Original Message- > > > > From: Paul Moore (pmoore2) via tboot-devel > > > [email protected]> > > > > Sent: Tuesday, November 5, 2019 16:50 > > > > To: [email protected]; > > > > [email protected] > > > > Subject: [tboot-devel] Creating a TXT/tboot policy suitable for > > > > a > > > > modern system with TXT+TPM2 > > > > > > > > > > > > > > > > Hi Lukasz, others, > > > > > > > > I'm in the process of working on the TXT/sig extensions to the > > > > LCP > > > > but I'm running into problems using the tboot tools to create a > > > > working LCP as a baseline. Simply put, the instructions I've > > > > been > > > > able to find either in the sources, the mailing list archives, > > > > or > > > > through Google searches do not produce a working LCP on my test > > > > system. The tools/arguments are either wrong, or the resulting > > > > LCP > > > > is bogus. > > > > > > I had to patch lcptools-v2 because I found the same problem. > > > Nothing > > > would produce a good LCP. > > > > > > > Before I start hacking away at the tools to get them to create a > > > > functional LCP that tboot understands, does anyone have a > > > > working > > > > how-to for creating a LCP using the current sources? > > > > > > When I patched lcptools-v2, I added a simple how-to for an MLE > > > LCP, > > > it's in the mailing list archives at the link below. If you need > > > more, > > > I have a few other examples. > > > > > > https://sourceforge.net/p/tboot/mailman/message/35976955/ > > > > Thanks Travis, that got me going in the right direction; I needed to > > add a > > tboot policy element to make my system happy, but that was a trivial > > addition to your instructions above. > > > > If you're willing to share your other examples, I'd love to see > > them, and I'm > > sure others would as well. > > > > Thanks again. > > I've got about 20 some of which are negative test cases. They're bash > scripts. I've stripped out the beginning shell line to make it more > email handler friendly. #9 is actually split into 5 different tests > signing various other policies that were previously unsigned. They > were designed to be run in order as some later tests rely on the > outputs of previous tests. I've included #3 and one of #9. Let me know > if you have interest in any of the others. You don't have to take > ownership or define the index every time, but keeping it in the script > didn't cause us any issues. We could just copy some of the > intermediate files and keep things simple when running tests out of > order on multiple machines. > > TXT - Scenario#1, Single MLE element and Unsigned Policy > TXT - Scenario#2, Three MLE elements and Unsigned LCP > TXT - Scenario#3, One PCONF element and Unsigned LCP > TXT - Scenario#4, Two PCONF elements and Unsigned LCP > TXT - Scenario#5, MLE, PCONF list Unsigned > TXT - Scenario#6, SINIT Revocation (Negative Testing) > TXT - Scenario#7, MLE Mismatch 1 - wrong hash file (Negative Testing) > TXT - Scenario#8, PCONF mismatch (Negative Testing) > TXT - Scenario#9, Signed policies with 2048 keys > TXT - Scenario#10, Signed policy with 1024 key > TXT - Scenario#11, Signed policy with 3072 key > TXT - Scenario#12: signed policy with invalid key size (2000) > TXT - Scenario#13 Input Validation, signed policy with invalid key > size (512) > TXT - Scenario#14, signed policy with invalid key size (4096) > TXT - Scenario#15, MLE Mismatch - change in boot parameters (Negative > Testing) > > <3> > cd /boot > tpm2_takeownership -o new -e new -l new > tpm2_nvdefine -x 0x1c10106 -a 0x4001 -P new -s 70 -t 0x204000A > > #TXT - Scenario#3, One PCONF element and Unsigned LCP > tpm2_listpcrs -g 0x0B -o 1pcrs > truncate -s 32 1pcrs #only select PCR0 for the policy > lcp2_cr
Re: [tboot-devel] Creating a TXT/tboot policy suitable for a modern system with TXT+TPM2
On Fri, 2019-11-08 at 12:47 +0100, Lukasz Hawrylko wrote: > For TPM2.0 LCP generation there is a Python tool lcp-gen2 that is > included in tboot's source code. To be honest I didn't try to generate > LCP with tboot's VLP inside but it should work. If not - this is a bug > and need to be fixed. > > lcptools-v2 will is not maintained, any new features like new signing > algorithms will not be included there, so I suggest not to use it for > new designs. We are actively improving lcp-gen2, if there is something > that is missing in your opinion please let me know. A few problems come to mind with lcp-gen2 all of which are blockers: * I see references to upgrading to newer versions of Python 2.x, but nothing about upgrading to Python 3.x; with Python 2.x going EOL in a few months this needs to happen very soon. * No documentation. This is a general problem with the tboot code/tools: there is very little documentation, and what does seem to be present is mostly wrong or incomplete. * The lcp-gen2 tool appears to be intended mostly as a GUI tool, and I need a CLI tool. It looks like there might be some sort of "batch build" available from the command line, but I don't see any further explanation or documentation on this ability. You mention that lcp-gen2 is being actively improved, is this happening offline? The last commit I see is to the sf.net repo for lcp-gen2 is over six months old. If these issues can't be resolved within the next month or two, is there any reason why we couldn't continue to make changes to the lcptools-v2 tools? -Paul _______ tboot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tboot-devel
Re: [tboot-devel] Creating a TXT/tboot policy suitable for a modern system with TXT+TPM2
I'm glad to hear that Python 3.x support is in the works, but I remain concerned about the CLI support. While JSON/XML is better than nothing, it still adds a bit of pain for those of us wishing to script the tools; while a parameter based approach might not be pretty, it is much easier to script. I'm a bit farther down the patch of sorting out the policy patches for the TXT/sig work, and as it currently stands it looks like the changes for lcptools-v2 is going to be very minor. Essentially it looks like the only changes I will need to make is to add a predefined custom ELT UUID for a certificate payload, and even then that is optional (one can specify the UUID on the command line if necessary). The other changes to the tboot policy would live outside lcptools-v2 in tb_polgen. Would you be open to merging *small* patches to lcptools-v2? I *really* don't want to have to deal with a GUI and/or JSON/XML if I don't have to do so. On Wed, 2019-11-13 at 15:23 +0100, Lukasz Hawrylko wrote: > Thank you for feedback, I understand your point. I was talking with > tools maintainer and he started working on migration to Python 3.x and > better CLI support (together with documentation how to use it). Our > idea > is not to add enormous list parameters to generate LCP with desired > options, but to add JSON/XML file that will describe LCP in human- > readable format. After preparing that file (you can do that in VIM) > you > will feed it into tool and than get LCP. I would like to hear your > opinion about that idea. > > The only reason why I don't want to maintain lcptools-v2 is to not > have > two tools that do the same thing. I hope that with your input we can > improve lcp-gen2 so it can replace lcptools-v2 in every case. In my > opinion adding CLI to GUI application is easier than adding GUI to CLI > application, that's why I decided to go with lcp-gen2. > > We are working on lcp-gen2 in our local repository, I will ask > maintainer when he will be ready with Python 3.x migration if that > will > be less than month I will wait for that to release new version. > > Lukasz > > On Fri, 2019-11-08 at 18:34 +, [email protected] wrote: > > > -Original Message- > > > From: Paul Moore (pmoore2) < > > > [email protected] > > > Sent: Friday, November 8, 2019 11:19 > > > To: > > > [email protected] > > > ; Gilbert, Travis > > > Cc: > > > [email protected] > > > > > > Subject: Re: [tboot-devel] Creating a TXT/tboot policy suitable > > > for a modern > > > system with TXT+TPM2 > > > > > > On Fri, 2019-11-08 at 12:47 +0100, Lukasz Hawrylko wrote: > > > > For TPM2.0 LCP generation there is a Python tool lcp-gen2 that > > > > is > > > > included in tboot's source code. To be honest I didn't try to > > > > generate > > > > LCP with tboot's VLP inside but it should work. If not - this is > > > > a bug > > > > and need to be fixed. > > > > > > > > lcptools-v2 will is not maintained, any new features like new > > > > signing > > > > algorithms will not be included there, so I suggest not to use > > > > it for > > > > new designs. We are actively improving lcp-gen2, if there is > > > > something > > > > that is missing in your opinion please let me know. > > > > > > A few problems come to mind with lcp-gen2 all of which are > > > blockers: > > > > > > * I see references to upgrading to newer versions of Python 2.x, > > > but nothing > > > about upgrading to Python 3.x; with Python 2.x going EOL in a few > > > months > > > this needs to happen very soon. > > > > > > * No documentation. This is a general problem with the tboot > > > code/tools: there is very little documentation, and what does seem > > > to be > > > present is mostly wrong or incomplete. > > > > > > * The lcp-gen2 tool appears to be intended mostly as a GUI tool, > > > and I need a > > > CLI tool. It looks like there might be some sort of "batch build" > > > available from > > > the command line, but I don't see any further explanation or > > > documentation > > > on this ability. > > > > > > You mention that lcp-gen2 is being actively improved, is this > > > happening > > > offline? The last commit I see is to the sf.net repo for lcp-gen2 > > > is over six > > > months old. > > > > &g
Re: [tboot-devel] Creating a TXT/tboot policy suitable for a modern system with TXT+TPM2
On Wed, 2019-11-13 at 17:17 +, [email protected] wrote: > > -Original Message- > > From: Paul Moore (pmoore2) > > Sent: Wednesday, November 13, 2019 09:51 > > To: [email protected]; Gilbert, Travis > > Cc: [email protected] > > Subject: Re: [tboot-devel] Creating a TXT/tboot policy suitable for > > a modern system with TXT+TPM2 ... > > I'm a bit farther down the patch of sorting out the policy patches > > for the > > TXT/sig work, and as it currently stands it looks like the changes > > for lcptools- > > v2 is going to be very minor. Essentially it looks like the only > > changes I will > > need to make is to add a predefined custom ELT UUID for a > > certificate > > payload, and even then that is optional (one can specify the UUID on > > the > > command line if necessary). > > Are you adding the ELT UUID as a policy element plugin similar to > mle_elt, sbios_elt, & stm_elt? That is the current approach, yes, but I consider it very much up for discussion/review. Essentially you dump a bundle of DER encoded certificates into a policy element and mark it with the newly specified UUID and after tboot has entered into the TXT protected state it imports those certificates into the cert DB as "trusted" which allows them to act as a root of trust for the PECOFF signature verification. This is actually working now, but I want to sort out the VLP details before updating the GitHub repo. The VLP changes are still a work in progress, but my current approach is to introduce a new hash type (e.g. TB_HTYPE_PECOFF) which would be an indication to tboot to perform PECOFF signature verification (using the previously imported trusted certificate payload) instead of the traditional digest verification. Not only does this preserve the VLP format, but it allows us to integrate with the rest of the VLP and leverage all of the existing policy functionality such as configurable PCR extension. Similar to the certificate ELT payload, it *should* result in minimal changes to the tooling, most of the changes will be in tboot itself. As soon as I have the VLP changes working I'll update my GH repo and post an update to the list, but comments on the above approach are always welcome. -Paul _______ tboot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tboot-devel
Re: [tboot-devel] Creating a TXT/tboot policy suitable for a modern system with TXT+TPM2
Thanks Lukasz. I realize that might be a difficult discussion internally, but I think it is the right thing to do at this point in time. On Fri, 2019-11-15 at 15:07 +0100, Lukasz Hawrylko wrote: > To be honest I don't know the history of lcp-gen2, personally I prefer > CLI tools too, so I understand your point. I thought that migration to > GUI tool was requested by TBOOT users. I going to start internal > discussion who is using lcp-gen2, maybe we should take a step back and > instead of developing new tool that nobody is going to use, continue > support for lcptools-v2. > > > On Wed, 2019-11-13 at 17:15 +, [email protected] wrote: > > > -Original Message- > > > From: Lukasz Hawrylko < > > > [email protected] > > > Sent: Wednesday, November 13, 2019 08:24 > > > To: Gilbert, Travis; > > > [email protected] > > > > > > Cc: > > > [email protected] > > > > > > Subject: Re: [tboot-devel] Creating a TXT/tboot policy suitable > > > for a modern > > > system with TXT+TPM2 > > > > > > > > > Thank you for feedback, I understand your point. I was talking > > > with tools > > > maintainer and he started working on migration to Python 3.x and > > > better CLI > > > support (together with documentation how to use it). Our idea is > > > not to add > > > enormous list parameters to generate LCP with desired options, but > > > to add > > > JSON/XML file that will describe LCP in human- readable format. > > > After > > > preparing that file (you can do that in VIM) you will feed it into > > > tool and than > > > get LCP. I would like to hear your opinion about that idea. > > > > > > The only reason why I don't want to maintain lcptools-v2 is to not > > > have two > > > tools that do the same thing. > > > > I understand your desire to avoid unnecessary duplication of work. > > Please understand my frustration with the situation and lack of > > communication from Intel. I understand that you weren't directly > > involved at the time, but you're the face now, so you get the > > complaints :) > > > > Intel created a separate tool, lcp-gen2, without mentioning it on > > the mailing list in the months leading up to its release. Until then > > we *had* one functioning toolset that everyone else was using for > > TPM 2.0. It was lcptools-v2. Then Intel abandoned it with no > > warning. Just pushed a whole new toolset at once. > > > > It broke a bunch of testing we had when your ACMs started checking > > things that lcptools-v2 apparently wasn't writing correctly. Up > > until the ACM changes, everything was fine. Intel apparently knew > > this because the lcp-gen2 toolset was merged not too long after and > > they generated working LCPs. > > > > That's the history of the situation in which we now find ourselves. > > Now that the air is clear, we can move on and work together on a > > solution. > > > > > I hope that with your input we can improve lcp- > > > gen2 so it can replace lcptools-v2 in every case. In my opinion > > > adding CLI to > > > GUI application is easier than adding GUI to CLI application, > > > that's why I > > > decided to go with lcp-gen2. > > > > We're very happy to work with Intel to get a solution that meets all > > our needs. We want TXT to be a robust solution for everyone. > > > > > We are working on lcp-gen2 in our local repository, I will ask > > > maintainer when > > > he will be ready with Python 3.x migration if that will be less > > > than month I will > > > wait for that to release new version. > > > > > > Lukasz > > > > > > On Fri, 2019-11-08 at 18:34 +, > > > [email protected] > > > wrote: > > > > > -Original Message- > > > > > From: Paul Moore (pmoore2) < > > > > > [email protected] > > > > > > > > > > > > > > > Sent: Friday, November 8, 2019 11:19 > > > > > To: > > > > > [email protected] > > > > > > > > > > ; Gilbert, Travis > > > > > Cc: > > > > > [email protected] > > > > > > > > > > > > > > > Subject: Re: [tboot-devel] Creating a TXT/tboot policy > > > > >
Re: [tboot-devel] [RFC] tboot: kernel signature verification
On Fri, 2019-10-18 at 13:27 +, Paul Moore (pmoore2) via tboot-devel wrote: > On Thu, 2019-09-19 at 15:39 +, Paul Moore (pmoore2) via > tboot-devel wrote: > > Hello, > > > > I've been working on adding PECOFF/kernel signature verification to > > tboot ... Hello everyone, I just pushed another update to my git repository under the working- txtsig branch: * https://github.com/pcmoore/misc-tboot/tree/working-txtsig This update is notable in that it adds the missing policy support; no longer is the Fedora CA built into the tboot binary, verification certificates should be included in the LCP and the tboot VLP specifies which modules are subject to signature verification. While there is still work to be done, I believe the code is now feature complete (or very close to it). I would appreciate sanity checks on my approach, especially when it comes to the policy changes. The commit descriptions have additional information, but in order to include certificates in the LCP, you would do the following: # lcp2_crtpolelt --create \ --type custom --uuid certificates test.der \ --out test.elt ... in this case test.der is a DER encoded X509 certificate; multiple certificates may be concatenated together into the file, tboot will load each certificate. Once the policy ELT has been created, it can be included in the LCP just as you would any other ELT module. Once you have created a certificate ELT, you need to tell the tboot VLP to perform PECOFF signature verification on the kernel module; you can do that with the following command(s): # tb_polgen --create --type nonfatal test.vlp # tb_polgen --add --num 0 --pcr 20 --hash pecoff test.vlp # tb_polgen --show test.vlp policy: version: 2 policy_type: TB_POLTYPE_CONT_NON_FATAL hash_alg: TB_HALG_SHA1 policy_control: 0001 (EXTEND_PCR17) num_entries: 1 policy entry[0]: mod_num: 0 pcr: 20 hash_type: TB_HTYPE_PECOFF num_hashes: 0 ... the pecoff/TB_HTYPE_PECOFF hash type instructs tboot to perform PECOFF signature verification on the given module. When selected, the digest of the trusted root for the signing authority will be extended into the given PCR, which happens to be PCR 20 in the example above. As a point of clarification, the "trusted root" is not necessarily the root CA of the signature chain, but rather the "nearest" certificate that was loaded from the LCP which is part of the signature chain. This should provide for the most flexibility while preserving a signature root of trust in the LCP/TPM. Comments and feedback on this approach are encouraged! -Paul _______ tboot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tboot-devel
Re: [tboot-devel] [RFC] tboot: kernel signature verification
On Mon, 2019-12-02 at 14:09 +0100, Lukasz Hawrylko wrote: > Hi Paul > > I went through all steps and I was able to create LCP with > certificated, > VLP with TB_HTYPE_PECOFF and finally got platform booted with PCR 20 > extended by certificate hash (to be honest I didn't check if it is > correct). So everything works, however I have few notes :) No worries, thanks for giving it a test. The code is still pretty rough, so I expect there to be plenty of feedback :) I guess what I'm most concerned about at this point are the changes to the policy: both the new LCP certificate payload element as well as the VLP/TB_HTYPE_PECOFF changes. Do those seem reasonable? > If VLP is present under its own index (for TPM 2.0 it is 0x01C10131), > tboot will not read LCP at all, so certificate will not be available. > I > think that we should modify program flow, so even if VLP is present, > LCP > should be read to check if LCP_CUSTOM_ELEMENT_CERTS_UUID element is > there. That sounds reasonable, let me see what I can do. > Still I can't verify signature of custom build kernel signed by my own > key, I am trying to figure out what is wrong, but without luck. One > thing that I found is a problem in pkcs1_search_signer > function (pkcs1.c:101), it is comparing certificate subject, but not > from the root of certificate. Can you elaborate a bit more on what you mean by "the root of certificate"? Alternatively, could you upload the kernel and signing certificate somewhere I could grab so I can play with it? > I know that this is working fine with > Fedora's certificate, but I don't know if this is valid for every > case. > With my simple certificate this was a first problem that I found. At > least, you should check if pointer to next element in chain is not > NULL. ___ tboot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tboot-devel
Re: [tboot-devel] [RFC] tboot: kernel signature verification
On Wed, 2019-12-04 at 14:33 +, Paul Moore (pmoore2) via tboot-devel wrote: > On Mon, 2019-12-02 at 14:09 +0100, Lukasz Hawrylko wrote: > > If VLP is present under its own index (for TPM 2.0 it is > > 0x01C10131), > > tboot will not read LCP at all, so certificate will not be > > available. > > I > > think that we should modify program flow, so even if VLP is present, > > LCP > > should be read to check if LCP_CUSTOM_ELEMENT_CERTS_UUID element is > > there. > > That sounds reasonable, let me see what I can do. A question for discussion: if the VLP is loaded from it's own nvindex, and there is also a VLP present inside the LCP, which VLP do we want to use? I'm assuming it is the VLP we loaded directly, and not from inside the LCP, but thought it was worth checking. -Paul ___ tboot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tboot-devel
Re: [tboot-devel] [RFC] tboot: kernel signature verification
On Fri, 2019-12-06 at 11:37 +0100, Lukasz Hawrylko wrote: > On Wed, 2019-12-04 at 14:33 +, Paul Moore (pmoore2) wrote: > > Can you elaborate a bit more on what you mean by "the root of > > certificate"? Alternatively, could you upload the kernel and > > signing > > certificate somewhere I could grab so I can play with it? > > Maybe I used wrong words, I am talking about pkcs1_search_signer > function and following lines: > > if (!asn1_blob_cmp(&entry->cert.serial, serial) && > !asn1_blob_cmp(&entry->cert.ca->subject, subject)) > > If I change them to > > if (!asn1_blob_cmp(&entry->cert.serial, serial) && > !asn1_blob_cmp(&entry->cert.subject, subject)) > > it will find my certificate. Thanks, that makes it much more clear. One of the benefits of sharing code is that it helps remove any uncertainties. :) > Could you please explain me why are you > using serial from root of entry and subject from sub-element? Is it > connected with certificate chain? What if there is just the simplest > possible certificate that is not signed by anybody? That does look a little odd, doesn't it? It's likely left over from a rework of the code during development that wasn't caught because of 1) it worked on my Fedora based test cases, and 2) I haven't really gone over all of the code yet to make sure it is "sane" ;) I know I've said this before, but please consider all of this code still a very rough prototype. Normally I wouldn't share code of this quality, but since there are a large number of uncertainties surrounding this work (e.g. is this approach reasonable? are the policy changes okay? etc.) I felt the advantages of sharing this code at such an early stage outweighed the risks. > I have uploaded certificate and key that I have generated here: > https://cloud.hawrylko.pl/s/ivHd7HZpuLIjQ88 there is also a signed > bzImage that I am using. Great, thank you. I'll take a closer look. > On Thu, 2019-12-05 at 17:20 +, Paul Moore (pmoore2) wrote: > > A question for discussion: if the VLP is loaded from it's own > > nvindex, > > and there is also a VLP present inside the LCP, which VLP do we want > > to > > use? I'm assuming it is the VLP we loaded directly, and not from > > inside > > the LCP, but thought it was worth checking. > > > > In "stock" TBOOT, VLP loaded from its own index has higher priority > over > one embedded in LCP, so I agree with you that here it should work like > that. > > Thanks, > Lukasz > ___ tboot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tboot-devel
Re: [tboot-devel] [RFC] tboot: kernel signature verification
On Mon, 2019-12-09 at 15:23 +0100, Lukasz Hawrylko wrote: > On Fri, 2019-12-06 at 21:28 +, Paul Moore (pmoore2) wrote: > > I know I've said this before, but please consider all of this code > > still > > a very rough prototype. Normally I wouldn't share code of this > > quality, > > but since there are a large number of uncertainties surrounding this > > work (e.g. is this approach reasonable? are the policy changes > > okay? > > etc.) I felt the advantages of sharing this code at such an early > > stage > > outweighed the risks. > > I totally understand that, it's nice that you are sharing your WIP > code, > so we can discuss changes on the fly. If I wrote something that > suggests > that I blame you for that, it's only a result of fact that English > is not my native language :) No worries, no offense was taken, I just wanted to make sure that the expectations were set appropriately. Also, I just wanted to say that your English is just fine, it's *far* better than my Polish ;) -Paul ___ tboot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tboot-devel
Re: [tboot-devel] [RFC] tboot: kernel signature verification
On Fri, 2019-12-06 at 21:28 +, Paul Moore (pmoore2) via tboot-devel wrote: > On Fri, 2019-12-06 at 11:37 +0100, Lukasz Hawrylko wrote: > > On Wed, 2019-12-04 at 14:33 +, Paul Moore (pmoore2) wrote: > > > Can you elaborate a bit more on what you mean by "the root of > > > certificate"? Alternatively, could you upload the kernel and > > > signing > > > certificate somewhere I could grab so I can play with it? > > > > Maybe I used wrong words, I am talking about pkcs1_search_signer > > function and following lines: > > > > if (!asn1_blob_cmp(&entry->cert.serial, serial) && > > !asn1_blob_cmp(&entry->cert.ca->subject, subject)) > > > > If I change them to > > > > if (!asn1_blob_cmp(&entry->cert.serial, serial) && > > !asn1_blob_cmp(&entry->cert.subject, subject)) > > > > it will find my certificate. > > Thanks, that makes it much more clear. One of the benefits of sharing > code is that it helps remove any uncertainties. :) > > > Could you please explain me why are you > > using serial from root of entry and subject from sub-element? Is it > > connected with certificate chain? What if there is just the simplest > > possible certificate that is not signed by anybody? > > That does look a little odd, doesn't it? It turns out it wasn't quite as odd as originally thought. While wrong, it wasn't far from the truth; the PKCS #7 blob in the signed PECOFF kernel image doesn't contain the signer's subject name, but rather the issuer's subject name. This explains why the code worked: in the self- signed (Lukasz's test case) and one intermediate CA cases (the Fedora test case) using the CA would result in the signer being found, anything with more than one intermediate CA would fail. I've corrected the code and pushed it to the repo/branch below: * https://github.com/pcmoore/misc-tboot/tree/working-txtsig > > I have uploaded certificate and key that I have generated here: > > https://cloud.hawrylko.pl/s/ivHd7HZpuLIjQ88 there is also a signed > > bzImage that I am using. > > Great, thank you. I'll take a closer look. It turns out this was due to a limitation in libtomfastmath. Your test key/certificate used a 4k RSA key, but libtomfastmath had a restriction on keys larger than 2k (it turns out the Fedora keys are 2k). I increased the libtomfastmath number limit to support 4k keys, and increased the tboot stack size accordingly. The updated misc- tboot/working-txtsig code should now work for your self-signed test case, if not please let me know. Thanks, -Paul ___ tboot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tboot-devel
Re: [tboot-devel] [RFC] tboot: kernel signature verification
On Fri, 2019-12-06 at 11:37 +0100, Lukasz Hawrylko wrote: > On Thu, 2019-12-05 at 17:20 +, Paul Moore (pmoore2) wrote: > > A question for discussion: if the VLP is loaded from it's own > > nvindex, > > and there is also a VLP present inside the LCP, which VLP do we want > > to > > use? I'm assuming it is the VLP we loaded directly, and not from > > inside > > the LCP, but thought it was worth checking. > > > > In "stock" TBOOT, VLP loaded from its own index has higher priority > over > one embedded in LCP, so I agree with you that here it should work like > that. I was thinking about this some more and I'm now wondering if we should only support the new TB_HTYPE_PECOFF hash type if it is present in a VLP loaded from the LCP. In order to use the new signature support admins are going to need to generate a new LCP to contain the certificate payload, why not store the VLP in the LCP at that point? Is there any advantage to storing the VLP directly in the TPM and not in the LCP? -Paul ___ tboot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tboot-devel
Re: [tboot-devel] [RFC] tboot: kernel signature verification
On Fri, 2019-12-20 at 10:51 +0100, Lukasz Hawrylko wrote: > On Tue, 2019-12-17 at 20:12 +, Paul Moore (pmoore2) wrote: > > On Fri, 2019-12-06 at 11:37 +0100, Lukasz Hawrylko wrote: > > > On Thu, 2019-12-05 at 17:20 +, Paul Moore (pmoore2) wrote: > > > > A question for discussion: if the VLP is loaded from it's own > > > > nvindex, > > > > and there is also a VLP present inside the LCP, which VLP do we > > > > want > > > > to > > > > use? I'm assuming it is the VLP we loaded directly, and not > > > > from > > > > inside > > > > the LCP, but thought it was worth checking. > > > > > > > > > > In "stock" TBOOT, VLP loaded from its own index has higher > > > priority > > > over > > > one embedded in LCP, so I agree with you that here it should work > > > like > > > that. > > > > I was thinking about this some more and I'm now wondering if we > > should > > only support the new TB_HTYPE_PECOFF hash type if it is present in a > > VLP > > loaded from the LCP. In order to use the new signature support > > admins > > are going to need to generate a new LCP to contain the certificate > > payload, why not store the VLP in the LCP at that point? > > To be honest I don't like to add any kind of limitation when it is not > needed. I think that in first approach we should allow to use any of > possible configurations. If admins prefer to delete VLP index in TPM > and > put everything in LCP, they will do it, if, for any reasons, they want > to keep VLP under its own index and put only certificate in LCP - why > not, we support that case too :) Okay, that's fine. FWIW, it seems to me as if keeping the VLP in it's own nvindex is a bit of a legacy solution, especially when we consider the PECOFF signature validation. In the PECOFF case you *must* have a LCP to carry the certificates. Not to mention the benefits of a signed LCP allowing you to update the policy without updating the values stored in the TPM nvindex (assuming the same policy signing key). > > Is there any advantage to storing the VLP directly in the TPM and > > not in > > the LCP? > > > > -Paul > > > > That's a good question. I don't know if customers prefer to use VLP in > LCP or directly, I will talk with our application engineers about > that. Thanks. -Paul ___ tboot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tboot-devel
Re: [tboot-devel] Creating a TXT/tboot policy suitable for a modern system with TXT+TPM2
On Wed, 2019-11-06 at 20:12 +, [email protected] wrote: > > -Original Message- > > From: Paul Moore (pmoore2) > > Sent: Tuesday, November 5, 2019 19:28 > > To: Gilbert, Travis > > Cc: [email protected] > > Subject: Re: Creating a TXT/tboot policy suitable for a modern > > system with TXT+TPM2 ... > > If you're willing to share your other examples, I'd love to see > > them, and I'm sure others would as well. > > > > Thanks again. > > I've got about 20 some of which are negative test cases. They're bash > scripts. I've stripped out the beginning shell line to make it more > email handler friendly. #9 is actually split into 5 different tests > signing various other policies that were previously unsigned. They > were designed to be run in order as some later tests rely on the > outputs of previous tests. I've included #3 and one of #9. Let me know > if you have interest in any of the others. Hi Travis, I'm sorry it took me a while to get back to this and try out the scripts, but if you are still willing to share I'd love to see all of them. Another question below ... > TXT - Scenario#1, Single MLE element and Unsigned Policy > TXT - Scenario#2, Three MLE elements and Unsigned LCP > TXT - Scenario#3, One PCONF element and Unsigned LCP > TXT - Scenario#4, Two PCONF elements and Unsigned LCP > TXT - Scenario#5, MLE, PCONF list Unsigned > TXT - Scenario#6, SINIT Revocation (Negative Testing) > TXT - Scenario#7, MLE Mismatch 1 - wrong hash file (Negative Testing) > TXT - Scenario#8, PCONF mismatch (Negative Testing) > TXT - Scenario#9, Signed policies with 2048 keys > TXT - Scenario#10, Signed policy with 1024 key > TXT - Scenario#11, Signed policy with 3072 key > TXT - Scenario#12: signed policy with invalid key size (2000) > TXT - Scenario#13 Input Validation, signed policy with invalid key > size (512) > TXT - Scenario#14, signed policy with invalid key size (4096) > TXT - Scenario#15, MLE Mismatch - change in boot parameters (Negative > Testing) > > <3> > cd /boot > tpm2_takeownership -o new -e new -l new > tpm2_nvdefine -x 0x1c10106 -a 0x4001 -P new -s 70 -t 0x204000A > > #TXT - Scenario#3, One PCONF element and Unsigned LCP > tpm2_listpcrs -g 0x0B -o 1pcrs > truncate -s 32 1pcrs #only select PCR0 for the policy > lcp2_crtpolelt --create --type pconf --out 1pconf.elt 1pcrs It appears that lcptools-v2 doesn't understand the "pconf" type, do you have a patch/branch/etc. that I could take a look at? I see that lcptools seems to have some basic support, and I'm sure if I dug into Intel's specs I could add it, but I'm guessing you've already done the hard work :) Thanks, -Paul ___ tboot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tboot-devel
[tboot-devel] VLP policy and TPM2 hash agility
I hope everyone had a nice holiday and is enjoying the new year thus far. As you've seen in the other thread, I'm playing around with different tboot/TXT policies and I have a question regarding tboot/VLP policies that can extend PCRs using something other than SHA1: at present tb_polgen seems limited to using SHA1, does anyone have any patches to use SHA256 (or another hash)? -Paul _______ tboot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tboot-devel
Re: [tboot-devel] VLP policy and TPM2 hash agility
On Thu, 2020-01-02 at 22:27 +, Paul Moore (pmoore2) via tboot-devel
wrote:
> I hope everyone had a nice holiday and is enjoying the new year thus
> far.
>
> As you've seen in the other thread, I'm playing around with different
> tboot/TXT policies and I have a question regarding tboot/VLP policies
> that can extend PCRs using something other than SHA1: at present
> tb_polgen seems limited to using SHA1, does anyone have any patches to
> use SHA256 (or another hash)?
To answer my own question, it appears that Lukasz added suppport in
549:ca935709d8a6 ("Add support for SHA256 in tb_polgen").
Lukasz, if I wanted to generate both SHA1 and SHA256 hashes for a TPM2
system, would I need to create two rules in the VLP? For example I do
the following now for the TXT/sig patches and PCR20:
# tb_polgen --add --num 0 --pcr 20 \
--hash pecoff pecoff.vlp
... but that only writes the SHA1 hash into PCR20, presumably I could do
the following to support both hashes?
# tb_polgen --add --num 0 --pcr 20 --alg sha1 \
--hash pecoff pecoff.vlp
# tb_polgen --add --num 0 --pcr 20 --alg sha256 \
--hash pecoff pecoff.vlp
-Paul
___________
tboot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tboot-devel
Re: [tboot-devel] VLP policy and TPM2 hash agility
On Fri, 2020-01-03 at 20:07 +, Paul Moore (pmoore2) via tboot-devel
wrote:
> On Thu, 2020-01-02 at 22:27 +, Paul Moore (pmoore2) via tboot-
> devel
> wrote:
> > I hope everyone had a nice holiday and is enjoying the new year thus
> > far.
> >
> > As you've seen in the other thread, I'm playing around with
> > different
> > tboot/TXT policies and I have a question regarding tboot/VLP
> > policies
> > that can extend PCRs using something other than SHA1: at present
> > tb_polgen seems limited to using SHA1, does anyone have any patches
> > to
> > use SHA256 (or another hash)?
>
> To answer my own question, it appears that Lukasz added suppport in
> 549:ca935709d8a6 ("Add support for SHA256 in tb_polgen").
>
> Lukasz, if I wanted to generate both SHA1 and SHA256 hashes for a TPM2
> system, would I need to create two rules in the VLP? For example I do
> the following now for the TXT/sig patches and PCR20:
>
> # tb_polgen --add --num 0 --pcr 20 \
> --hash pecoff pecoff.vlp
>
> ... but that only writes the SHA1 hash into PCR20, presumably I could
> do
> the following to support both hashes?
>
> # tb_polgen --add --num 0 --pcr 20 --alg sha1 \
> --hash pecoff pecoff.vlp
> # tb_polgen --add --num 0 --pcr 20 --alg sha256 \
> --hash pecoff pecoff.vlp
>
It appears I didn't look close enough at the patch, the hash algorithm
selection is done at VLP policy creation and applies to all the rules.
Lukasz, is there a way to generate PCR hashes for all supported
algorithms like tboot does for PCR17/18?
-Paul
___
tboot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tboot-devel
Re: [tboot-devel] Creating a TXT/tboot policy suitable for a modern system with TXT+TPM2
On Mon, 2019-12-23 at 21:20 +, Paul Moore (pmoore2) via tboot-devel wrote: > It appears that lcptools-v2 doesn't understand the "pconf" type ... I just added a new "pconf2" policy element type to lcptools-v2 so you can generate a LCP_PCONF_ELEMENT2 without having to resort to the lcp- gen2 tools. As the Intel TXT developers guide isn't as detailed as I would like, this is based mostly off the lcp-gen2 python code and may have some bugs. That said, it is working on my test system tracking both PCR0 and PCR2. If you want to play with it, you can find it in my working-txtsig development branch: * https://github.com/pcmoore/misc-tboot/tree/working-txtsig -Paul ___________ tboot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tboot-devel
Re: [tboot-devel] VLP policy and TPM2 hash agility
On Thu, 2020-01-09 at 14:59 +, Hawrylko, Lukasz wrote:
On Fri, 2020-01-03 at 20:26 +, Paul Moore (pmoore2) via tboot-devel
wrote:
On Fri, 2020-01-03 at 20:07 +, Paul Moore (pmoore2) via tboot-devel
wrote:
On Thu, 2020-01-02 at 22:27 +, Paul Moore (pmoore2) via tboot-
devel
wrote:
I hope everyone had a nice holiday and is enjoying the new year thus
far.
As you've seen in the other thread, I'm playing around with
different
tboot/TXT policies and I have a question regarding tboot/VLP
policies
that can extend PCRs using something other than SHA1: at present
tb_polgen seems limited to using SHA1, does anyone have any patches
to
use SHA256 (or another hash)?
To answer my own question, it appears that Lukasz added suppport in
549:ca935709d8a6 ("Add support for SHA256 in tb_polgen").
Lukasz, if I wanted to generate both SHA1 and SHA256 hashes for a TPM2
system, would I need to create two rules in the VLP? For example I do
the following now for the TXT/sig patches and PCR20:
# tb_polgen --add --num 0 --pcr 20 \
--hash pecoff pecoff.vlp
... but that only writes the SHA1 hash into PCR20, presumably I could
do
the following to support both hashes?
# tb_polgen --add --num 0 --pcr 20 --alg sha1 \
--hash pecoff pecoff.vlp
# tb_polgen --add --num 0 --pcr 20 --alg sha256 \
--hash pecoff pecoff.vlp
It appears I didn't look close enough at the patch, the hash algorithm
selection is done at VLP policy creation and applies to all the rules.
Lukasz, is there a way to generate PCR hashes for all supported
algorithms like tboot does for PCR17/18?
-Paul
Hello Paul
I looks like you can't create policy with different hash algorithms,
look at tb_policy_t structure in tb_policy.h There is one field for
setting hash algorithm that is common to all policy entries.
Have you been able to create a VLP which causes tboot to extend the TPM's
sha256 PCR bank?
-Paul
___________
tboot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tboot-devel
Re: [tboot-devel] VLP policy and TPM2 hash agility
On Mon, 2020-01-13 at 20:33 +, Paul Moore (pmoore2) via tboot-devel wrote:
On Thu, 2020-01-09 at 14:59 +, Hawrylko, Lukasz wrote:
On Fri, 2020-01-03 at 20:26 +, Paul Moore (pmoore2) via tboot-devel
wrote:
On Fri, 2020-01-03 at 20:07 +, Paul Moore (pmoore2) via tboot-devel
wrote:
On Thu, 2020-01-02 at 22:27 +, Paul Moore (pmoore2) via tboot-
devel
wrote:
I hope everyone had a nice holiday and is enjoying the new year thus
far.
As you've seen in the other thread, I'm playing around with
different
tboot/TXT policies and I have a question regarding tboot/VLP
policies
that can extend PCRs using something other than SHA1: at present
tb_polgen seems limited to using SHA1, does anyone have any patches
to
use SHA256 (or another hash)?
To answer my own question, it appears that Lukasz added suppport in
549:ca935709d8a6 ("Add support for SHA256 in tb_polgen").
Lukasz, if I wanted to generate both SHA1 and SHA256 hashes for a TPM2
system, would I need to create two rules in the VLP? For example I do
the following now for the TXT/sig patches and PCR20:
# tb_polgen --add --num 0 --pcr 20 \
--hash pecoff pecoff.vlp
... but that only writes the SHA1 hash into PCR20, presumably I could
do
the following to support both hashes?
# tb_polgen --add --num 0 --pcr 20 --alg sha1 \
--hash pecoff pecoff.vlp
# tb_polgen --add --num 0 --pcr 20 --alg sha256 \
--hash pecoff pecoff.vlp
It appears I didn't look close enough at the patch, the hash algorithm
selection is done at VLP policy creation and applies to all the rules.
Lukasz, is there a way to generate PCR hashes for all supported
algorithms like tboot does for PCR17/18?
-Paul
Hello Paul
I looks like you can't create policy with different hash algorithms,
look at tb_policy_t structure in tb_policy.h There is one field for
setting hash algorithm that is common to all policy entries.
Have you been able to create a VLP which causes tboot to extend the TPM's
sha256 PCR bank?
After digging through the code some more, it looks like the key to making this
work is to specify the correct "extpol=" parameter on the tboot command line.
It appears to be TPM and ACM dependent (?) so I'm not sure this will work for
everyone, but on my system "extpol=embedded" caused tboot to extend all of the
TPM PCR banks; "extpol=agile" on my system caused the ACM to reset the system.
-Paul
_______
tboot-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tboot-devel
Re: [tboot-devel] VLP policy and TPM2 hash agility
On Wed, 2020-01-15 at 15:25 +0100, Lukasz Hawrylko wrote: > On Tue, 2020-01-14 at 11:47 -0500, Paul Moore wrote: > > On Tue, Jan 14, 2020 at 10:31 AM Lukasz Hawrylko > > < > > [email protected] > > > wrote: > > > On Tue, 2020-01-14 at 00:18 +, Paul Moore (pmoore2) wrote: > > > > On Mon, 2020-01-13 at 20:33 +, Paul Moore (pmoore2) via > > > > tboot-devel wrote: > > > > > On Thu, 2020-01-09 at 14:59 +, Hawrylko, Lukasz wrote: > > > > > > On Fri, 2020-01-03 at 20:26 +, Paul Moore (pmoore2) via > > > > > > tboot-devel > > > > > > wrote: > > > > > > > Lukasz, is there a way to generate PCR hashes for all > > > > > > > supported > > > > > > > algorithms like tboot does for PCR17/18? > > > > > > > > > > > > > > -Paul > > > > > > > > > > > > > > > > > > > Hello Paul > > > > > > > > > > > > I looks like you can't create policy with different hash > > > > > > algorithms, > > > > > > look at tb_policy_t structure in tb_policy.h There is one > > > > > > field for > > > > > > setting hash algorithm that is common to all policy entries. > > > > > > > > > > Have you been able to create a VLP which causes tboot to > > > > > extend the > > > > > TPM's sha256 PCR bank? > > > > > > > > > > > > > After digging through the code some more, it looks like the key > > > > to > > > > making this work is to specify the correct "extpol=" parameter > > > > on the > > > > tboot command line. It appears to be TPM and ACM dependent (?) > > > > so I'm > > > > not sure this will work for everyone, but on my system > > > > "extpol=embedded" caused tboot to extend all of the TPM PCR > > > > banks; > > > > "extpol=agile" on my system caused the ACM to reset the system. > > > > > > > > -Paul > > > > > > > > > > As far as I remember I was able to extend SHA256 PCRs, because > > > this is > > > the only way to test my changes in tb_polgen. I am not sure, but I > > > think > > > that you have to pass "extpol=sha256" in command line and than you > > > can > > > work with SHA256 policies. Did you try to do that? I will try > > > tomorrow > > > how agile and embedded options work on my platform. > > > > Yes, "extpol=sha256" did work to extend the sha256 PCR bank, but it > > didn't extend the sha1 bank; ideally I would be able to do both and > > that is what "extpol=embedded" did for my system. > > > > I have a suspicion that instead of defaulting to sha1, we may be > > able > > to query the ACM to get the TPM2 extpol setting, but I haven't done > > any serious investigation of that yet. > > > > > > On my platform both "agile" and "embedded" options extends sha1 and > sha256 banks. When using "agile" whole process is much longer because > hash computation is done on TPM. In "embedded" hashes are computed > locally and result is sent to TPM to extend PCRs. The easiest way to > find out how that mechanism work is to look at hash_module() function > in > policy.c file. > > Interesting thing is that on your platform you can't use "agile" > method. > If reset is invoked by SINIT ACM there should be error code value in > TXT.ERRORCODE register, can you check what is there? TBOOT prints its > value during each boot, so just allow platform to boot once again > after > that reset and you will find TXT.ERRORCODE somewhere in logs. My TXT.ERRORCODE was set to 0xc0002081 when trying to boot with extpol=agile. I don't have the Type2 error code decoder spreadsheet/csv to decode the error (the TXT specification document doesn't seem to include the Type2 error codes anymore). In related news, I added a patch to my working-txtsig GH development branch which adds the "extpol=acm" option that cause tboot to query the ACM and and set the extpol based on the ACM header information; it gives the embedded policy priority when the ACM supports both embedded and agile policies. -Paul ___ tboot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tboot-devel
Re: [tboot-devel] Intel TXT + TBOOT + TPM 2.0: can't get LCP_ANY policy working on Supermicro X11SPM-TF
On Tue, 2020-02-04 at 13:50 +, LE ROY Olivier - Contractor wrote: > These two policies fail with following tboot error: > TBOOT: no SINIT provided by bootloader; using BIOS SINIT > ... > TBOOT: reading Verified Launch Policy from TPM NV... > TBOOT: TPM: fail to get public data of 0x01C10131 in TPM NV > TBOOT: :reading failed > TBOOT: reading Launch Control Policy from TPM NV... > TBOOT: :70 bytes read > TBOOT: :reading failed > TBOOT: failed to read policy from TPM NV, using default > TBOOT: policy: > > The point is the SINIT ACM reads my LCP_ANY policy from TPM2 NVram but > doesn't seem to understand it. > > There are no reason indicated in the TBOOT log. > > One reason I think of could be that the NVram index 0x01C10106 wasn't > defined with proper attributes. > I define it with: > > tpm2_nvdefine -x 0x01c10106 -a 0x4001 -s 70 -t 0x0204000a -P > password > > Hoping someone will help me solve this problem, Hi, I'm not sure if this would help, but here is the process I typically follow when first getting TXT working on a TPM2 system. 1. Reset / Clear the TPM and Take Ownership This may not be strictly necessary if you can guarantee the TPM is in a known good state, but if you aren't certain and you don't have anything stored in the TPM I think a full TPM reset/clear is a smart idea. You typically need to do the TPM clear via the BIOS menu system, and on some systems you need an admin/supervisor password set before you can access the TPM clear option. Once the TPM is cleared you can take ownership with the following command: # tpm2_takeownership -o -e -l 2. Define the LCP Index You already know how to do this, but after you clear the TPM you will need to redefine the NVRAM index on the TPM. # tpm2_nvdefine -x 0x1c10106 -a 0x4001 -P \ -s 70 -t 0x204000A 3. Write the TPM's Portion of the LCP into the TPM The LCP is too large to fit into the TPM so we split into *.data and *.pol files when generating it via the lcp2_crtpol tool. You'll want to pass the *.data file to tboot during boot and the *.pol file (lists.pol in the example below) you'll want to write to the TPM using the following command: # tpm2_nvwrite -x 0x1c10106 -a 0x4001 -P lists.pol Hopefully that gets you closer to a working system. I'm in the process of writing up some better notes, I'll send a note to the list when they are available. Good luck! -Paul _______ tboot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tboot-devel
Re: [tboot-devel] Intel TXT + TBOOT + TPM 2.0: can't get LCP_ANY policy working on Supermicro X11SPM-TF
On Tue, 2020-02-04 at 14:59 +, LE ROY Olivier - Contractor wrote: > Hi, > > thanks for this checklist , but unfortunately, I already observed > these manipulations, without success. > > I must say the same attempt was done on two Supermicro platforms > (Brodwell based and Cascade Lake based) with same result: > > TBOOT: :70 bytes read > TBOOT: :reading failed I'm sorry to hear that didn't help. Unfortunately the tboot code that reads the LCP doesn't provide a lot of detailed information by default; you may need to instrument the tboot code to debug this further. If you haven't found it already, a good starting point is the tboot/common/policy.c:set_policy() function. > De : Paul Moore (pmoore2) > Envoyé : mardi 4 février 2020 15:44 > À : LE ROY Olivier - Contractor; [email protected] > Objet : Re: [tboot-devel] Intel TXT + TBOOT + TPM 2.0: can't get > LCP_ANY policy working on Supermicro X11SPM-TF > > On Tue, 2020-02-04 at 13:50 +, LE ROY Olivier - Contractor wrote: > > These two policies fail with following tboot error: > > TBOOT: no SINIT provided by bootloader; using BIOS SINIT > > ... > > TBOOT: reading Verified Launch Policy from TPM NV... > > TBOOT: TPM: fail to get public data of 0x01C10131 in TPM NV > > TBOOT: :reading failed > > TBOOT: reading Launch Control Policy from TPM NV... > > TBOOT: :70 bytes read > > TBOOT: :reading failed > > TBOOT: failed to read policy from TPM NV, using default > > TBOOT: policy: > > > > The point is the SINIT ACM reads my LCP_ANY policy from TPM2 NVram > but > > doesn't seem to understand it. > > > > There are no reason indicated in the TBOOT log. > > > > One reason I think of could be that the NVram index 0x01C10106 > wasn't > > defined with proper attributes. > > I define it with: > > > > tpm2_nvdefine -x 0x01c10106 -a 0x4001 -s 70 -t 0x0204000a -P > > password > > > > Hoping someone will help me solve this problem, > > Hi, > > I'm not sure if this would help, but here is the process I typically > follow when first getting TXT working on a TPM2 system. > > 1. Reset / Clear the TPM and Take Ownership > > This may not be strictly necessary if you can guarantee the TPM is in > a > known good state, but if you aren't certain and you don't have > anything > stored in the TPM I think a full TPM reset/clear is a smart idea. You > typically need to do the TPM clear via the BIOS menu system, and on > some > systems you need an admin/supervisor password set before you can > access > the TPM clear option. Once the TPM is cleared you can take ownership > with the following command: > > # tpm2_takeownership -o -e -l > > 2. Define the LCP Index > > You already know how to do this, but after you clear the TPM you will > need to redefine the NVRAM index on the TPM. > > # tpm2_nvdefine -x 0x1c10106 -a 0x4001 -P \ > -s 70 -t 0x204000A > > 3. Write the TPM's Portion of the LCP into the TPM > > The LCP is too large to fit into the TPM so we split into *.data and > *.pol files when generating it via the lcp2_crtpol tool. You'll want > to > pass the *.data file to tboot during boot and the *.pol file > (lists.pol > in the example below) you'll want to write to the TPM using the > following command: > > # tpm2_nvwrite -x 0x1c10106 -a 0x4001 -P lists.pol > > Hopefully that gets you closer to a working system. I'm in the > process > of writing up some better notes, I'll send a note to the list when > they > are available. > > Good luck! > > -Paul > > ___ > tboot-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/tboot-devel ___ tboot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tboot-devel
[tboot-devel] Update on my tboot kernel signature verification work
Hello all, I wanted to provide a quick update on the TXT/sig project and point you at it's new location on GitHub: * https://github.com/anuvu/tboot ... the TXT/sig changes can be found in the master branch. In addition to the code changes, I've included a README.md with a lot of information on how to use the tboot signature verification code, as well as TXT and tboot in general. Even if you are not interested in using signed kernel images, you may find the README.md documentation helpful. Unfortunately for my TXT/sig efforts, there have been some changes in the product I am working on and the TXT/sig capability is not expected to be a critical part of the product. This means my contributions going forward are likely to be seriously diminished. I do have some interest in pursuing this on my own time, but considering all of the other demands on my time I'm not certain how much I will be able to contribute. I've cleaned the existing patches up as much as time would allow, and I believe they are in half-reasonable shape; if the tboot community wants to merge them as they currently are, I'm happy to do whatever I can on my end to make that happen. If someone wants to take these patches and build on top of them, that's fine too. If there is anything I can do to help, please let me know, just understand my time is likely to be limited. Beyond the TXT/sig patches, I believe the repo mentioned above contains some other patches which I believe have standalone value: * "all: ensure we can build on a modern system" This patch allows tboot to successfully build with GCC v9. I know there have been other GCC related patches posted to the mailing list; it might be worthwhile checking to see if this patch adds additional corrections. * "lcptools-v2: add pconf2 policy element support" Adds the ability to create a TPM2 PCONF policy element to the lcptools- v2 tools. I realize that there is a strong desire on the part of Intel to move to the Python GUI tools, but for those of us who prefer the command line lcptools-v2 tools this may be useful. * "tboot: get the TPM extpol setting from the ACM" This patch adds the ability to query the ACM during boot and adjust the "extpol" setting based on the ACM's reported support (cmdline example: "extpol=acm"). Hopefully some of this work will prove helpful, even if it is just the information in README.md. Thanks for all your help over the past year! -Paul ___ tboot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tboot-devel
[tboot-devel] Issue with grub2-2.02-0.86 and tboot-1.9.11
Hi, I have an issue with grub2-2.02-0.86 which I hadn't with grub2-2.02-0.80. TBOOT: Error: Linux setup sectors 212 exceed maximum limitation 64. Has anyone experienced the same error? Cordialement / regards, Olivier le Roy (contractor) HW – SW development engineer Thales LAS France ___ tboot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tboot-devel
