[PATCH 0/4] Add support for TPM2 log reported via ACPI table

[PATCH 0/4] Add support for TPM2 log reported via ACPI table

[Petr Vandrovec]

Hi Peter,

This series of 4 patches adds support for handling TPM2
log when it is reported through ACPI TPM2 table, as
described in latest TPM ACPI draft (Version 1.2, Revision 8,
from February 27th, 2017).

I've tested patch on x86 only - I do not have PPC64 system
with TPM, and handling of endianness between tpm1_eventlog.c
and tpm2_eventlog.c seems inconsistent: tpm1_eventlog.c uses
be32_to_cpu() for all log fields on PPC64, while
tpm2_eventlog.c uses log uses native endianness.  If it
is intentional, and PPC64 has TPM1 logs in big endian
while TPM2 logs in native endianness, then 3rd patch
needs to be amended.

Four patches split task of improving TPM2 support into following
subtasks:


1. Add log start/length fields to TPM2 table

This patch adds 1.2 rev 8 structures to TPM2 table, and
modifies tpm_tis and tpm_crb to use
offsetofend(tpm2, field_accessed) rather than sizeof(tpm2)
to verify that TPM2 table is big enough.


2. Read TCG log from TPM2 table

This patch modifies tpm_acpi code to read log start/length
from TPM2 table similar way it does so from TCPA table.


3. Autodetect TCG event log version

This patch modifies tpm1_eventlog to make decision whether
to use TPM1 or TPM2 format based on log content, rather
than from chip version: on x86 there is dozen of firmwares
that use TPM1 log with TPM2 chip.

Other part of the change is to validate content of specid
event to make sure kernel does not crash when faced with
specid event that claims there is 2^32-1 hashes in the
event list.


4. Improve handling of TPM2 event logs

Current code does not report any error when digest's hash
is not listed in specid event, or if event reports 2^32-1
digests (which is BIOS bug), or if event has more than
3 digests (that is kernel bug).  Instead it will try to
vmalloc() all available memory when event log is read by
userspace application.

This patch updates code so that it can handle arbitrary
number of digests, as long as they are all described
in specid event, and stops parsing as soon as any malformed
event is detected.


Let me know if there are any improvements I can make to
this patch series.

Thanks,
Petr Vandrovec


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

Re: [PATCH 0/4] Add support for TPM2 log reported via ACPI table

[Nayna]

On 03/29/2017 01:13 PM, Petr Vandrovec wrote:
> Hi Peter,
>
> This series of 4 patches adds support for handling TPM2
> log when it is reported through ACPI TPM2 table, as
> described in latest TPM ACPI draft (Version 1.2, Revision 8,
> from February 27th, 2017).
>
> I've tested patch on x86 only - I do not have PPC64 system
> with TPM, and handling of endianness between tpm1_eventlog.c
> and tpm2_eventlog.c seems inconsistent: tpm1_eventlog.c uses
> be32_to_cpu() for all log fields on PPC64, while
> tpm2_eventlog.c uses log uses native endianness.  If it
> is intentional, and PPC64 has TPM1 logs in big endian

Yes, in case of ppc64, the tpm1 code logs are in big endian format.

> while TPM2 logs in native endianness, then 3rd patch
> needs to be amended.
>
> Four patches split task of improving TPM2 support into following
> subtasks:
>
>
> 1. Add log start/length fields to TPM2 table
>
> This patch adds 1.2 rev 8 structures to TPM2 table, and
> modifies tpm_tis and tpm_crb to use
> offsetofend(tpm2, field_accessed) rather than sizeof(tpm2)
> to verify that TPM2 table is big enough.
>
>
> 2. Read TCG log from TPM2 table
>
> This patch modifies tpm_acpi code to read log start/length
> from TPM2 table similar way it does so from TCPA table.
>
>
> 3. Autodetect TCG event log version
>
> This patch modifies tpm1_eventlog to make decision whether
> to use TPM1 or TPM2 format based on log content, rather
> than from chip version: on x86 there is dozen of firmwares
> that use TPM1 log with TPM2 chip.

