Re: [tboot-devel] PCR values?
On 09/01/2016 10:55 AM, Jan Schermer wrote: > Do you have the correct TPM driver loaded in kernel? Does > /sys/class/misc/tpm0 exist? > AFAIK you can TXT-launch a kernel that has no driver (as it is likely loaded > in initramfs or later anyway), txt-stat will probably also work even without > a working in the kernel... > On newer kernels (4.x+ IIRC) the location in sysfs changed: /sys/class/tpm/tpm0/device/pcrs > Jan > > >> On 01 Sep 2016, at 16:32, Brian E Luckau <bluc...@sgi.com> wrote: >> >> In the past using tboot 1.8.x and versions of trousers, tpm tools, etc, >> etc. that came with the distros, I was able to see the PCR values with: >> >> cat /sys/class/misc/tpm0/device/pcrs >> >> Currently I'm in CentOS 7.2 and have compliled and installed tboot 1.9.4. I >> see this, which with my limited knowledge base tells me something is goign >> right: >> >> >> [root@server0 ~]# txt-stat | grep measured >> TXT measured launch: TRUE >> TBOOT: measured launch succeeded >> >> [root@server0 ~]# txt-stat | grep senter >> senter_done: TRUE >> >> >> Any idea why I can't see the PCR values? >> >> -- >> ___ >> tboot-devel mailing list >> tboot-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/tboot-devel > > > -- > ___ > tboot-devel mailing list > tboot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/tboot-devel > -- Ross Philipson -- ___ tboot-devel mailing list tboot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tboot-devel
Re: [tboot-devel] About changeset 664e69 - backward-incompatible change of the way tboot reads command lines
On 02/23/2016 07:01 AM, Wilck, Martin wrote:
> Changeset 664e69 fundamentally changes the way tboot command lines need
> to be built. I have read the discussions leading to this change, and I
> agree that it was the right decision make this change. However, I have
> issues with the way it was implemented:
>
> 1. tboot has stripped the first command line argument since 36d849
> (2008-12-22) (that is, practically forever). People have got used to it,
> and many users (everyone who isn't using "tip") are still using tboot
> versions that do it. Yet the changes made to the documentation in commit
> 664e69 don't bother to explain this drastic change of usage. This will
> confuse users (it did confuse myself, actually). I think that the
> documentation should spell this out much more clearly.
>
> 2. /etc/grub.d/20_linux{_,_xen_}tboot haven't been changed. They still
> generate grub2 command lines according to the old, now broken assumption
> that the first argument will be skipped by tboot.
>
> I reckon that a new tboot release including 664e69 would deserve an
> obvious change in the version number, 1.9.x would seem appropriate. That
I think that is a very good suggestion as well as what is suggested in
1. above regarding documenting it.
> would also raise the question of an independent 1.8.x release
> incorporating the bug fixes in for 1.8.3 that can be applied without
> breaking existing configurations (after all, 1.8.3 already contains
> change set 0efdaf which fixes the worst part of the vulnerability caused
> by command line stripping, at least for the common case of GRUB2 users).
If this were done I would also clearly document that this line of code
has the old fix and the 1.9 line has the new one.
>
> Regards
> Martin
>
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
> ___
> tboot-devel mailing list
> tboot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tboot-devel
>
--
Ross Philipson
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel
[tboot-devel] TBOOT 1.8.3 LZ_Compress very slow and buffer overrun in compression logic
I am starting a new thread for these issues because I now understand
what is going on. The original thread was this one:
http://sourceforge.net/p/tboot/mailman/message/34455904/
We have identified 2 issues with the LZ compressed log code feature
introduced here:
http://hg.code.sf.net/p/tboot/code/rev/9040e000ccc4
http://hg.code.sf.net/p/tboot/code/rev/78713e04bdd9
Issue #1
Calls to LZ_Compress can be extremely slow. On all the systems we have
we are seeing times on the order of around 1 minute to as bad as 4
minutes or more on the first zip to occur. This is why we thought we saw
hangs - they turned out to be temporary ones and eventually the system
would resume from S3.
The author of the LZ code actually states that it is very very slow:
https://github.com/NordicSemiconductor/puck-central-ios/blob/master/PuckCentral/lz.c#L22
I assume this particular implementation was chosen because it is BSD
(lzlib is GPL)? I also assume LZ_CompressFast was not used because of
the very large buffer it needs? At any rate, I don't think this is an
acceptable delay in S3 resume.
Issue #2
The new log compressing logic is susceptible to buffer overruns after a
sequence of S3 sleeps and resumes. This is because there is no
terminating condition in the logic. This condition needs to be tested
before copying more zipped blobs and text into the log buffer:
if (g_log->curr_pos + count > g_log->max_size) {
g_log->zip_size = LZ_Compress(_log->buf[g_log->zip_pos], out,
g_log->curr_pos - g_log->zip_pos);
/* This is the new condition that needs to be tested for here */
if (g_log->zip_pos + g_log->zip_size + count > g_log->max_size) {
/* Not sure what the right thing to do here is. Reset logging
pointers, disable further mem logging, etc... */
}
...
}
I have shown in code that I do reach that condition and logging beyond
that condition results in a buffer overrun.
Thanks
--
Ross Philipson
--
___
tboot-devel mailing list
tboot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tboot-devel
Re: [tboot-devel] TBOOT 1.8.3 fails to resume from S3
On 09/10/2015 03:35 PM, Ross Philipson wrote: > I have been working on moving our project from TBOOT 1.7.0 to 1.8.3. I > have discovered that while our 1.7.0 version of TBOOT resumes from S3 > just fine, 1.8.3 does not. > > The most common symptom seems to be a hang just after TBOOT enters SMX > mode. The hang happens at different places so I don't think it is one > specific thing that TBOOT is doing to cause the hang. The hang can be > short (on the order of seconds) or longs (several minutes). Then > suddenly the platform will "unhang". It looks like the platform restarts > quickly and goes right back in to TBOOT but it is a little hard to tell > exactly what happens right around this point. We see this on every > system we have tried it on. > > I have backed all our patches out and I still see the problem with a > clean 1.8.3 code base. I have also tried using TBOOT with a Debian > Jessie install and I get similar problems there. I have been comparing > the code between the version and have so far not found anything that > makes a difference. > > Any help in this matter is appreciated. > Thanks I spent some time tracking this down today. If I build without these two patches, I no longer get a hang on resume from S3: http://hg.code.sf.net/p/tboot/code/rev/9040e000ccc4 http://hg.code.sf.net/p/tboot/code/rev/78713e04bdd9 I have not identified the exact cause yet but I wanted to get these results posted to the list. Thanks -- Ross Philipson -- ___ tboot-devel mailing list tboot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tboot-devel
Re: [tboot-devel] TBOOT 1.8.3 fails to resume from S3
On 09/11/2015 05:21 PM, Ahmed, Safayet (GE Global Research) wrote: > The current bleeding-edge version of TBOOT contains a fix for a > stack-overflow problem that was present in the code you cited: > > http://sourceforge.net/p/tboot/code/ci/a21e913550866591ba838d49fb3aed43b2f6aadd/tree//tboot/common/printk.c?diff=9040e000ccc4cd85fe8e34616f21e0207808604a > > The resulting overflow would overwrite strings in the .rodata section of > TBOOT memory. I'm wondering if this was the cause of the hangs. Hmm, well that certainly sounds like a nasty problem. We were curious about the gigantic buffer on the stack in that routine. It seems the BSP stack size is still not big enough even with this patch? I will try these fixes out, thanks for pointing that out. I suspect we may have another problem though. The previous terminating condition was correctly wrapping the log in memlog_write. It seems the new logic for whether to try to zip does not provide a correct terminating condition and the zipping could overflow the log. This is consistent with our problem only showing up on resume from S3 since in this case we are adding even more to the buffer that is still present from before S3. Anyway, needs more investigation... Thanks > > -Original Message- > From: Ross Philipson [mailto:ross.philip...@gmail.com] > Sent: Friday, September 11, 2015 5:16 PM > To: tboot-devel@lists.sourceforge.net > Subject: Re: [tboot-devel] TBOOT 1.8.3 fails to resume from S3 > > On 09/10/2015 03:35 PM, Ross Philipson wrote: >> I have been working on moving our project from TBOOT 1.7.0 to 1.8.3. I >> have discovered that while our 1.7.0 version of TBOOT resumes from S3 >> just fine, 1.8.3 does not. >> >> The most common symptom seems to be a hang just after TBOOT enters SMX >> mode. The hang happens at different places so I don't think it is one >> specific thing that TBOOT is doing to cause the hang. The hang can be >> short (on the order of seconds) or longs (several minutes). Then >> suddenly the platform will "unhang". It looks like the platform >> restarts quickly and goes right back in to TBOOT but it is a little >> hard to tell exactly what happens right around this point. We see this >> on every system we have tried it on. >> >> I have backed all our patches out and I still see the problem with a >> clean 1.8.3 code base. I have also tried using TBOOT with a Debian >> Jessie install and I get similar problems there. I have been comparing >> the code between the version and have so far not found anything that >> makes a difference. >> >> Any help in this matter is appreciated. >> Thanks > > I spent some time tracking this down today. If I build without these two > patches, I no longer get a hang on resume from S3: > > https://urldefense.proofpoint.com/v2/url?u=http-3A__hg.code.sf.net_p_tboot_code_rev_9040e000ccc4=BQICAg=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI=lDSLRzn8YUPmwjLuy9Ek9Dy-T15T3uK505eKqf1EFfg=LAxK0DGQNQEDu2T5Lov2U5XNSelVt93H8xUJDDWj864=pJ6y0vwTNPdTGh85FoFOBH4j9WSTx-I4p0Ncr3n1i1I= > https://urldefense.proofpoint.com/v2/url?u=http-3A__hg.code.sf.net_p_tboot_code_rev_78713e04bdd9=BQICAg=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI=lDSLRzn8YUPmwjLuy9Ek9Dy-T15T3uK505eKqf1EFfg=LAxK0DGQNQEDu2T5Lov2U5XNSelVt93H8xUJDDWj864=eszD9yhtQidHK6kMeMRcXUsjs_0u_frsAZENAWez6zA= > > I have not identified the exact cause yet but I wanted to get these results > posted to the list. > > Thanks > > -- > Ross Philipson > > -- > ___ > tboot-devel mailing list > tboot-devel@lists.sourceforge.net > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_tboot-2Ddevel=BQICAg=IV_clAzoPDE253xZdHuilRgztyh_RiV3wUrLrDQYWSI=lDSLRzn8YUPmwjLuy9Ek9Dy-T15T3uK505eKqf1EFfg=LAxK0DGQNQEDu2T5Lov2U5XNSelVt93H8xUJDDWj864=UHGtkbuNtbT5_PcWwQKBwJ9kDfHkcpd_iF23GT8LCmg= > -- Ross Philipson -- ___ tboot-devel mailing list tboot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tboot-devel
[tboot-devel] TBOOT 1.8.3 fails to resume from S3
I have been working on moving our project from TBOOT 1.7.0 to 1.8.3. I have discovered that while our 1.7.0 version of TBOOT resumes from S3 just fine, 1.8.3 does not. The most common symptom seems to be a hang just after TBOOT enters SMX mode. The hang happens at different places so I don't think it is one specific thing that TBOOT is doing to cause the hang. The hang can be short (on the order of seconds) or longs (several minutes). Then suddenly the platform will "unhang". It looks like the platform restarts quickly and goes right back in to TBOOT but it is a little hard to tell exactly what happens right around this point. We see this on every system we have tried it on. I have backed all our patches out and I still see the problem with a clean 1.8.3 code base. I have also tried using TBOOT with a Debian Jessie install and I get similar problems there. I have been comparing the code between the version and have so far not found anything that makes a difference. Any help in this matter is appreciated. Thanks -- Ross Philipson -- Monitor Your Dynamic Infrastructure at Any Scale With Datadog! Get real-time metrics from all of your servers, apps and tools in one place. SourceForge users - Click here to start your Free Trial of Datadog now! http://pubads.g.doubleclick.net/gampad/clk?id=241902991=/4140 ___ tboot-devel mailing list tboot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tboot-devel
Re: [tboot-devel] Follow up on TBOOT Argument Measurement Vulnerability for GRUB2 + ELF Kernels
On 08/12/2015 12:50 PM, Sun, Ning wrote: Hi Ross, Thanks your for bring this up, there are some questions for us to understand your usage senarios: Are you using tboot right now? Yes and I am in the process of upgrading to 1.8.3 which is why this came up. Do you use Launch Control Policy? No, we rely on extending PCRs during launch and unsealing when we reach a known measurement. What is your usage model for tboot regarding to avoid this vulnerability? We use the patch that I attached. Our older current version of tboot does not have the fix of yours that I referenced. Our solution could be a trade-off, either accept your patch and modify the user measurement process or do a comparison between 1st and 2nd parameters in current commandline. I guess what confuses us is why there is any special logic skip any module name when measuring the cmdline that the boot-loader passes in. What is the motivation to do all the work to not have the boot image name in the measurement? Thanks, -ning -Original Message- From: Ross Philipson [mailto:ross.philip...@gmail.com] Sent: Friday, August 07, 2015 12:48 PM To: tboot-devel@lists.sourceforge.net Subject: [tboot-devel] Follow up on TBOOT Argument Measurement Vulnerability for GRUB2 + ELF Kernels This is in regards to this vulnerability and the state of current fix for it. The vuln was reported by James Blake and this is the current fix for it as far as I can tell: http://hg.code.sf.net/p/tboot/code/code?cmd=changeset;node=0efdaf7c5348 In a posted message, it was pointed out that this fix is insufficient and we believe that to be true too: http://sourceforge.net/p/tboot/mailman/message/32760688/ It is not clear to me why the first item on the command line has to be skipped when it happens to be the image file name. The command line is what the boot-loader passed whether it includes a file name up front or not. It seems a much simpler and cleaner approach would be like the one from James Blake that I attached. Thanks -- Ross Philipson -- Ross Philipson -- ___ tboot-devel mailing list tboot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tboot-devel
Re: [tboot-devel] Follow up on TBOOT Argument Measurement Vulnerability for GRUB2 + ELF Kernels
On 08/12/2015 02:54 PM, Sun, Ning wrote: What is the motivation to do all the work to not have the boot image name in the measurement? Without containing boot image name in the measurement, Launch Control Policy user don't need to figure out by themselves whether the cmdline includes the boot image name, and what it is(for different boot loaders), only the arguments are measured. And if only the boot image name changed (content is same as before), LCP do not need updated. If we include image name in cmdline measurement, when tboot user measuring the cmdline, they should know that grub2 cmdline does not pass boot image name to tboot, but other boot loaders do so That will confuse and add extra effort to end user, and it looks like not a very good design for user experience. Its seems to me users would not really care very much if the image name happened to be present and measured depending on what the particular boot loader passed in. It seems it could be handled in documentation with something like Note depending on your boot loader ... and then trace out from tboot exactly what was measured. I also think that boot image names changing without the actual boot image changing is pretty unlikely. It is just my general opinion that trying to do something complicated leaves many more opportunities for risk and problems than going with the simplest solution. Anyway just my $0.02 worth... So to tboot in general, the requirement for this is that no boot image name is required in cmdline measurement and no vulnerability there. There should be various ways to implement it, we just figure out a better way... Thanks, -ning -Original Message- From: Ross Philipson [mailto:ross.philip...@gmail.com] Sent: Wednesday, August 12, 2015 9:59 AM To: Sun, Ning; tboot-devel@lists.sourceforge.net Cc: Wei, Gang Subject: Re: [tboot-devel] Follow up on TBOOT Argument Measurement Vulnerability for GRUB2 + ELF Kernels On 08/12/2015 12:50 PM, Sun, Ning wrote: Hi Ross, Thanks your for bring this up, there are some questions for us to understand your usage scenarios: Are you using tboot right now? Yes and I am in the process of upgrading to 1.8.3 which is why this came up. Do you use Launch Control Policy? No, we rely on extending PCRs during launch and unsealing when we reach a known measurement. What is your usage model for tboot regarding to avoid this vulnerability? We use the patch that I attached. Our older current version of tboot does not have the fix of yours that I referenced. Our solution could be a trade-off, either accept your patch and modify the user measurement process or do a comparison between 1st and 2nd parameters in current commandline. I guess what confuses us is why there is any special logic skip any module name when measuring the cmdline that the boot-loader passes in. What is the motivation to do all the work to not have the boot image name in the measurement? Thanks, -ning -Original Message- From: Ross Philipson [mailto:ross.philip...@gmail.com] Sent: Friday, August 07, 2015 12:48 PM To: tboot-devel@lists.sourceforge.net Subject: [tboot-devel] Follow up on TBOOT Argument Measurement Vulnerability for GRUB2 + ELF Kernels This is in regards to this vulnerability and the state of current fix for it. The vuln was reported by James Blake and this is the current fix for it as far as I can tell: http://hg.code.sf.net/p/tboot/code/code?cmd=changeset;node=0efdaf7c5348 In a posted message, it was pointed out that this fix is insufficient and we believe that to be true too: http://sourceforge.net/p/tboot/mailman/message/32760688/ It is not clear to me why the first item on the command line has to be skipped when it happens to be the image file name. The command line is what the boot-loader passed whether it includes a file name up front or not. It seems a much simpler and cleaner approach would be like the one from James Blake that I attached. Thanks -- Ross Philipson -- Ross Philipson -- ___ tboot-devel mailing list tboot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tboot-devel
Re: [tboot-devel] getting txt errorcode 0xc0001c41
-Original Message- From: dknueppel [mailto:dknuep...@online.de] Sent: Monday, May 05, 2014 12:41 PM To: Ross Philipson; dknueppel; tboot-devel@lists.sourceforge.net Subject: AW: [tboot-devel] getting txt errorcode 0xc0001c41 Hi Ross, Sorry for the delay, got an issue with my email server ... thanks for your hint. Agree, basically I have the same indexes. Even one more ... # tpmnv_getcap The response data is: 10 00 00 01 10 00 f0 00 50 00 00 03 50 00 00 01 4 indices have been defined list of indices for defined NV storage areas: 0x1001 0x1000f000 0x5003 0x5001 Guess those are created already by the BIOS when enabling the TPM. Those indexes look right. They were put there by the OEM per instructions given to them for TXT configuration. Do you know further details on how to debug tboot in order to find the missing (?) index? The error is being set during the execution of the ACM. The best you could do there for debugging in my experience is static analysis of the code in the SINIT module. Someone else suggested you we using an SINIT that would not work on a server platform. It was suggested you remove the module and use the one in firmware - did that lead anywhere? If not, is there a newer SINIT module for you server platform you could download and try? Thanks a lot, Dieter -Ursprüngliche Nachricht- Von: Ross Philipson [mailto:ross.philip...@citrix.com] Gesendet: Montag, 28. April 2014 20:38 An: dknueppel; tboot-devel@lists.sourceforge.net Betreff: Re: [tboot-devel] getting txt errorcode 0xc0001c41 On 04/26/2014 02:09 AM, dknueppel wrote: Hi, I'm getting txt error code 0xc0001c41 with rebooting the system afterwards. Mainboard Intel S1200RPL CPU XEON E3-1265L TPM AXXTPME5 BootBIOS (i.e. no EFI, EFI boot shows identical behavior) DistributionUbuntu 14.04 w/ tboot 1.8 SINIT 4th_gen_i5_i7_SINIT_75.BIN Attached below how the TPM is set up and the tboot dump. I don't have any clue why I'm still getting the error. According to SINIT_Errors.pdf error indicates Invalid TPM NV index You may be missing some NV indexes that the OEM is supposed to put there. For example on my Dell 6430 where I am using the TXT/TPM I have: # tpmnv_getcap The response data is: 10 00 00 01 50 00 00 01 50 00 00 03 3 indices have been defined list of indices for defined NV storage areas: 0x1001 0x5001 0x5003 The second two need to be there - the are LCP related indexes (0x5001 is LCP supplier and 0x5003 is AUX2 IIRC). These are supposed to be create by the OEM then locked in NV RAM to prevent removal. Help pretty much appreciated. Thanks, Dieter + tpm_takeownership -z Enter owner password: Confirm password: + tpmnv_defindex -i 0x2002 -s 8 -pv 0 -rl 0x07 -wl 0x07 -p + password Tspi_NV_DefineSpace failed failed: NVRAM area already exists (0x08313b) Command DefIndex failed: TSS API failed + tpmnv_defindex -i owner -s 0x36 -p password Haven't input permission value, use default value 0x2 Successfully defined index 0x4001 as permission 0x2, data size is 54 + tpmnv_defindex -i 0x2001 -s 512 -pv 0x02 -p password Successfully defined index 0x2001 as permission 0x2, data size is 512 + rm -r tmp + mkdir tmp + cd tmp + lcp_mlehash -c logging=serial,vga,memory /boot/tboot.gz + lcp_crtpolelt --create --type mle --ctrl 0x00 --minver 0 --out + tboot_mle.elt tboot_hash lcp_crtpollist --create --out + list_unsig.lst tboot_mle.elt + lcp_crtpol2 --create --type list --ctrl 0x02 --pol owner_list.pol + --data owner_list.data list_unsig.lst lcp_writepol -i owner -f + owner_list.pol -p password Successfully write policy into index 0x4001 + cp owner_list.data /boot + tb_polgen --create --type nonfatal tcb.pol + tb_polgen --add --num 0 --pcr 18 --hash image --cmdline 'root=/dev/mapper/test--node--vg-root ro intel_iommu=on' --image /boot/vmlinuz-3.13.0-24-generic tcb.pol + tb_polgen --add --num 1 --pcr 19 --hash image --cmdline '' --image + /boot/initrd.img-3.13.0-24-generic tcb.pol lcp_writepol -i + 0x2001 -f tcb.pol -p password Successfully write policy into index 0x2001 TBOOT: *** TBOOT *** TBOOT:2014-01-30 12:00 +0800 1.8.0 TBOOT: * TBOOT: command line: logging=serial,vga,memory TBOOT: BSP is cpu 0 TBOOT: original e820 map: TBOOT: - 0009bc00 (1) TBOOT: 0009bc00 - 000a (2) TBOOT: 000e - 0010 (2) TBOOT: 0010 - bbdc7000 (1) TBOOT: bbdc7000 - be782000 (2) TBOOT: be782000 - be788000 (4) TBOOT: be788000 - be8be000 (2
Re: [tboot-devel] getting txt errorcode 0xc0001c41
= TBOOT: mle_start_off=4000 TBOOT: mle_end_off=34000 TBOOT: capabilities: 0x0027 TBOOT: rlp_wake_getsec: 1 TBOOT: rlp_wake_monitor: 1 TBOOT: ecx_pgtbl: 1 TBOOT: stm: 0 TBOOT: pcr_map_no_legacy: 0 TBOOT: pcr_map_da: 1 TBOOT: platform_type: 0 TBOOT: max_phy_addr: 0 TBOOT: MLE start=804000, end=834000, size=3 TBOOT: ptab_size=3000, ptab_base=0x801000 TBOOT: TXT.HEAP.BASE: 0xbef2 TBOOT: TXT.HEAP.SIZE: 0xe (917504) TBOOT: bios_data (@0xbef20008, 0x56): TBOOT: version: 4 TBOOT: bios_sinit_size: 0xce40 (52800) TBOOT: lcp_pd_base: 0x0 TBOOT: lcp_pd_size: 0x0 (0) TBOOT: num_logical_procs: 8 TBOOT: flags: 0x TBOOT: ext_data_elts[]: TBOOT: BIOS_SPEC_VER: TBOOT: major: 0x2 TBOOT: minor: 0x1 TBOOT: rev: 0x0 TBOOT: ACM: TBOOT: num_acms: 1 TBOOT: acm_addrs[0]: 0xfff7d000 TBOOT: discarding RAM above reserved regions: 0xbebf - 0xbec0 TBOOT: min_lo_ram: 0x0, max_lo_ram: 0xbbdc7000 TBOOT: min_hi_ram: 0x1, max_hi_ram: 0x44000 TBOOT: no LCP module found TBOOT: os_sinit_data (@0xbef3517e, 0x7c): TBOOT: version: 6 TBOOT: flags: 0 TBOOT: mle_ptab: 0x801000 TBOOT: mle_size: 0x3 (196608) TBOOT: mle_hdr_base: 0x175a0 TBOOT: vtd_pmr_lo_base: 0x0 TBOOT: vtd_pmr_lo_size: 0xbbc0 TBOOT: vtd_pmr_hi_base: 0x1 TBOOT: vtd_pmr_hi_size: 0x34000 TBOOT: lcp_po_base: 0x0 TBOOT: lcp_po_size: 0x0 (0) TBOOT: capabilities: 0x0002 TBOOT: rlp_wake_getsec: 0 TBOOT: rlp_wake_monitor: 1 TBOOT: ecx_pgtbl: 0 TBOOT: stm: 0 TBOOT: pcr_map_no_legacy: 0 TBOOT: pcr_map_da: 0 TBOOT: platform_type: 0 TBOOT: max_phy_addr: 0 TBOOT: efi_rsdt_ptr: 0x0 TBOOT: ext_data_elts[]: TBOOT: EVENT_LOG_POINTER: TBOOT: size: 16 TBOOT:elog_addr: 0xbef30176 TBOOT: Event Log Container: TBOOT: Signature: TXT Event Container TBOOT:ContainerVer: 1.0 TBOOT: PCREventVer: 1.0 TBOOT:Size: 20480 TBOOT:EventsOffset: [48,48) TBOOT: setting MTRRs for acmod: base=0xbef0, size=0xce40, num_pages=13 TBOOT: executing GETSEC[SENTER]... -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ tboot-devel mailing list tboot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tboot-devel -- Ross Philipson -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ tboot-devel mailing list tboot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tboot-devel
Re: [tboot-devel] When !is_kernel_linux(), tboot memory is set to E820_UNUSABLE
On 05/03/2013 09:25 PM, Konrad Rzeszutek Wilk wrote: Oh I am sorry - I gave you incorrect information. We are not seeing the crash on our xenified 2.6.32 kernel. We just started seeing it in our newer 3.2 pvops kernel. Sorry for the confusion. I would suggest you try the v3.9 kernel to see if the problem shows up. There were fixes in arch/x86/xen/setup.c and arch/x86/xen/p2m.c that might cause this. I know we are working on moving to a 3.8 kernel. At the very least we can diff them and see if we can identify the fixes and try them. (XEN) mm.c:901:d0 Error getting mfn 800 (pfn ) from L1 entry 00800403 for l1e_owner=0, pg_owner=0 (XEN) mm.c:4976:d0 ptwr_emulate: could not get_page_from_l1e() And earlier: [0.00] init_memory_mapping: -36ffe000 is a bit odd. It is trying to map only up to 36ffe000. Thought it also reminds me of an clipped MTRR issue that Stefan Bader found - take a look in the xen-devel archives and see.I think the fix was a one line change in the Linxu code but I can't recall the details What you need to figure out is why the M2P (so DIRECTMAP from Xen) is giving dom0 the 14060 MFN value for some PTE. Ok we will try hunting those issues down. Thanks a lot for the help Konrad. Thanks -- Ross Philipson -- Ross Philipson -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ tboot-devel mailing list tboot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tboot-devel
[tboot-devel] When !is_kernel_linux(), tboot memory is set to E820_UNUSABLE
We have been looking at the code in tboot.c that sets the tboot memory area to E820_UNUSABLE when it detects that the next module is not Linux. Specifically this code: uint32_t mem_type = is_kernel_linux() ? E820_RESERVED : E820_UNUSABLE; And this commit: http://hg.code.sf.net/p/tboot/code/rev/b170b7b39e5c It seems to make sense to set the region to reserved but we do not understand why the region is set to unusable in the other case. Can someone explain the reasoning behind this? Also, the check for is_kernel_linux() relies on it not being an elf image but this doesn't seem very correct. Not being an elf image does not imply it is a Linux kernel. Are you relying on the fact that only Linux and Xen are used with tboot at the moment? Thanks, Ross Philipson -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ tboot-devel mailing list tboot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tboot-devel
[tboot-devel] [PATCH] Fix lcptools makefile
Patch attached: The removal of Trousers from the build introduced a build issue in the lcptools/Makefile where -ltspi is listed as a build target and causes building to fail. Signed-off-by: Ross Philipson ross.philip...@citrix.commailto:ross.philip...@citrix.com tboot-broken-makefile.patch Description: tboot-broken-makefile.patch -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev___ tboot-devel mailing list tboot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tboot-devel
