parabolis wrote:
> They are working with hardware people to ensure that
> signed startup code is not executed unless the startup code has
> not been changed.
Would you please point out a reference? Thanks in advance.

> This startup code can then be used to ensure the rest of the OS code has not been mucked with and will also allow the OS to guarantee your signed code has not been changed either.
But only if the complete OS is selfchecking, right? Otherwise that would imply the end of all viruses.

-manfred

"Manfred Nowak" <svv1999@hotmail.com> wrote in message news:csbb31$2c30$1@digitaldaemon.com...
> that would imply the end of all viruses.

and non-MS operation systems..
i think that despite the good idea about have an OS incorporated into the
CPU,
this movement would give much power to MS.
too much power if you ask me..

the ideas of cracking, viruses, and all that..
it's much less scares me than having no alternative.
at least now, we have a certain amount of freedom. who can tell what will
happened
when the Hexium will be spreaded across the land ?

- Asaf.

Norbert Nemec wrote:

> I'm not sure what you mean with "release option". If you talk of "release" vs. "debug" mode, then this option is not a separate stage after compilation but an option that affects the code generate stage.
Yes correct: I mean the '-release' option of  'dmd'. And your pure mention,
that
the code generating phase is affected is according to your own argument at
least
incomplete: Why can this switching off of at least asserts, array bounds
checks
and switching on of  code optimization not be done perfectly well in a
postprocessing phase?

[...]
> If a system administrator has special need for checksumming, it should be up to him to decide on the details.
Correct. But adminstrators mostly prefer to decide, not to code. So her decision in case of  lack of an existing decision possibility would not be "Ahh. Here is a D-Source. I want to code the self checking  I need for it." but rather "Ahh. Here is a D-Source. Nope. That _was_ a D-Source."

[...]
> If I knew that every binary is self-checking, there might be a certain
gain,
Thanks for the respect.

> but if it is depending on the programming language, the feature is mostly worthless.
Why? You just pointed out, that in your opinion the self checking instrumentation can and should be done in a post processing phase. Why is this true only for D and not for any of the other languages of that particular adminstrator?

-manfred

Asaf Karagila wrote:

[...]
> when the Hexium will be spreaded across the land ?

http://satirist.org/whale/2003/10/30.html :D

-manfred

Manfred Nowak wrote:
> parabolis wrote:
> 
>>They are working with hardware people to ensure that
>>signed startup code is not executed unless the startup code has
>>not been changed.
> 
> Would you please point out a reference? Thanks in advance.

Search google for Palladium (MS's next big OS) and TCPA (Trusted Platform Alliance). Here is a TCPA faq to get you started:

http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html

A short exerpt from that FAQ:
----------------------------------------------------------------
The current version has Fritz as a passive monitoring component that stores the hash of the machine state on start-up. This hash is computed using details of the hardware (audio card, video card etc) and the software (O/S, drivers, etc). If the machine ends up in the approved state, Fritz will make available to the operating system the cryptographic keys needed to decrypt TC applications and data. If it ends up in the wrong state, the hash will be wrong and Fritz won't release the right key. The machine may still be able to run non-TC apps and access non-TC data, but protected material will be unavailable.

The operating system security kernel (the `Nexus') bridges the gap between the Fritz chip and the application security components (the `NCAs'). It checks that the hardware components are on the TCG approved list, that the software components have been signed, and that none of them has a serial number that has been revoked.
...
When it first launched TC as Palladium, Microsoft claimed that Palladium would stop spam, viruses and just about every other bad thing in cyberspace.
----------------------------------------------------------------

On 2005-01-15, parabolis <parabolis@softhome.net> wrote:
> Manfred Nowak wrote:
>> parabolis wrote:
> components (the `NCAs'). It checks that the hardware components
> are on the TCG approved list, that the software components have
> been signed, and that none of them has a serial number that has
> been revoked.
> ...
> When it first launched TC as Palladium, Microsoft claimed that
> Palladium would stop spam, viruses and just about every other
> bad thing in cyberspace.
> ----------------------------------------------------------------

Also please note that free software would be one the the very bad things (for Microsoft) that Palladium could stop.

I fear, this whole thread is going nowhere. Essentially it falls back to: If you think it is essential, either code it yourself or find someone else to code it. I have the feeling that so far nobody has spoken up for the task.

Personally, I have no need whatsoever for checksumming and I doubt that D as a language would gain a lot by it. There are many other feature that might be nice to have which nobody ever implemented. Maybe this is just one more of them.

If you think about implementing a checksumming algorithm, you might soon
realize that it is simpler to write a language-ignorant program that just
takes an executable and spits out another one. It may have disadvantages
compared to one built into the compiler, but it certainly has some
advantages
* It works for any language and even third-party programs that you did not
compile yourself.
* You don't have to convince any compiler-writer to include it.
* If anybody thinks it should be done differently, they can just write their
own version any you don't have to fight whose gets into the compiler.

> > components (the `NCAs'). It checks that the hardware components
> > are on the TCG approved list, that the software components have
> > been signed, and that none of them has a serial number that has
> > been revoked.
> > ...
> > When it first launched TC as Palladium, Microsoft claimed that
> > Palladium would stop spam, viruses and just about every other
> > bad thing in cyberspace.

> Also please note that free software would be one the the very bad things (for Microsoft) that Palladium could stop.

The basic concept of assigning access rights based on "trust" is quite usefull.

(On one of my system only executeables with an embedded valid & trusted GPG signature are allowed to be loaded.)

The problem with Palladium is how the "trust" is managed.

1) The local administrator isn't in controll. This leads to lots of legal problems
- at least here in Old Europe.
2) Online access is required.

Many of todays Bad Soft(tm) are working on the script level. I'm sure IE, OE and MsOffice will be trusted ...

Thomas

yes,
but just for the reference, if you want to write an executable compressor,
take a look at UPX, which is great, free and open source.
if you want to write a protector.. well, i suggest you spend 3 years or more
learning reverse code engineering, PE and COFF formats, encryption,
compression, etc etc etc. and maybe just maybe, you'll manage to write
a decent protector.
illusioning yourself to be able to write a good protector with a mere idea,
your chance to succeed is smaller than the chance of a tsunami hitting
texas.
(sorry for the cynical remark if i offended anyone..)
it's like writing a very simple serial check routine and think it's
undefeatable
because you're XORing the value, and no one can guess the result.

my entire point is, most of the programmers can't protect their code right. either find a GOOD (and proved as good, not by the company as well) protector, or follow my first paragraph suggestions.

- Asaf.

On 2005-01-16, Thomas Kuehne <thomas-dloop@kuehne.cn> wrote:
>> Also please note that free software would be one the the very bad things (for Microsoft) that Palladium could stop.
>
> The basic concept of assigning access rights based on "trust" is quite usefull.

> (On one of my system only executeables with an embedded valid & trusted GPG signature are allowed to be loaded.)
>
> The problem with Palladium is how the "trust" is managed.
>
> 1) The local administrator isn't in controll. This leads to lots of legal problems
> - at least here in Old Europe.
> 2) Online access is required.

And probably:
  3) To obtain a certificate for your software that works with Palladium
  hardware you must pay Microsoft (or Intel or...), for every new
  version and minor release.

> Many of todays Bad Soft(tm) are working on the script level. I'm sure IE, OE and MsOffice will be trusted ...

Sure.