Do you mean firmware support TPM1 log as only SHA1 log format and not 
crypto agile log with only SHA1 ?

Thanks & Regards,
    - Nayna

>
> Other part of the change is to validate content of specid
> event to make sure kernel does not crash when faced with
> specid event that claims there is 2^32-1 hashes in the
> event list.
>
>
> 4. Improve handling of TPM2 event logs
>
> Current code does not report any error when digest's hash
> is not listed in specid event, or if event reports 2^32-1
> digests (which is BIOS bug), or if event has more than
> 3 digests (that is kernel bug).  Instead it will try to
> vmalloc() all available memory when event log is read by
> userspace application.
>
> This patch updates code so that it can handle arbitrary
> number of digests, as long as they are all described
> in specid event, and stops parsing as soon as any malformed
> event is detected.
>
>
> Let me know if there are any improvements I can make to
> this patch series.
>
> Thanks,
> Petr Vandrovec
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> tpmdd-devel mailing list
> tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/tpmdd-devel
>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

Re: [PATCH 0/4] Add support for TPM2 log reported via ACPI table

[Petr Vandrovec]

Nayna wrote:
>
>
> On 03/29/2017 01:13 PM, Petr Vandrovec wrote:
>> Hi Peter,
>>
>> This series of 4 patches adds support for handling TPM2
>> log when it is reported through ACPI TPM2 table, as
>> described in latest TPM ACPI draft (Version 1.2, Revision 8,
>> from February 27th, 2017).
>>
>> I've tested patch on x86 only - I do not have PPC64 system
>> with TPM, and handling of endianness between tpm1_eventlog.c
>> and tpm2_eventlog.c seems inconsistent: tpm1_eventlog.c uses
>> be32_to_cpu() for all log fields on PPC64, while
>> tpm2_eventlog.c uses log uses native endianness. If it
>> is intentional, and PPC64 has TPM1 logs in big endian
>
> Yes, in case of ppc64, the tpm1 code logs are in big endian format.

Thanks.  What about tpm2 logs?  Is first (specid) event in big endian 
format too, or no?

>> while TPM2 logs in native endianness, then 3rd patch
>> needs to be amended.
>>
>> Four patches split task of improving TPM2 support into following
>> subtasks:
>>
>>
>> 1. Add log start/length fields to TPM2 table
>>
>> This patch adds 1.2 rev 8 structures to TPM2 table, and
>> modifies tpm_tis and tpm_crb to use
>> offsetofend(tpm2, field_accessed) rather than sizeof(tpm2)
>> to verify that TPM2 table is big enough.
>>
>>
>> 2. Read TCG log from TPM2 table
>>
>> This patch modifies tpm_acpi code to read log start/length
>> from TPM2 table similar way it does so from TCPA table.
>>
>>
>> 3. Autodetect TCG event log version
>>
>> This patch modifies tpm1_eventlog to make decision whether
>> to use TPM1 or TPM2 format based on log content, rather
>> than from chip version: on x86 there is dozen of firmwares
>> that use TPM1 log with TPM2 chip.
>
> Do you mean firmware support TPM1 log as only SHA1 log format and not
> crypto agile log with only SHA1 ?

Yes.  See f.e. 'TPM2 Preboot Event Log' paragraph in 
https://twobit.us/2016/05/tpm2-uefi-measurements-and-event-log/.

If you think there is no need to support such obscure hardware (it does 
not support this year's draft of TPM2 ACPI spec as hardware is few years 
old, so it would matter only if boot loader would pass log address to 
the kernel, and currently there is no support for this in the kernel), I 
can move validation of header event to tpm2_eventlog.c, and simply 
reject any non-specid log with TPM2.
							Petr

