You can subscribe to this list here.
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
(13) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2008 |
Jan
(19) |
Feb
(24) |
Mar
(8) |
Apr
(14) |
May
(8) |
Jun
(10) |
Jul
(14) |
Aug
(3) |
Sep
(13) |
Oct
(27) |
Nov
(39) |
Dec
(24) |
2009 |
Jan
(19) |
Feb
(4) |
Mar
(2) |
Apr
(15) |
May
|
Jun
(2) |
Jul
(44) |
Aug
(21) |
Sep
(20) |
Oct
(2) |
Nov
(1) |
Dec
(7) |
2010 |
Jan
(7) |
Feb
(10) |
Mar
(2) |
Apr
(12) |
May
(7) |
Jun
(2) |
Jul
(18) |
Aug
(11) |
Sep
(4) |
Oct
(25) |
Nov
(8) |
Dec
(1) |
2011 |
Jan
(27) |
Feb
(2) |
Mar
(19) |
Apr
(8) |
May
(16) |
Jun
(11) |
Jul
(9) |
Aug
(9) |
Sep
(35) |
Oct
(9) |
Nov
(8) |
Dec
(32) |
2012 |
Jan
(37) |
Feb
(20) |
Mar
(2) |
Apr
(24) |
May
(4) |
Jun
(3) |
Jul
(5) |
Aug
(21) |
Sep
(8) |
Oct
(15) |
Nov
(1) |
Dec
(7) |
2013 |
Jan
(4) |
Feb
(8) |
Mar
(38) |
Apr
(9) |
May
(42) |
Jun
(4) |
Jul
(21) |
Aug
(4) |
Sep
|
Oct
(7) |
Nov
(2) |
Dec
(3) |
2014 |
Jan
(8) |
Feb
(8) |
Mar
(5) |
Apr
(9) |
May
(19) |
Jun
(1) |
Jul
(10) |
Aug
(25) |
Sep
(6) |
Oct
(2) |
Nov
(5) |
Dec
(1) |
2015 |
Jan
|
Feb
|
Mar
(5) |
Apr
|
May
(12) |
Jun
|
Jul
(2) |
Aug
(5) |
Sep
(11) |
Oct
(5) |
Nov
(3) |
Dec
(1) |
2016 |
Jan
(2) |
Feb
(24) |
Mar
|
Apr
(6) |
May
(26) |
Jun
(20) |
Jul
(8) |
Aug
(15) |
Sep
(21) |
Oct
(1) |
Nov
(7) |
Dec
(24) |
2017 |
Jan
(12) |
Feb
(2) |
Mar
(6) |
Apr
(8) |
May
(18) |
Jun
(13) |
Jul
(12) |
Aug
(8) |
Sep
(5) |
Oct
(1) |
Nov
|
Dec
|
2018 |
Jan
(2) |
Feb
(12) |
Mar
(8) |
Apr
(5) |
May
(7) |
Jun
(1) |
Jul
(4) |
Aug
(8) |
Sep
(2) |
Oct
(3) |
Nov
(4) |
Dec
(3) |
2019 |
Jan
(8) |
Feb
|
Mar
(2) |
Apr
|
May
(3) |
Jun
(4) |
Jul
(1) |
Aug
|
Sep
(8) |
Oct
(6) |
Nov
(20) |
Dec
(14) |
2020 |
Jan
(25) |
Feb
(12) |
Mar
(2) |
Apr
(13) |
May
(44) |
Jun
(9) |
Jul
|
Aug
(3) |
Sep
(5) |
Oct
(4) |
Nov
(2) |
Dec
|
2021 |
Jan
(6) |
Feb
|
Mar
(7) |
Apr
(1) |
May
|
Jun
(2) |
Jul
|
Aug
(16) |
Sep
(4) |
Oct
(6) |
Nov
(1) |
Dec
(6) |
2022 |
Jan
(5) |
Feb
(4) |
Mar
(22) |
Apr
(6) |
May
(4) |
Jun
(17) |
Jul
(2) |
Aug
|
Sep
|
Oct
(2) |
Nov
(1) |
Dec
(2) |
2023 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
2024 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Christopher B. <sal...@gm...> - 2024-01-29 16:12:06
|
On 1/29/24 02:31, Florian Weimer wrote: > As far as I can tell, this warning is both technically correct and > harmless. The called generate_composite_hash hash function only writes > SHA1_DIGEST_SIZE bytes and uses byte accesses. > > Thanks, > Florian > > diff --git a/lcptools-v2/pconf_legacy.c b/lcptools-v2/pconf_legacy.c > index 443b5cd5525b9fe1..5ebc6c451f7008b1 100644 > --- a/lcptools-v2/pconf_legacy.c > +++ b/lcptools-v2/pconf_legacy.c > @@ -324,7 +324,7 @@ static lcp_policy_element_t *create(void) > ERROR("Error: no pcrs were selected.\n"); > return NULL; > } > - digest = malloc(SHA1_DIGEST_SIZE); > + digest = malloc(sizeof(*digest)); > if (digest == NULL) { > ERROR("Error: failed to allocate memory for digest buffer.\n"); > return NULL; > > > > _______________________________________________ > tboot-devel mailing list > tbo...@li... > https://lists.sourceforge.net/lists/listinfo/tboot-devel That's not the only patch that file needed. When I submitted the original patch to use the correct algorithm, I missed a line. |
From: Florian W. <fw...@re...> - 2024-01-29 08:32:15
|
As far as I can tell, this warning is both technically correct and harmless. The called generate_composite_hash hash function only writes SHA1_DIGEST_SIZE bytes and uses byte accesses. Thanks, Florian diff --git a/lcptools-v2/pconf_legacy.c b/lcptools-v2/pconf_legacy.c index 443b5cd5525b9fe1..5ebc6c451f7008b1 100644 --- a/lcptools-v2/pconf_legacy.c +++ b/lcptools-v2/pconf_legacy.c @@ -324,7 +324,7 @@ static lcp_policy_element_t *create(void) ERROR("Error: no pcrs were selected.\n"); return NULL; } - digest = malloc(SHA1_DIGEST_SIZE); + digest = malloc(sizeof(*digest)); if (digest == NULL) { ERROR("Error: failed to allocate memory for digest buffer.\n"); return NULL; |
From: Timo L. <tim...@ik...> - 2023-12-20 16:10:57
|
Hi, a Debian 12 installation with tboot stopped working when I upgraded BIOS from version 2.4.2 to version 2.9.0. Instead of a normal boot the system just resets and BIOS tells me that "There was an error during TXT SNIT ACM invocation on the previous boot. Verify that the SINIT ACM used is compatible with this platform and with the OS loader." Here's more info: Hardware: Dell PowerEdge R420 Boot mode: BIOS TPM version: 1.2 CPUs: 2 x Intel(R) Xeon(R) CPU E5-2430 0 @ 2.20GHz tboot package version: 1.10.5-4 intel-acm package version: 20210710-2 The serial console logs are available at the following URLs: https://lindi.iki.fi/lindi/tboot/Dell_PowerEdge_R420_BIOS_2.4.2_serial.txt https://lindi.iki.fi/lindi/tboot/Dell_PowerEdge_R420_BIOS_2.9.0_serial.txt Reverting back to the old BIOS version resolved the issue but I guess this should be investigated? -Timo |
From: Heting W. <me...@im...> - 2023-08-16 18:13:15
|
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 } |
From: Matthias G. <mge...@su...> - 2023-05-31 08:40:53
|
Hello list, a customer is experiencing a regression using tboot in some new hardware/boot environment. Their boot gets stuck in the call to move_modules(), producing the following log: TBOOT: no LCP module found TBOOT: This is an ELF32 file. TBOOT: kernel is ELF format TBOOT: 0x6ff000 bytes copied from 0x101000 to 0x364f000 TBOOT: loader context was moved from 0x100130 to 0x364e130 The next logline that should occur "move modules to high memory" never shows up. An engineer on the customer side identified the likely cause of this; quote: > Looks like this is a bug in tboot... in move_modules(), it tries to copy the MBI > and any modules that are loaded below tboot to memory above tboot--but due to > faulty logic in an if/then, it is not copying the MBI if its address is below > tboot & below the lowest module's address. > > You can see that with the tboot messages: > > TBOOT: 0x6ff000 bytes copied from 0x101000 to 0x3586000 > TBOOT: loader context was moved from 0x100130 to 0x3585130 > > The loader context (MBI) was not moved, so when it tries to access it at the new > location, it may see no modules, or it may get bad info, just depending on what > happens to me in that memory. > > The latest upstream code appears to have this bug, also. I have attached the suggested patch to this email. Can you please review the patch and apply it to the repository if the analysis is correct? Thanks Matthias -- Matthias Gerstner <mat...@su...> Security Engineer https://www.suse.com/security GPG Key ID: 0x14C405C971923553 SUSE Software Solutions Germany GmbH HRB 36809, AG Nürnberg Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman |
From: Eric Li <lix...@gm...> - 2023-05-09 22:16:29
|
I recently found that in tboot/include/txt/heap.h, os_mle_data_t defines saved_misc_enable_msr with type uint32_t. However, MSRs contain 64 bits, so uint64_t should be used. The consequence of this bug is that in tboot/txt/txt.c, "os_mle_data->saved_misc_enable_msr = rdmsr(MSR_IA32_MISC_ENABLE);" results in integer truncation. On my machine (Dell 7050 with Intel(R) Core(TM) i5-7600 CPU @ 3.50GHz), I see that IA32_MISC_ENABLE before SENTER is 0x4000840089. However, IA32_MISC_ENABLE after SENTER is restored to 0x840089, where the 34th bit is lost. This bug appears in tboot-1.11.1, it also appears in the latest version on sourceforge: https://sourceforge.net/p/tboot/code/ci/20d511/tree/tboot/include/txt/heap.h#l288 Could you please fix this bug in tboot? Thank you. |
From: Dr. G. <gr...@en...> - 2023-02-04 06:06:07
|
Good evening, I hope the week has gone well for everyone. On behalf of the Quixote team: Izzy the Golden Retriever, Maria, John and myself; I am pleased to announce the initial release of the Quixote/TSEM Trust Orchestration System. We believe it uniquely positions Linux to demonstrate a new approach to security and security co-processor architectures. Quixote/TSEM is based on the notion, that like all other physical phenomenon, the security state of a platform or workload can be mathematically modeled. The objective is to provide for Linux security what Docker did for Linux namespace technology. There are two major components to this architecture. TSEM is the Trusted Security Event Modeling system. It is a new Linux Security Module implementation, that at a conceptual level, is a blending of integrity measurement and mandatory access controls. It treats the LSM hooks as the basis set for a functional description of the security state of a system. Quixote is the userspace software stack that makes the TSEM LSM useful. It implements the concept of a Trust Orchestration System (TOS). A trust orchestration environment is designed to keep a platform or workload in a known trust state. It thus implements the notion of prospective trust rather than the retrospective trust model available with TPM based architectures. A patch series implementing the TSEM LSM has been submitted to the linux-security-module list for review and inclusion in the upstream kernel. The source code for the Quixote TOS and pre-compiled binaries for the userspace tooling can be found at the following URL: ftp://ftp.enjellic.com/pub/Quixote The source release includes a selection of TMA's that include Xen, SGX and micro-controller implementations. The kernel patches include a documentation file, that we believe, thoroughly discusses the rationale and implementation of the new architecture. To avoid further indemnifying my reputation for loquaciousness in e-mail, I will defer interested parties to that document for further discussion. The document is also included in the Quixote source code release for those who choose to download that. In addition to initiating a discussion on a different approach to security, we hope that this release keeps Casey Schaufler from turning more blue than he already is. Given that I had mentioned to him two months ago that a new LSM would become available, "in a couple of weeks", that may influence conversations on changes to the Linux LSM architecture that are being discussed. Such is the state of software development.... :-) I would be more than happy to field any additional questions that may be forthcoming. Best wishes for a pleasant weekend. As always, Dr. Greg The Quixote Project - Flailing at the Travails of Cybersecurity |
From: Randzio, P. <paw...@in...> - 2023-01-25 09:32:51
|
Hi Łukasz, Sorry for not responding to your e-mail earlier, but somehow it failed to reach me through both of my inboxes. Thank you for pointing out that memory overlap issue, I was not aware of this. And as I've mentioned in the new commit message: when I tested it on some of our platforms (Xeons mostly) they didn't have much of an issue with this (somehow), that's why I did not expect anything to come up. The motivation was to unlock the possible length of logs a little bit, because high core count CPUs had only several hundred lines of VMXOFF in them. Now I know that we will need to do it some other way Anyway - thanks for the heads-up and sorry for that mess :) Best regards, Paweł --------------------------------------------------------------------- Intel Technology Poland sp. z o.o. ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | Kapital zakladowy 200.000 PLN. Spolka oswiadcza, ze posiada status duzego przedsiebiorcy w rozumieniu ustawy z dnia 8 marca 2013 r. o przeciwdzialaniu nadmiernym opoznieniom w transakcjach handlowych. Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiekolwiek przegladanie lub rozpowszechnianie jest zabronione. This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by others is strictly prohibited. |
From: Łukasz H. <lu...@ha...> - 2022-12-27 21:56:22
|
Hi Paweł On Thu, 2022-12-22 at 15:13 +0000, 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 0x90000. 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 |
From: Christopher B. <sal...@gm...> - 2022-12-26 20:08:34
|
This got missed for the current version, so I'm resubmitting for the next version: # HG changeset patch # User Christopher Byrne <sal...@gm...> # Date 1672084560 21600 # Mon Dec 26 13:56:00 2022 -0600 # Node ID de13f5fe8812350a662e411d5253067a2bb3e3b6 # Parent 4a904a608c70468d3156341dd9132233c4c4ff5b lcptools-v2/pconf_legacy.c: Add missing BE size_of_pcrs to hash buffer First fix attempt was almost correct. System still doesn't boot with PCONF element. I forgot 1 important line though. Once added, the system now boots with the PCONF element. Tested with both 1 PCR and 2 PCRs. Signed-of-by: Christopher Byrne <sal...@gm...> diff -r 4a904a608c70 -r de13f5fe8812 lcptools-v2/pconf_legacy.c --- a/lcptools-v2/pconf_legacy.c Fri Dec 23 10:15:47 2022 +0100 +++ b/lcptools-v2/pconf_legacy.c Mon Dec 26 13:56:00 2022 -0600 @@ -241,6 +241,7 @@ ERROR("Error: failed to allocate buffer for composite digest.\n"); return false; } + buff->size_of_pcrs = htonl(no_of_pcrs * SHA1_DIGEST_SIZE); memcpy_s( &buff->pcr_selection, sizeof buff->pcr_selection, |
From: Miguel M. <mig...@ua...> - 2022-11-29 18:45:18
|
Hi, Łukasz, First, thanks for the previous answer. It has helped me move forward with remote attestation. While implementing the remote attestation procedure, I attempted to extend the TPM's PCRs further. More precisely, PCR 21 is locked behind locality 2. Therefore only a trusted OS can extend it. However, I can't extend that PCR, even though the txt-stat tool shows the following: "TXT measured launch: TRUE secrets flag set: TRUE ... locality_1_open: TRUE locality_2_open: TRUE " The tpm2_pcrwrite command returns the following error: " tpm:warn(2.0): bad locality " So, from the previous message explanation, I can't write an LCP due to some platform misconfigurations. These configurations don't allow me to write the LCP to the expected NVINDEX. I wrote a VLP instead, which up until this point, was working as expected. Is using a VLP instead of an LCP the reason for not being able to write to locality 2 PCRs? Or is there something else I'm missing on? Best Regards, Miguel Mota ________________________________ De: Łukasz Hawryłko <lu...@ha...> Enviado: 10 de outubro de 2022 10:01 Para: Miguel Mota <mig...@ua...>; tbo...@li... <tbo...@li...> Assunto: Re: [tboot-devel] TBOOT on a PowerEdge R730 with a TPM2.0 Hi Miguel On Fri, 2022-10-07 at 14:30 +0000, 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 |
From: Łukasz H. <lu...@ha...> - 2022-10-10 09:26:46
|
Hi Miguel On Fri, 2022-10-07 at 14:30 +0000, 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 |
From: Miguel M. <mig...@ua...> - 2022-10-07 16:02:46
|
Hi, Lately I've been trying to get tboot to work on a Dell PowerEdge R730 with the latest bios (v2.15.0). In v2.15.0 the BIOS and SINIT ACM were updated to v3.1.5_20211209 according to the Dell change log. The machine is equiped with a TPM2.0 and prior to the following tests no actions were taken with it (important for later). So, I installed tboot (v1.9.12) and the default policy worked straight away. First thing that I noticed was that it was looking for a VLP at NVIndex 0x01200001 but didn't show where it was looking for the LCP. From reading the manuals and some other mailing lists (this one for example: https://sourceforge.net/p/tboot/mailman/message/36754984/) and from the information presented by tboot I reached this conclusion: My TPM2.0 NVIndex Set is 0 based on the information below: TBOOT: TPM info list: TBOOT: TPM capability: TBOOT: ext_policy: 0x3 TBOOT: tpm_family : 0x3 TBOOT: tpm_nv_index_set : 0x0 TBOOT: alg count: 3 TBOOT: alg_id: 0x4 TBOOT: alg_id: 0xb TBOOT: alg_id: 0x14 Therefore the relevant TPM2 NVRAM indexes are as follows (also supported by tboot/common/tpm_20.c line 2795-2798): PS: 0x1800001 PO: 0x1400001 AUX: 0x1800003 SGX: 0x1800004 Thus based on this I should write the LCP into nvindex 0x1400001. The problem is that if I check the current capabilities of my TPM2.0 it presents me with this information: tpm2_getcap handles-nv-index - 0x1400001 - 0x1400002 - 0x1C00002 - 0x1C00003 - 0x1C00004 - 0x1C0000A - 0x1C0000B - 0x1C0000C - 0x1C10102 - 0x1C10103 - 0x1C10104 - 0x1C10105 tpm2_nvreadpublic 0x1400001 0x1400001: name: 000be7351a9ff0c7de635f31d6bd6a1d0fe6f123316614138dc3c743c78bf30edb1f hash algorithm: friendly: sha256 value: 0xB attributes: friendly: ppwrite|authwrite|write_stclear|ppread|authread|no_da|written|platformcreate|read_stclear value: 0x54005E2 size: 32 This , as far as my knowledge goes, tells me I can't clear or write to it since it is established by, in this case, Dell. For sanity of mind I also tried the new index (0x1c10106) but it would end up with an error ("An issue is observed in the previous invocation of TXT SINIT Authenticated Code Module (ACM) because the TXT information stored in the TPM chip may be corrupted.") during boot. I confirmed the information presented in the tpm with the tools used for generating (--show --verbose) and nothing was corrupted, so this index is clearly not the one I want. So, what should regarding this issue? Or where should I place the LCP? I'm using the following commands for generating and written the LCP to the TPM. lcp2_mlehash --create --alg sha256 --cmdline "logging=serial,memory" /boot/tboot.gz > mle_hash lcp2_crtpolelt --create --type mle2 --minver 17 --alg sha256 --out mle.elt mle_hash tb_polgen --create --alg sha256 --type continue vl.pol tb_polgen --add --num 0 --pcr 19 --hash image --cmdline "$(</proc/cmdline) intel_iommu=on noefi" --image "/boot/vmlinuz-$(uname -r)" vl.pol tb_polgen --add --num 1 --pcr 20 --hash image --image "/boot/initrd-$(uname -r)" vl.pol lcp2_crtpolelt --create --type custom --out vl.elt --uuid tboot vl.pol lcp2_crtpollist --create --listver 0x300 --out list_unsig.lst mle.elt pcr.elt vl.elt cp list_unsig.lst list_sig.lst lcp2_crtpollist --sign 0x8 --sigalg rsapss --hashalg sha256 --pub pub.pem --priv priv.pem --out list_sig.lst lcp2_crtpol --create --alg sha256 --polver 3.2 --type list --pol list.pol --data list.data list_sig.lst tpm2_nvdefine -s $(( 38 + 32 )) -a 'ownerwrite|policywrite|authread|no_da' 0x01400001 tpm2_nvwrite -i list.pol 0x01400001 sudp cp list.data /boot Since I couldn't find (and hope to find out what is the problem with this mail), instead of writting the LCP I write the VLP (vl.pol) to 0x01200001. The server can reboot and the system will extend, in this specific case, the PCR 19 with the kernel+cmdline and PCR 20 with the initrd+cmdline. 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. |
From: Łukasz H. <lu...@ha...> - 2022-07-13 20:46:35
|
Hi Alex On Mon, 2022-07-11 at 13:00 -0500, Alex Olson wrote: > # HG changeset patch > # User Alex Olson <ale...@st...> > # 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 |
From: Alex O. <thi...@gm...> - 2022-07-11 18:00:35
|
# HG changeset patch # User Alex Olson <ale...@st...> # 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(). Signed-off-by: Alex Olson <ale...@st...> diff -r fa60b63892e8 -r 0552b7ac10e2 tboot/common/boot.S --- a/tboot/common/boot.S Fri Jun 17 11:39:11 2022 +0300 +++ b/tboot/common/boot.S Mon Jul 11 12:01:31 2022 -0500 @@ -400,23 +400,28 @@ .align 8 +/* Below assumes "_start" is exactly at TBOOT_START and is needed to allow arithmetic: */ +#define INT_HANDLER_ADDR (int_handler - _start + TBOOT_START) +#define INT_HANDLER_LO16 (INT_HANDLER_ADDR & 0xffff) +#define INT_HANDLER_HI16 (INT_HANDLER_ADDR >> 16) + idt_table: .rept 18 - .word int_handler - _start + .word INT_HANDLER_LO16 .word cs_sel .word 0x8e00 /* present, DPL=0, 32b, interrupt */ - .word (int_handler - _start + TBOOT_START) >> 16 + .word INT_HANDLER_HI16 .endr /* for machine-check exception */ - .word int_handler - _start + .word INT_HANDLER_LO16 .word cs_sel .word 0x8f00 /* present, DPL=0, 32b, trap */ - .word (int_handler - _start + TBOOT_START) >> 16 + .word INT_HANDLER_HI16 .rept 237 - .word int_handler - _start + .word INT_HANDLER_LO16 .word cs_sel .word 0x8e00 /* present, DPL=0, 32b, interrupt */ - .word (int_handler - _start + TBOOT_START) >> 16 + .word INT_HANDLER_HI16 .endr idt_table_end: |
From: Timo L. <tim...@ik...> - 2022-06-19 21:19:44
|
Hi, please consider the attached patch. Currently tboot respects CFLAGS and LDFLAGS from the environment but not CPPFLAGS. -Timo |
From: Timo L. <tim...@ik...> - 2022-06-19 21:17:37
|
Hi, please consider the attached patch to help make tboot builds reproducible. Currently using -Werror -Wdate-time causes the build to fail. The option -Wdate-time is described as: "Warn when macros __TIME__, __DATE__ or __TIMESTAMP__ are encountered as they might prevent bit-wise-identical reproducible compilations." -Timo |
From: Tony C. <tc...@re...> - 2022-06-18 14:36:33
|
On 6/18/2022 8:08 AM, lukasz hawrylko wrote: > Re: [PATCH] 20_linux_tboot: efi logic was inverted > '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. You are correct. The chain of trust does not include the EFI runtime. The system having the problem was using VROC. Intel confirms that VROC cannot operate without EFI. They also confirmed the logical conclusion that tboot and VROC are incompatible. So, this is not a bug. |
From: Łukasz H. <lu...@ha...> - 2022-06-17 21:45:27
|
Hi Tony On Thu, 2022-06-09 at 15:04 -0400, Tony Camuso wrote: > # HG changeset patch > # User Tony Camuso <tc...@re...> > # 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_tboot Thu Mar 17 23:58:50 2022 +0200 > +++ b/tboot/20_linux_tboot Thu 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 |
From: Timo L. <tim...@ik...> - 2022-06-14 07:41:34
|
Hi, that's good to hear, thanks for the quick reply. Would it be possible to include the license text in the zip file in the future? It is difficult to get this through review if the license is not included. Also, how can I know when a new version is available? I don't have a login to the Intel site. Alternatively, would it be possible to have the ACMs available in a more public website like https://www.intel.com/content/www/us/en/developer/articles/tool/intel-trusted-execution-technology.html that already requires users to read the license before downloading? -Timo On Mon, 13 Jun 2022, Bhungal, Jeevan S wrote: > Hi Timo, > > It is the same license, so no change. > > > Jeevan Bhungal > Client Security Technologist | CCG-CPE-CCE > CCE Security Champion > D 916.377.1013 | M 530.844.0930 > Intel Corporation | intel.com > > -----Original Message----- > From: Timo Lindfors <tim...@ik...> > Sent: Monday, June 13, 2022 1:13 AM > To: Jason Andryuk <jan...@gm...> > Cc: Bhungal, Jeevan S <jee...@in...>; Gupta, Rahul Kumar <rah...@in...>; Fedko, Artem <art...@in...>; Crain, Keegan <kee...@in...>; Parmeter, Ben <ben...@in...>; tbo...@li...; Sehra, Supreeti <sup...@in...> > Subject: Re: [tboot-devel] 11th Gen SINIT ACM > > Hi, > > On Mon, 25 Apr 2022, Jason Andryuk wrote: >>> >>> https://cdrdv2.intel.com/v1/dl/getContent/630744?explicitVersion=true >>> >>> Jeevan Bhungal >> >> Great! Yeah, the internal link does not work, but the direct link >> does. Thank you, Jeevan. > > The direct link works but does not seem to contain any license information, just a PDF that says > > "No license (express or implied, by estoppel or otherwise) to any > intellectual property rights is granted by this document." > > I'd like to include these in the Debian non-free package intel-acm. This package currently holds ACM modules published at > > https://www.intel.com/content/www/us/en/developer/articles/tool/intel-trusted-execution-technology.html > > under the following license: > > """ > Copyright (c) 2007 - 2011, Intel(R) Corporation. > All rights reserved. > Redistribution > Redistribution and use in binary form, without modification, are permitted provided that the following conditions are met: > > Redistributions must reproduce the above copyright notice and the following disclaimer in the documentation and/or other materials provided with the distribution. > Neither the name of Intel Corporation nor the names of its suppliers may be used to endorse or promote products derived from this software without specific prior written permission. > No reverse engineering, decompilation, or disassembly of this software is permitted. > > Limited patent license > Intel Corporation grants a world-wide, royalty-free, non-exclusive license under patents it now or hereafter owns or controls to make, have made, use, import, offer to sell and sell ("Utilize") this software, but solely to the extent that any such patent is necessary to Utilize the software alone. The patent license shall not apply to any combinations which include this software. No hardware per se is licensed hereunder. > DISCLAIMER > THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. > > """ > > Is Intel licensing these new files also under the same license or has the license changed? > > > -Timo > > |
From: Bhungal, J. S <jee...@in...> - 2022-06-13 18:11:42
|
Hi Timo, It is the same license, so no change. Jeevan Bhungal Client Security Technologist | CCG-CPE-CCE CCE Security Champion D 916.377.1013 | M 530.844.0930 Intel Corporation | intel.com -----Original Message----- From: Timo Lindfors <tim...@ik...> Sent: Monday, June 13, 2022 1:13 AM To: Jason Andryuk <jan...@gm...> Cc: Bhungal, Jeevan S <jee...@in...>; Gupta, Rahul Kumar <rah...@in...>; Fedko, Artem <art...@in...>; Crain, Keegan <kee...@in...>; Parmeter, Ben <ben...@in...>; tbo...@li...; Sehra, Supreeti <sup...@in...> Subject: Re: [tboot-devel] 11th Gen SINIT ACM Hi, On Mon, 25 Apr 2022, Jason Andryuk wrote: >> >> https://cdrdv2.intel.com/v1/dl/getContent/630744?explicitVersion=true >> >> Jeevan Bhungal > > Great! Yeah, the internal link does not work, but the direct link > does. Thank you, Jeevan. The direct link works but does not seem to contain any license information, just a PDF that says "No license (express or implied, by estoppel or otherwise) to any intellectual property rights is granted by this document." I'd like to include these in the Debian non-free package intel-acm. This package currently holds ACM modules published at https://www.intel.com/content/www/us/en/developer/articles/tool/intel-trusted-execution-technology.html under the following license: """ Copyright (c) 2007 - 2011, Intel(R) Corporation. All rights reserved. Redistribution Redistribution and use in binary form, without modification, are permitted provided that the following conditions are met: Redistributions must reproduce the above copyright notice and the following disclaimer in the documentation and/or other materials provided with the distribution. Neither the name of Intel Corporation nor the names of its suppliers may be used to endorse or promote products derived from this software without specific prior written permission. No reverse engineering, decompilation, or disassembly of this software is permitted. Limited patent license Intel Corporation grants a world-wide, royalty-free, non-exclusive license under patents it now or hereafter owns or controls to make, have made, use, import, offer to sell and sell ("Utilize") this software, but solely to the extent that any such patent is necessary to Utilize the software alone. The patent license shall not apply to any combinations which include this software. No hardware per se is licensed hereunder. DISCLAIMER THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. """ Is Intel licensing these new files also under the same license or has the license changed? -Timo |
From: Timo L. <tim...@ik...> - 2022-06-13 10:16:02
|
Hi, On Mon, 25 Apr 2022, Jason Andryuk wrote: >> >> https://cdrdv2.intel.com/v1/dl/getContent/630744?explicitVersion=true >> >> Jeevan Bhungal > > Great! Yeah, the internal link does not work, but the direct link > does. Thank you, Jeevan. The direct link works but does not seem to contain any license information, just a PDF that says "No license (express or implied, by estoppel or otherwise) to any intellectual property rights is granted by this document." I'd like to include these in the Debian non-free package intel-acm. This package currently holds ACM modules published at https://www.intel.com/content/www/us/en/developer/articles/tool/intel-trusted-execution-technology.html under the following license: """ Copyright (c) 2007 - 2011, Intel(R) Corporation. All rights reserved. Redistribution Redistribution and use in binary form, without modification, are permitted provided that the following conditions are met: Redistributions must reproduce the above copyright notice and the following disclaimer in the documentation and/or other materials provided with the distribution. Neither the name of Intel Corporation nor the names of its suppliers may be used to endorse or promote products derived from this software without specific prior written permission. No reverse engineering, decompilation, or disassembly of this software is permitted. Limited patent license Intel Corporation grants a world-wide, royalty-free, non-exclusive license under patents it now or hereafter owns or controls to make, have made, use, import, offer to sell and sell ("Utilize") this software, but solely to the extent that any such patent is necessary to Utilize the software alone. The patent license shall not apply to any combinations which include this software. No hardware per se is licensed hereunder. DISCLAIMER THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. """ Is Intel licensing these new files also under the same license or has the license changed? -Timo |
From: Tony C. <tc...@re...> - 2022-06-11 22:51:08
|
CORRECTION > I'm using a RHEL-8.5 based on 5.14 kernel. CentOS 8.5 is the same thing. ^^^^ That's a 4.18 kernel, NOT a 5.14 kernel. |
From: Tony C. <tc...@re...> - 2022-06-11 22:49:16
|
On 6/11/2022 1:41 PM, Timo Lindfors wrote: > On Sat, 11 Jun 2022, Tony Camuso wrote: >> OK, so something is going wrong with the information that tboot is >> forwarding to the kernel launch. >> >> On the efi system, with "noefi" removed from the grub command line, >> the system boots. >> >> With "noefi" in the grub command line, Device Mapper cannot find >> the root and swap devices and drops to the dracut prompt. >> >> How can I determine what info efi is providing that tboot is not? >> >> Where can I instrument the code to gain that visibility? > > I'm not too familiar with dracut but I'd imagine you can unpack the initramfs and investigate how it works. It might be easiest to spawn a shell at some point. > > Can you reproduce the problem if you do a fresh install? What distribution is this? If you have easy steps to reproduce this I can try to take a look. I'm normally on Debian so will need good instructions for other distros :) > > -Timo > I'm using a RHEL-8.5 based on 5.14 kernel. CentOS 8.5 is the same thing. You can probably reproduce it on a debian system with storage configured as VROC RAID. You will need a motherboard and intel cpu that can implement VROC RAID. lenovo-st250v2 is the platform I'm using to reproduce the problem. See... https://www.intel.com/content/www/us/en/support/articles/000026106/memory-and-storage/ssd-software.html https://www.intel.com/content/www/us/en/support/articles/000030445/memory-and-storage/ssd-management-tools.html RAID info ==================================================================== # cat /proc/mdstat Personalities : [raid0] md126 : active raid0 sda[1] sdb[0] 1855842304 blocks super external:/md127/0 128k chunks md127 : inactive sda[1](S) sdb[0](S) 10402 blocks super external:imsm unused devices: <none> # cat /etc/mdadm.conf # mdadm.conf written out by anaconda MAILADDR root AUTO +imsm +1.x -all ARRAY /dev/md/Volume0_0 UUID=8061c4cf:06de8a59:a9eefb7e:3edb011a ARRAY /dev/md/imsm UUID=549c2ba4:1e03463b:d429e75b:398c67a3 --------------------------------------------------------------------- Physical Volume, Volume Group, and Logical Volume info ===================================================================== # pvs PV VG Fmt Attr PSize PFree /dev/md126p3 rhel_lenovo-st250v2-02 lvm2 a-- <1.73t 0 # vgs VG #PV #LV #SN Attr VSize VFree rhel_lenovo-st250v2-02 1 4 0 wz--n- <1.73t 0 # lvs LV VG Attr LSize home rhel_lenovo-st250v2-02 -wi-ao---- 500.00g root rhel_lenovo-st250v2-02 -wi-ao---- 70.00g swap rhel_lenovo-st250v2-02 -wi-ao---- 31.47g work rhel_lenovo-st250v2-02 -wi-ao---- <1.14t ----------------------------------------------------------------------- By the time initramfs is running, it's too late, since the Device Mapper cannot find the logical volumes. ************* * NOTE * ************* There are differences in the memmap that tboot hands off to the initramfs with and without the "noefi" directive. Failed with "noefi" =================== TBOOT: get_highest_sized_ram: size 14e99600 -> base 62585000, size 24949000 : ^^^^^^^^ ^^^^^^^^ TBOOT: /swap console=ttyS0,115200N81 intel_iommu=on noefi TBOOT: EFI memmap: memmap base: 0x69808, memmap size: 0x14a0 ^^^^^^^ ^^^^^^ Successful boot with efi ======================== TBOOT: get_highest_sized_ram: size 14e99600 -> base 62045000 size 24789000 : ^^^^^^^^ ^^^^^^^^ TBOOT: /swap console=ttyS0,115200N81 intel_iommu=on TBOOT: EFI memmap: memmap base: 0x69808, memmap size: 0x1b00 ^^^^^^^ ^^^^^^ |
From: Timo L. <tim...@ik...> - 2022-06-11 19:45:24
|
On Sat, 11 Jun 2022, Tony Camuso wrote: > OK, so something is going wrong with the information that tboot is > forwarding to the kernel launch. > > On the efi system, with "noefi" removed from the grub command line, > the system boots. > > With "noefi" in the grub command line, Device Mapper cannot find > the root and swap devices and drops to the dracut prompt. > > How can I determine what info efi is providing that tboot is not? > > Where can I instrument the code to gain that visibility? I'm not too familiar with dracut but I'd imagine you can unpack the initramfs and investigate how it works. It might be easiest to spawn a shell at some point. Can you reproduce the problem if you do a fresh install? What distribution is this? If you have easy steps to reproduce this I can try to take a look. I'm normally on Debian so will need good instructions for other distros :) -Timo |