2009/8/19 Vladimir 'phcoder' Serbinenko :
> On Wed, Aug 19, 2009 at 10:57 PM, Duboucher Thomas wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Michal Suchanek a écrit :
> Without threat model we're speaking placebo.
>
Stoned Bootkit?
>>>
>>> Coreboot can prevent that a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Vladimir 'phcoder' Serbinenko a écrit :
> You can remove TPM too
And if you remove the TPM, how do you retrieve the secret? oO
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
On Wed, Aug 19, 2009 at 10:57 PM, Duboucher Thomas wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Michal Suchanek a écrit :
Without threat model we're speaking placebo.
>>> Stoned Bootkit?
>>
>> Coreboot can prevent that as well as TPM can.
>>
>
> Coreboot can be "stoned" as
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michal Suchanek a écrit :
>>> Without threat model we're speaking placebo.
>>>
>> Stoned Bootkit?
>
> Coreboot can prevent that as well as TPM can.
>
Coreboot can be "stoned" as easily as your MBR since you can easily
rewrite the MBR from the softwa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Vladimir 'phcoder' Serbinenko a écrit :
> How many record labels will not jump on occasion of an efficient DRM?
In France, they still believe it takes three days for a .mp3 to travel
from Japan to France ...
> How many banks will resist the temptatio
On Wed, Aug 19, 2009 at 10:37 PM, Duboucher Thomas wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Vladimir 'phcoder' Serbinenko a écrit :
>> There is a point in keeping them - remote atestation. Why do I need
>> manufacturer to sign my key?
>
> No, the endorsement key pair is not used
2009/8/19 Duboucher Thomas :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Vladimir 'phcoder' Serbinenko a écrit :
>> Without threat model we're speaking placebo.
>>
>
> Stoned Bootkit?
Coreboot can prevent that as well as TPM can.
Any threat model which shows the advantage of TPM?
Than
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Vladimir 'phcoder' Serbinenko a écrit :
> There is a point in keeping them - remote atestation. Why do I need
> manufacturer to sign my key?
No, the endorsement key pair is not used in remote attestation. Only to
generate one time key pairs for owners
On Wed, Aug 19, 2009 at 10:33 PM, Michael Gorven wrote:
> On Wed, Aug 19, 2009 at 10:27:59PM +0200, Vladimir 'phcoder' Serbinenko
> wrote:
Since we're going to say no anyway, there's no reason to do it later.
The
longer we wait the stronger they'll be, and the more difficult fo
On Wed, Aug 19, 2009 at 10:27:59PM +0200, Vladimir 'phcoder' Serbinenko wrote:
Since we're going to say no anyway, there's no reason to do it
later. The
longer we wait the stronger they'll be, and the more difficult for us to
reject their unreasonable demands.
Because there are valid use case
>> It could mean you can't read a book unless you use their designated
>> non-free
>> reader (with DRM restrictions, etc).
>
> So use a different bank and a different publisher.
How many record labels will not jump on occasion of an efficient DRM?
How many banks will resist the temptation to say "w
>
> 99% of people with this use case are not going to put their BIOS chip in
> concrete. Configuring a TPM chip a lot easier.
>
98% of people in this case don't really care if they are secure or not.
>>> I keep trusting it because
>>> the TPM tells me it hasn't been altered on my computer by nasty
On Wed, Aug 19, 2009 at 10:13 PM, Duboucher Thomas wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Vladimir 'phcoder' Serbinenko a écrit :
>> Could you please avoid using abbreviations. It's already hard to read
>> TPM specs because of their twisted terminology. If EKP is the key
>> st
- Lock down via proprietary crypto chip (TPM). Different software can
happen if "attacker" figured out how to break into your TPM, which is
actually quite possibly easier, not harder, than replacing hardware
because the TPMs are closed systems that don't disclose their design a
On Wed, Aug 19, 2009 at 04:42:32PM +0200, Robert Millan wrote:
On Wed, Aug 19, 2009 at 02:25:21PM +0200, Michael Gorven wrote:
On Wednesday 19 August 2009 13:51:34 Vladimir 'phcoder' Serbinenko wrote:
> 1) Making use of TPM you become dependent on good will of TPM
> manufacturer. You can never k
On Wed, Aug 19, 2009 at 9:53 PM, Michael Gorven wrote:
> On Wed, Aug 19, 2009 at 04:01:39PM +0200, Robert Millan wrote:
>>
>> Can you give a reason not to provide the owner with any of:
>>
>> - A printed copy of the private key corresponding to the chip he paid
>> for.
>
> Not really, although not
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Vladimir 'phcoder' Serbinenko a écrit :
> Could you please avoid using abbreviations. It's already hard to read
> TPM specs because of their twisted terminology. If EKP is the key
> stored in the TPM then manufacturer can keep a copy of public or
> pri
Coreboot can make this too. And firmware doesn't need TPM to do such
checks.
>>>
>>> Yes, except coreboot isn't widely supported.
>>
>> It's not a reason to obey BIOS manufacturers.
>
> You're not obeying them.
Yeah?
>> If you don't trust a location, change it. They have physical access
>
On Wed, Aug 19, 2009 at 08:48:13PM +0200, Vladimir 'phcoder' Serbinenko wrote:
Since the BIOS can be "easily" replaced, it cannot be trusted, hence you
can't build a chain of trust starting from your BIOS. It is a "little"
more difficult to replace a TPM, even more if it's holding a shared
secret
On Wed, Aug 19, 2009 at 08:01:06PM +0200, Vladimir 'phcoder' Serbinenko wrote:
I can imagine a world with computers you can access from free and from
whom you can boot with your USB pen-drive (or trust the installed OS, or
whatever you want). But this world is still far away from here ... :|
TPM
On Wed, Aug 19, 2009 at 04:01:39PM +0200, Robert Millan wrote:
Can you give a reason not to provide the owner with any of:
- A printed copy of the private key corresponding to the chip he paid for.
Not really, although not having any trace of the private key reduces the
chance of it being st
On Wed, Aug 19, 2009 at 03:48:18PM +0200, Vladimir 'phcoder' Serbinenko wrote:
On Wed, Aug 19, 2009 at 3:24 PM, Michael Gorven wrote:
On Wednesday 19 August 2009 14:42:37 Vladimir 'phcoder' Serbinenko wrote:
Even if they can't stop from working at all they can make it
effectively useless by e.g
On Wed, Aug 19, 2009 at 9:16 PM, Duboucher Thomas wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Vladimir 'phcoder' Serbinenko a écrit :
>> But why does a third instance (manufacturer) need to trust my key?
>> Only one: he wants a control.
>
> I don't see where the TPME needs to trust
2009/8/19 Vladimir 'phcoder' Serbinenko :
> On Wed, Aug 19, 2009 at 8:13 PM, Duboucher Thomas wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Vladimir 'phcoder' Serbinenko a écrit :
> 2) Ethical Aspects
> ==
>
Every technology has its evil uses, so
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Vladimir 'phcoder' Serbinenko a écrit :
> But why does a third instance (manufacturer) need to trust my key?
> Only one: he wants a control.
I don't see where the TPME needs to trust the EKP in the specification.
>> Also, most of the time, the reset
> Since the BIOS can be "easily" replaced, it cannot be trusted, hence you
> can't build a chain of trust starting from your BIOS. It is a "little"
> more difficult to replace a TPM, even more if it's holding a shared
> secret. :)
Write wire? Concrete around the chip? Concrete is more resistant tha
On Wed, Aug 19, 2009 at 8:13 PM, Duboucher Thomas wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Vladimir 'phcoder' Serbinenko a écrit :
2) Ethical Aspects
==
>>> Every technology has its evil uses, so does TPM. However, there's a very
>>> large gap betw
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Vladimir 'phcoder' Serbinenko a écrit :
>> I can imagine a world with computers you can access from free and from
>> whom you can boot with your USB pen-drive (or trust the installed OS, or
>> whatever you want). But this world is still far away from h
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Vladimir 'phcoder' Serbinenko a écrit :
>>> 2) Ethical Aspects
>>> ==
>>>
>> Every technology has its evil uses, so does TPM. However, there's a very
>> large gap between currently implemented solutions and what you suggest.
> How can y
> I can imagine a world with computers you can access from free and from
> whom you can boot with your USB pen-drive (or trust the installed OS, or
> whatever you want). But this world is still far away from here ... :|
TPM doesn't protect your computer from being stolen and HD wiped.
>> replace yo
Duboucher Thomas wrote:
Also, you are not owning a computer by using a chain of trust. You are
only sure that the software you trust on your computer haven't been
tampered. And you can keep trusting them, even if they have a backdoor
you weren't aware of! ;)
well it's true, even with the most o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Isaac Dupree a écrit :
> Suppose you are the proud technical support person at a third-world
> school that just bought a thousand OLPC XOs. You, as part of your
> country's government, are instructed to own those XOs. If they are
> stolen and get int
> Technical measures can never decide who, morally, "owns" a computer.
I agree. Anyone who can open the computer can make it do whatever he
wants too. It's possible to increase the cost of such operations by
all kind of obfuscation schemes. If a cost to make a laptop behave for
the thief is bigger
>> 2) Ethical Aspects
>> ==
>>
> Every technology has its evil uses, so does TPM. However, there's a very
> large gap between currently implemented solutions and what you suggest.
How can you know this? I met persons who say that it's very difficult
to mount a PKI infrastructure to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> 1) Technical Aspects
>
>
>>From a purely technical point of view, the TPM support in GRUB is about
> the "Trusted Boot" with a partial support and a full one.
>
> Partial support means that GRUB is able to (TPM commands are ta
On Wed, Aug 19, 2009 at 11:17 PM, Michal Suchanek wrote:
> {} block syntax is also widely used and much easier to read and write
> by humans than XML+CSS.
>
> I do not see the reason for pushing XML/CSS everywhere. It's a
> compromise that does not quite work for neither of visual formatting,
> oth
Michael Gorven wrote:
On Wednesday 19 August 2009 14:42:37 Vladimir 'phcoder' Serbinenko wrote:
Even if they can't stop from working at all they can make it
effectively useless by e.g. not allowing you to see online videos, buy
online or even just send an e-mail (saying it's "spam control") if y
On Wed, Aug 19, 2009 at 5:34 PM, Robert Millan wrote:
> On Wed, Aug 19, 2009 at 01:54:46PM +0200, Vladimir 'phcoder' Serbinenko wrote:
>> This is a dirty import of multiboot specification from grub1. It
>> doesn't compile it unless explicitly requested since we don't have
>> appropriate autoconf te
On Wed, Aug 19, 2009 at 01:54:46PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> This is a dirty import of multiboot specification from grub1. It
> doesn't compile it unless explicitly requested since we don't have
> appropriate autoconf tests yet. The main goal is to leave no current
> documentati
On Mon, Aug 17, 2009 at 04:27:51PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> >> 1) stat and readlink are different. Does anyone have an idea how to
> >> make scripts always use right syntax?
> >
> > AFAIK a custom autoconf snippet is the only way.
> I would prefer it to be done on runtime if po
On Wed, Aug 19, 2009 at 02:25:08AM +0800, Bean wrote:
> > Have you tried linux_video_setup as present in i386/linux.c in
> > i386/efi/linux.c ? It would be nice if we could share more code
> > between these 2 files. If it works and you judge that i386/linux.c
> > and i386/efi/linux.c are similar e
On Tue, Aug 18, 2009 at 09:26:45PM +0800, Bean wrote:
> Hi,
>
> Here is the raw patch.
Thanks. Was efi_fb.c written from scratch, or copied/refurbished from another
part of GRUB ? It's ok either way, but we need to know about it. Would you
please send a ChangeLog entry where this is referenced
On Tue, Aug 18, 2009 at 07:53:30PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> >
> > I'm sorry, I'm very busy these days. I don't know what message you are
> > talking about, but I still have a lot of mail to read.
> >
> > I don't insist on changing the default, as long as GRUB behaves
> > corre
2009/8/19 Bean :
> On Wed, Aug 19, 2009 at 10:30 PM, Vladimir 'phcoder'
> Serbinenko wrote:
>> On Wed, Aug 19, 2009 at 4:22 PM, Bean wrote:
>>> Hi,
>>>
>>> Some clarification about the XML/CSS format:
>>>
>>> First of all, the internal representation of component is tree-like
>>> structure, which i
On Wed, Aug 19, 2009 at 5:08 PM, Robert Millan wrote:
>
> I agree with this proposal in general. Except with the concept of "users",
> which I think might be overkill. GRUB is not a Un*x with its /home and
> per-user settings. These passwords just protect resources, so I'm not sure
> if there's
On Mon, Aug 17, 2009 at 03:54:06PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> On Mon, Aug 17, 2009 at 3:43 PM, Robert Millan wrote:
> > On Sat, Aug 15, 2009 at 04:47:32PM +0200, Vladimir 'phcoder' Serbinenko
> > wrote:
> >> +static inline char *
> >> +grub_strncat (char *dest, const char *src,
On Sun, Jul 26, 2009 at 06:20:03PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> I think you underestimate yourself. Especially if we agree on function
> propotypes you are completely able to implement. Discussing on IRC I
> formulated 3 criteria which our system must satisfy:
> (1) you can't acces
On Wed, Aug 19, 2009 at 10:30 PM, Vladimir 'phcoder'
Serbinenko wrote:
> On Wed, Aug 19, 2009 at 4:22 PM, Bean wrote:
>> Hi,
>>
>> Some clarification about the XML/CSS format:
>>
>> First of all, the internal representation of component is tree-like
>> structure, which is quite natural to XML, we c
On Wed, Aug 19, 2009 at 02:25:21PM +0200, Michael Gorven wrote:
> On Wednesday 19 August 2009 13:51:34 Vladimir 'phcoder' Serbinenko wrote:
> > 1) Making use of TPM you become dependent on good will of TPM
> > manufacturer. You can never know if or when the TPM manufacturer or
> > someone connected
On Wed, Aug 19, 2009 at 01:00:43PM +0200, Emmanuel Fleury wrote:
> Dear all,
>
> I know this is a quite sensitive topic and I'm really not willing to
> start a new flame-war about it. I just want to know the exact status of
> it and what is the (official) position of the GRUB team on the TPM suppo
On Wed, Aug 19, 2009 at 4:22 PM, Bean wrote:
> Hi,
>
> Some clarification about the XML/CSS format:
>
> First of all, the internal representation of component is tree-like
> structure, which is quite natural to XML, we can create the tree while
> parsing. Besides, we don't need to implement the ful
Hi,
Some clarification about the XML/CSS format:
First of all, the internal representation of component is tree-like
structure, which is quite natural to XML, we can create the tree while
parsing. Besides, we don't need to implement the full specification of
XML/CSS, just a subset that works for
On Wed, Aug 19, 2009 at 03:24:34PM +0200, Michael Gorven wrote:
> If you don't want to follow their requirements, then don't.
They never had the right to impose arbitrary requirements to media they
produce. Under the US Constitution (and just about every jurisdiction in
the world) they can't ever
On Wed, Aug 19, 2009 at 03:24:34PM +0200, Michael Gorven wrote:
> > > The only valid argument I see against TPM is the
> > > supporting-possibly-harmful-technology one. But then we shouldn't use
> > > crypto at all because it can be used for DRM...
> >
> > It's not just "possibly harmful", it's "de
On Wed, Aug 19, 2009 at 3:24 PM, Michael Gorven wrote:
> On Wednesday 19 August 2009 14:42:37 Vladimir 'phcoder' Serbinenko wrote:
>> Even if they can't stop from working at all they can make it
>> effectively useless by e.g. not allowing you to see online videos, buy
>> online or even just send an
On Wednesday 19 August 2009 14:42:37 Vladimir 'phcoder' Serbinenko wrote:
> Even if they can't stop from working at all they can make it
> effectively useless by e.g. not allowing you to see online videos, buy
> online or even just send an e-mail (saying it's "spam control") if you
> aren't TPM-che
On Wed, Aug 19, 2009 at 2:25 PM, Michael Gorven wrote:
> On Wednesday 19 August 2009 13:51:34 Vladimir 'phcoder' Serbinenko wrote:
>> 1) Making use of TPM you become dependent on good will of TPM
>> manufacturer. You can never know if or when the TPM manufacturer or
>> someone connected with them w
On Wednesday 19 August 2009 13:51:34 Vladimir 'phcoder' Serbinenko wrote:
> 1) Making use of TPM you become dependent on good will of TPM
> manufacturer. You can never know if or when the TPM manufacturer or
> someone connected with them will ask you to use remote attestation to
> prove them that y
On Wed, Aug 19, 2009 at 1:00 PM, Emmanuel Fleury wrote:
> Dear all,
>
> I know this is a quite sensitive topic and I'm really not willing to
> start a new flame-war about it. I just want to know the exact status of
> it and what is the (official) position of the GRUB team on the TPM support.
>
> La
Dear all,
I know this is a quite sensitive topic and I'm really not willing to
start a new flame-war about it. I just want to know the exact status of
it and what is the (official) position of the GRUB team on the TPM support.
Last discussion about the TPM issue was in February (see:
http://lists
2009/8/19 Vladimir 'phcoder' Serbinenko :
>>> To have level or tree-like model you can use '.' as a name separator
>>> it will make the system uniform with current FreeBSD booting.
>>
>> XML/CSS is not the easiest format to work with but a bunch of
>> variables which represent a tree is not nice ei
>> To have level or tree-like model you can use '.' as a name separator
>> it will make the system uniform with current FreeBSD booting.
>
> XML/CSS is not the easiest format to work with but a bunch of
> variables which represent a tree is not nice either.
>
> However, apt has settings format that
On Sat, Aug 15, 2009 at 12:00 AM, Pavel Roskin wrote:
> On Fri, 2009-08-14 at 22:53 +0200, Vladimir 'phcoder' Serbinenko wrote:
>> Hello. Currently afs and befs modules handle both big and little
>> endian variants. Here is a patch to split into 2 modules.
>> Unfortunately I wasn't able to find eas
2009/8/19 Vladimir 'phcoder' Serbinenko :
> On Wed, Aug 19, 2009 at 11:05 AM, Bean wrote:
>> Hi,
>>
>> Currently, the menu system is a little unorganized and difficult to
>> extend. My goal of the redesign are:
>>
>> Modular
>> Split code into small modules, each module implement a specific
>> func
On Wed, Aug 19, 2009 at 11:05 AM, Bean wrote:
> Hi,
>
> Currently, the menu system is a little unorganized and difficult to
> extend. My goal of the redesign are:
>
> Modular
> Split code into small modules, each module implement a specific
> function, modules uses predefined interface to call each
Hi,
Currently, the menu system is a little unorganized and difficult to
extend. My goal of the redesign are:
Modular
Split code into small modules, each module implement a specific
function, modules uses predefined interface to call each other.
Extensible
The core of the menu system is component
66 matches
Mail list logo