> Thanks & Regards,
> - Nayna
>
>>
>> Other part of the change is to validate content of specid
>> event to make sure kernel does not crash when faced with
>> specid event that claims there is 2^32-1 hashes in the
>> event list.
>>
>>
>> 4. Improve handling of TPM2 event logs
>>
>> Current code does not report any error when digest's hash
>> is not listed in specid event, or if event reports 2^32-1
>> digests (which is BIOS bug), or if event has more than
>> 3 digests (that is kernel bug). Instead it will try to
>> vmalloc() all available memory when event log is read by
>> userspace application.
>>
>> This patch updates code so that it can handle arbitrary
>> number of digests, as long as they are all described
>> in specid event, and stops parsing as soon as any malformed
>> event is detected.
>>
>>
>> Let me know if there are any improvements I can make to
>> this patch series.
>>
>> Thanks,
>> Petr Vandrovec
>>
>>
>> ------------------------------------------------------------------------------
>>
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> tpmdd-devel mailing list
>> tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>> https://lists.sourceforge.net/lists/listinfo/tpmdd-devel
>>
>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

Re: [PATCH 0/4] Add support for TPM2 log reported via ACPI table

[Ken Goldman]

On 3/30/2017 4:13 AM, Petr Vandrovec wrote:
> Nayna wrote:
>>
>>
>> On 03/29/2017 01:13 PM, Petr Vandrovec wrote:
>> [snip]
>>> tpm2_eventlog.c uses log uses native endianness. If it
>>> is intentional, and PPC64 has TPM1 logs in big endian
>>
>> Yes, in case of ppc64, the tpm1 code logs are in big endian format.
>
> Thanks.  What about tpm2 logs?  Is first (specid) event in big endian
> format too, or no?

Formally, according to the TCG specifications, the firmware event log
is little endian.

My opinion (but I may be wrong) ...

It doesn't matter, as long as the platform knows what it did.

When the platform sends the log to the attestation server, it should be
a consistent format, regardless of the endian'ness of the platform.

In my attestation implementation, I use big endian, because that's what
the TPM uses. Thus, I reuse all the TPM and TSS marshaling and
unmarshaling code.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

Re: [PATCH 0/4] Add support for TPM2 log reported via ACPI table

[Nayna]

On 03/30/2017 01:43 PM, Petr Vandrovec wrote:
> Nayna wrote:
>>
>>
>> On 03/29/2017 01:13 PM, Petr Vandrovec wrote:
>>> Hi Peter,
>>>
>>> This series of 4 patches adds support for handling TPM2
>>> log when it is reported through ACPI TPM2 table, as
>>> described in latest TPM ACPI draft (Version 1.2, Revision 8,
>>> from February 27th, 2017).
>>>
>>> I've tested patch on x86 only - I do not have PPC64 system
>>> with TPM, and handling of endianness between tpm1_eventlog.c
>>> and tpm2_eventlog.c seems inconsistent: tpm1_eventlog.c uses
>>> be32_to_cpu() for all log fields on PPC64, while
>>> tpm2_eventlog.c uses log uses native endianness. If it
>>> is intentional, and PPC64 has TPM1 logs in big endian
>>
>> Yes, in case of ppc64, the tpm1 code logs are in big endian format.
>
> Thanks.  What about tpm2 logs?  Is first (specid) event in big endian
> format too, or no?

For TPM2 logs, all the events including the first one, are in little endian.

Sorry for delay in response.

Thanks & Regards,
    - Nayna

>
>>> while TPM2 logs in native endianness, then 3rd patch
>>> needs to be amended.
>>>
>>> Four patches split task of improving TPM2 support into following
>>> subtasks:
>>>
>>>
>>> 1. Add log start/length fields to TPM2 table
>>>
>>> This patch adds 1.2 rev 8 structures to TPM2 table, and
>>> modifies tpm_tis and tpm_crb to use
>>> offsetofend(tpm2, field_accessed) rather than sizeof(tpm2)
>>> to verify that TPM2 table is big enough.
>>>
>>>
>>> 2. Read TCG log from TPM2 table
>>>
>>> This patch modifies tpm_acpi code to read log start/length
>>> from TPM2 table similar way it does so from TCPA table.
>>>
>>>
>>> 3. Autodetect TCG event log version
>>>
>>> This patch modifies tpm1_eventlog to make decision whether
>>> to use TPM1 or TPM2 format based on log content, rather
>>> than from chip version: on x86 there is dozen of firmwares
>>> that use TPM1 log with TPM2 chip.
>>
>> Do you mean firmware support TPM1 log as only SHA1 log format and not
>> crypto agile log with only SHA1 ?
>
> Yes.  See f.e. 'TPM2 Preboot Event Log' paragraph in
> https://twobit.us/2016/05/tpm2-uefi-measurements-and-event-log/.
>
> If you think there is no need to support such obscure hardware (it does
> not support this year's draft of TPM2 ACPI spec as hardware is few years
> old, so it would matter only if boot loader would pass log address to
> the kernel, and currently there is no support for this in the kernel), I
> can move validation of header event to tpm2_eventlog.c, and simply
> reject any non-specid log with TPM2.
>                              Petr
>
>> Thanks & Regards,
>> - Nayna
>>
>>>
>>> Other part of the change is to validate content of specid
>>> event to make sure kernel does not crash when faced with
>>> specid event that claims there is 2^32-1 hashes in the
>>> event list.
>>>
>>>
>>> 4. Improve handling of TPM2 event logs
>>>
>>> Current code does not report any error when digest's hash
>>> is not listed in specid event, or if event reports 2^32-1
>>> digests (which is BIOS bug), or if event has more than
>>> 3 digests (that is kernel bug). Instead it will try to
>>> vmalloc() all available memory when event log is read by
>>> userspace application.
>>>
>>> This patch updates code so that it can handle arbitrary
>>> number of digests, as long as they are all described
>>> in specid event, and stops parsing as soon as any malformed
>>> event is detected.
>>>
>>>
>>> Let me know if there are any improvements I can make to
>>> this patch series.
>>>
>>> Thanks,
>>> Petr Vandrovec
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>>
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> tpmdd-devel mailing list
>>> tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>>> https://lists.sourceforge.net/lists/listinfo/tpmdd-devel
>>>
>>
>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

Re: [PATCH 0/4] Add support for TPM2 log reported via ACPI table

[Jarkko Sakkinen]

Oh there it was.

/Jarkko

On Wed, Mar 29, 2017 at 12:43:20AM -0700, Petr Vandrovec wrote:
> Hi Peter,
> 
> This series of 4 patches adds support for handling TPM2
> log when it is reported through ACPI TPM2 table, as
> described in latest TPM ACPI draft (Version 1.2, Revision 8,
> from February 27th, 2017).
> 
> I've tested patch on x86 only - I do not have PPC64 system
> with TPM, and handling of endianness between tpm1_eventlog.c
> and tpm2_eventlog.c seems inconsistent: tpm1_eventlog.c uses
> be32_to_cpu() for all log fields on PPC64, while
> tpm2_eventlog.c uses log uses native endianness.  If it
> is intentional, and PPC64 has TPM1 logs in big endian
> while TPM2 logs in native endianness, then 3rd patch
> needs to be amended.
> 
> Four patches split task of improving TPM2 support into following
> subtasks:
> 
> 
> 1. Add log start/length fields to TPM2 table
> 
> This patch adds 1.2 rev 8 structures to TPM2 table, and
> modifies tpm_tis and tpm_crb to use
> offsetofend(tpm2, field_accessed) rather than sizeof(tpm2)
> to verify that TPM2 table is big enough.
> 
> 
> 2. Read TCG log from TPM2 table
> 
> This patch modifies tpm_acpi code to read log start/length
> from TPM2 table similar way it does so from TCPA table.
> 
> 
> 3. Autodetect TCG event log version
> 
> This patch modifies tpm1_eventlog to make decision whether
> to use TPM1 or TPM2 format based on log content, rather
> than from chip version: on x86 there is dozen of firmwares
> that use TPM1 log with TPM2 chip.
> 
> Other part of the change is to validate content of specid
> event to make sure kernel does not crash when faced with
> specid event that claims there is 2^32-1 hashes in the
> event list.
> 
> 
> 4. Improve handling of TPM2 event logs
> 
> Current code does not report any error when digest's hash
> is not listed in specid event, or if event reports 2^32-1
> digests (which is BIOS bug), or if event has more than
> 3 digests (that is kernel bug).  Instead it will try to
> vmalloc() all available memory when event log is read by
> userspace application.
> 
> This patch updates code so that it can handle arbitrary
> number of digests, as long as they are all described
> in specid event, and stops parsing as soon as any malformed
> event is detected.
> 
> 
> Let me know if there are any improvements I can make to
> this patch series.
> 
> Thanks,
> Petr Vandrovec
> 

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

Re: [PATCH 0/4] Add support for TPM2 log reported via ACPI table

[Jarkko Sakkinen]

On Wed, Mar 29, 2017 at 12:43:20AM -0700, Petr Vandrovec wrote:
> Hi Peter,
> 
> This series of 4 patches adds support for handling TPM2
> log when it is reported through ACPI TPM2 table, as
> described in latest TPM ACPI draft (Version 1.2, Revision 8,
> from February 27th, 2017).
> 
> I've tested patch on x86 only - I do not have PPC64 system
> with TPM, and handling of endianness between tpm1_eventlog.c
> and tpm2_eventlog.c seems inconsistent: tpm1_eventlog.c uses
> be32_to_cpu() for all log fields on PPC64, while
> tpm2_eventlog.c uses log uses native endianness.  If it
> is intentional, and PPC64 has TPM1 logs in big endian
> while TPM2 logs in native endianness, then 3rd patch
> needs to be amended.
> 
> Four patches split task of improving TPM2 support into following
> subtasks:

This cover letter is a bit chaotic. A cover letter should give an
understandable description of the what is done. Now you have a 2nd
version of commit messages here. This looks confusing.

/Jarkko

> 
> 
> 1. Add log start/length fields to TPM2 table
> 
> This patch adds 1.2 rev 8 structures to TPM2 table, and
> modifies tpm_tis and tpm_crb to use
> offsetofend(tpm2, field_accessed) rather than sizeof(tpm2)
> to verify that TPM2 table is big enough.
> 
> 
> 2. Read TCG log from TPM2 table
> 
> This patch modifies tpm_acpi code to read log start/length
> from TPM2 table similar way it does so from TCPA table.
> 
> 
> 3. Autodetect TCG event log version
> 
> This patch modifies tpm1_eventlog to make decision whether
> to use TPM1 or TPM2 format based on log content, rather
> than from chip version: on x86 there is dozen of firmwares
> that use TPM1 log with TPM2 chip.
> 
> Other part of the change is to validate content of specid
> event to make sure kernel does not crash when faced with
> specid event that claims there is 2^32-1 hashes in the
> event list.
> 
> 
> 4. Improve handling of TPM2 event logs
> 
> Current code does not report any error when digest's hash
> is not listed in specid event, or if event reports 2^32-1
> digests (which is BIOS bug), or if event has more than
> 3 digests (that is kernel bug).  Instead it will try to
> vmalloc() all available memory when event log is read by
> userspace application.
> 
> This patch updates code so that it can handle arbitrary
> number of digests, as long as they are all described
> in specid event, and stops parsing as soon as any malformed
> event is detected.
> 
> 
> Let me know if there are any improvements I can make to
> this patch series.
> 
> Thanks,
> Petr Vandrovec
> 

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

Re: [PATCH 0/4] Add support for TPM2 log reported via ACPI table

[Petr Vandrovec]

Jarkko Sakkinen wrote:
> On Wed, Mar 29, 2017 at 12:43:20AM -0700, Petr Vandrovec wrote:
>> Hi Peter,
>>
>> This series of 4 patches adds support for handling TPM2
>> log when it is reported through ACPI TPM2 table, as
>> described in latest TPM ACPI draft (Version 1.2, Revision 8,
>> from February 27th, 2017).
>>
>> I've tested patch on x86 only - I do not have PPC64 system
>> with TPM, and handling of endianness between tpm1_eventlog.c
>> and tpm2_eventlog.c seems inconsistent: tpm1_eventlog.c uses
>> be32_to_cpu() for all log fields on PPC64, while
>> tpm2_eventlog.c uses log uses native endianness.  If it
>> is intentional, and PPC64 has TPM1 logs in big endian
>> while TPM2 logs in native endianness, then 3rd patch
>> needs to be amended.
>>
>> Four patches split task of improving TPM2 support into following
>> subtasks:
>
> This cover letter is a bit chaotic. A cover letter should give an
> understandable description of the what is done. Now you have a 2nd
> version of commit messages here. This looks confusing.

Hi Jarkko,

sorry about that.  I wanted to provide additional details in the cover 
letter.  As far as understandable description, it is more or less 
covered in first paragraph.  Would this summary work for you:

This series adds support for handling TPM2 log when it is reported 
through ACPI TPM2 table, as described in latest TPM ACPI draft (Version 
1.2, Revision 8, from February 27th, 2017).

Second half of the series then improves support for TPM2 log parsing, so 
kernel does not crash when firmware provides TPM log in different format 
than 'Spec ID Event03', or if it uses Event03 format with more than 3 
hashes.


Thanks,
Petr

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

Re: [PATCH 0/4] Add support for TPM2 log reported via ACPI table

[Jarkko Sakkinen]

On Fri, Mar 31, 2017 at 02:18:23PM -0700, Petr Vandrovec wrote:
> Jarkko Sakkinen wrote:
> > On Wed, Mar 29, 2017 at 12:43:20AM -0700, Petr Vandrovec wrote:
> > > Hi Peter,
> > > 
> > > This series of 4 patches adds support for handling TPM2
> > > log when it is reported through ACPI TPM2 table, as
> > > described in latest TPM ACPI draft (Version 1.2, Revision 8,
> > > from February 27th, 2017).
> > > 
> > > I've tested patch on x86 only - I do not have PPC64 system
> > > with TPM, and handling of endianness between tpm1_eventlog.c
> > > and tpm2_eventlog.c seems inconsistent: tpm1_eventlog.c uses
> > > be32_to_cpu() for all log fields on PPC64, while
> > > tpm2_eventlog.c uses log uses native endianness.  If it
> > > is intentional, and PPC64 has TPM1 logs in big endian
> > > while TPM2 logs in native endianness, then 3rd patch
> > > needs to be amended.
> > > 
> > > Four patches split task of improving TPM2 support into following
> > > subtasks:
> > 
> > This cover letter is a bit chaotic. A cover letter should give an
> > understandable description of the what is done. Now you have a 2nd
> > version of commit messages here. This looks confusing.
> 
> Hi Jarkko,
> 
> sorry about that.  I wanted to provide additional details in the cover
> letter.  As far as understandable description, it is more or less covered in
> first paragraph.  Would this summary work for you:
> 
> This series adds support for handling TPM2 log when it is reported through
> ACPI TPM2 table, as described in latest TPM ACPI draft (Version 1.2,
> Revision 8, from February 27th, 2017).
> 
> Second half of the series then improves support for TPM2 log parsing, so
> kernel does not crash when firmware provides TPM log in different format
> than 'Spec ID Event03', or if it uses Event03 format with more than 3
> hashes.
> 
> 
> Thanks,
> Petr

Great, thank you. I'll look into this in more detail after we are done
with 4.12.

/Jarkko

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot