Is Itanium the first 64-bit casualty?

Page 9 - Seeking answers? Join the Tom's Hardware community: where nearly two million members share solutions and discuss the latest tech.
Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

On Fri, 09 Jul 2004 08:25:37 +0200, Ketil Malde <ketil@ii.uib.no> wrote:

>Paul Gunson <spammersrot@mybasement.com> writes:
>
>> i was shocked to learn that it still required a floppy drive to
>> install XP-64.
>
>I've been wondering why all new PCs seem to have them the last five
>years 🙂

Some of the large corps have had err, problems with theft of "important"
info on USB flash drives. They're disabling the functionality down to
keyboard/mouse as necessary.... and CD writers are also often banned from
employee systems.

Rgds, George Macdonald

"Just because they're paranoid doesn't mean you're not psychotic" - Who, me??
 
Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

"George Macdonald" <fammacd=!SPAM^nothanks@tellurian.com> wrote in message
news:fgkse0d7g5v3qq01sqei1qhefiunpdqd4t@4ax.com...
> On Fri, 09 Jul 2004 08:25:37 +0200, Ketil Malde <ketil@ii.uib.no> wrote:
>
> >Paul Gunson <spammersrot@mybasement.com> writes:
> >
> >> i was shocked to learn that it still required a floppy drive to
> >> install XP-64.
> >
> >I've been wondering why all new PCs seem to have them the last five
> >years 🙂
>
> Some of the large corps have had err, problems with theft of "important"
> info on USB flash drives. They're disabling the functionality down to
> keyboard/mouse as necessary.... and CD writers are also often banned from
> employee systems.
>
> Rgds, George Macdonald
>
> "Just because they're paranoid doesn't mean you're not psychotic" - Who,
me??

I visited a defense contractor to give a presentation a number of years ago
when flash drives were newly available but limited supply and very
expensive. (mine was a gift) As we checked in through security they
required my floppy be removed, it was in my bag but I left it with security.

At the presentation, I booted up my PC and shoved the flash drive in (8MB
maybe...) I store all the presenations/whitepapers/propoganda on the flash
so if someone requests it, I just dump it on their PC right there. Also
helps if my PC dies, I use any available PC .

The director looked at me and said "Holy @#$!"

-brig
 
Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Stephen Sprunk wrote:
> That's only needed if you need additional drivers during install (e.g.
> SATA); alternately, users can modify the installation ISO to include
> additional drivers, but it's not for the faint of heart...

Yes, but a machine with SATA disks is probably a very modern one, and why on
earth do you want a floppy drive on a modern machine? Most Athlon64 boards
come with SATA (and only a few different SATA chipsets actually exist), so
including those SATA drivers into the OS designed to run on Athlon64 is
really mandatory.

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
 
Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

On Fri, 09 Jul 2004 04:11:32 -0400, George Macdonald wrote:

> On Fri, 09 Jul 2004 08:25:37 +0200, Ketil Malde <ketil@ii.uib.no> wrote:
>
>>Paul Gunson <spammersrot@mybasement.com> writes:
>>
>>> i was shocked to learn that it still required a floppy drive to
>>> install XP-64.
>>
>>I've been wondering why all new PCs seem to have them the last five
>>years 🙂
>
> Some of the large corps have had err, problems with theft of "important"
> info on USB flash drives. They're disabling the functionality down to
> keyboard/mouse as necessary.... and CD writers are also often banned from
> employee systems.

Really?! I hadn't heard that one. I just bought a flash drive for that
very reason (to take work home). It's a slick little Gizmo. In fact I
put a floppy in the new system just out of habit. I can't remember the
last time I used a floppy. If the data I need will fit on a floppy,
I just email it to myself.

Which reminds me; I have to get it working under Linux.

--
Keith
 
Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

On Fri, 09 Jul 2004 11:15:08 -0700, Keith <krw@att.bizzzz> wrote:

>On Fri, 09 Jul 2004 04:11:32 -0400, George Macdonald wrote:
>
>> On Fri, 09 Jul 2004 08:25:37 +0200, Ketil Malde <ketil@ii.uib.no> wrote:
>>
>>>Paul Gunson <spammersrot@mybasement.com> writes:
>>>
>>>> i was shocked to learn that it still required a floppy drive to
>>>> install XP-64.
>>>
>>>I've been wondering why all new PCs seem to have them the last five
>>>years 🙂
>>
>> Some of the large corps have had err, problems with theft of "important"
>> info on USB flash drives. They're disabling the functionality down to
>> keyboard/mouse as necessary.... and CD writers are also often banned from
>> employee systems.
>
>Really?! I hadn't heard that one.

Yup, one of the large JP auto mfrs found one of their latest, still secret,
car designs -- 3D-CAD stuff, the whole ball-a-wax -- published in a
magazine. Henceforth all USB flash connectors are to be "sealed off".
There was also the big scandal a few months ago, where Ferrari F1 designs
turned up at Toyota F1 along with a "new" ex-Ferrari employee - CD-R in
that case I believe.

I figure there's also gotta be a *big* potential problem with things like
medical record databases, govt. records, insurance records, etc. too and
that affects all of us.

> I just bought a flash drive for that
>very reason (to take work home). It's a slick little Gizmo. In fact I
>put a floppy in the new system just out of habit. I can't remember the
>last time I used a floppy. If the data I need will fit on a floppy,
>I just email it to myself.

Yeah well e-mail attachments are another thing - easy to limit size there
but something substantial *could* still get through I suppose. The USB
drives are a great convenience but the scope for abuse is huge - a
disgruntled employee could do a lot of damage.

Rgds, George Macdonald

"Just because they're paranoid doesn't mean you're not psychotic" - Who, me??
 
Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

"Brig Campbell" <brig...campbell@unisys...com> writes:

>At the presentation, I booted up my PC and shoved the flash drive in (8MB
>maybe...) I store all the presenations/whitepapers/propoganda on the flash
>so if someone requests it, I just dump it on their PC right there. Also
>helps if my PC dies, I use any available PC .

>The director looked at me and said "Holy @#$!"

I guess they understand the threat now; perhaps that is why most
flash drives come with rounded edges and a cord attached.

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
 
Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

"George Macdonald" <fammacd=!SPAM^nothanks@tellurian.com> wrote in message
news:fgkse0d7g5v3qq01sqei1qhefiunpdqd4t@4ax.com...
> On Fri, 09 Jul 2004 08:25:37 +0200, Ketil Malde <ketil@ii.uib.no> wrote:
> >Paul Gunson <spammersrot@mybasement.com> writes:
> >> i was shocked to learn that it still required a floppy drive to
> >> install XP-64.
> >
> >I've been wondering why all new PCs seem to have them the last five
> >years 🙂
>
> Some of the large corps have had err, problems with theft of "important"
> info on USB flash drives. They're disabling the functionality down to
> keyboard/mouse as necessary.... and CD writers are also often banned from
> employee systems.

Floppy drives have been banned (or at least disabled) at many large corps
for years; USB flash drives, CD writers, etc. are headed towards the same
fate.

Amusingly, the same corporations often have no problem with email
attachments.

S

--
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov
 
Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

On Sat, 10 Jul 2004 02:37:26 GMT, "Stephen Sprunk" <stephen@sprunk.org>
wrote:

>"George Macdonald" <fammacd=!SPAM^nothanks@tellurian.com> wrote in message
>news:fgkse0d7g5v3qq01sqei1qhefiunpdqd4t@4ax.com...
>> On Fri, 09 Jul 2004 08:25:37 +0200, Ketil Malde <ketil@ii.uib.no> wrote:
>> >Paul Gunson <spammersrot@mybasement.com> writes:
>> >> i was shocked to learn that it still required a floppy drive to
>> >> install XP-64.
>> >
>> >I've been wondering why all new PCs seem to have them the last five
>> >years 🙂
>>
>> Some of the large corps have had err, problems with theft of "important"
>> info on USB flash drives. They're disabling the functionality down to
>> keyboard/mouse as necessary.... and CD writers are also often banned from
>> employee systems.
>
>Floppy drives have been banned (or at least disabled) at many large corps
>for years; USB flash drives, CD writers, etc. are headed towards the same
>fate.

The scale of and scope for abuse with USB flash and CD is somewhat bigger
though. This could be what drives TCPA, or some extansion thereof,
forwards and into widespread corporate acceptance.

>Amusingly, the same corporations often have no problem with email
>attachments.

I'm seeing more and more restrictions there too in terms of content and
size though it's partially driven by SPAM/virus considerations.

Rgds, George Macdonald

"Just because they're paranoid doesn't mean you're not psychotic" - Who, me??
 
Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

In comp.arch Stephen Sprunk <stephen@sprunk.org> wrote:
> "George Macdonald" <fammacd=!SPAM^nothanks@tellurian.com> wrote in message
> news:fgkse0d7g5v3qq01sqei1qhefiunpdqd4t@4ax.com...
> > On Fri, 09 Jul 2004 08:25:37 +0200, Ketil Malde <ketil@ii.uib.no> wrote:
> > >Paul Gunson <spammersrot@mybasement.com> writes:
> > >> i was shocked to learn that it still required a floppy drive to
> > >> install XP-64.
> > >
> > >I've been wondering why all new PCs seem to have them the last five
> > >years 🙂
> >
> > Some of the large corps have had err, problems with theft of "important"
> > info on USB flash drives. They're disabling the functionality down to
> > keyboard/mouse as necessary.... and CD writers are also often banned from
> > employee systems.
>
> Floppy drives have been banned (or at least disabled) at many large corps
> for years; USB flash drives, CD writers, etc. are headed towards the same
> fate.
>
> Amusingly, the same corporations often have no problem with email
> attachments.

yeah, and as long as you can connect to a web server outside the "perimter"
you can upload the doc via HTTP POST anyways. Security by mandate from those
who do not understand security at all is just an excercice in pointless
futility.

You either trust people you are letting to handle the sensitive documents and
can expect them to not play loose with them or they have to be on non-networked
computers with no removable media. And you had better be sure they aren't walking
in with a digicam or writing stuff down from memory.

Its a 'you lose or you lose a lot of money and lose anyways' situation.

>
> S
>

--
Sander

+++ Out of cheese error +++
 
Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Nick Maclaren wrote:
> In article <1089305308.466753@teapot.planet.gong>,
> Rupert Pigott <roo@try-removing-this.darkboong.demon.co.uk> wrote:
>
>>Stuff like sparse addressing would be "hard" without paging or
>>something akin to it. In most other respects I think a friendly
>>segmentation scheme would be adequate. :)
>
>
> Can you give one SOLID reason why sparse addressing should be provided
> by hardware and privileged code? Note that, as usual, I am not talking

There is no explicit support for it in any of the languages I have
used and it appears that it would be hard to directly map it onto
C for example...

A "Might makes Right" kind of argument would be : On the systems
I've used it's always been done by the OS (ie: priviledged code +
hardware).

I guess those are not SOLID reasons, but it's the best I can think
of right now. :)

> about implementing the current methods in applications and libraries,
> but about providing equivalent functionality and efficiency.

No ideas are coming to mind about how I would go about faking holes
with other protection and mapping schemes... I usually can come up
with a few good/bad ideas fairly quickly. Drawing a blank is usually
a warning sign for me.

Cheers,
Rupert
 
Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

"Sander Vesik" <sander@haldjas.folklore.ee> wrote in message
news:1089495959.612118@haldjas.folklore.ee...
> In comp.arch Stephen Sprunk <stephen@sprunk.org> wrote:
> > Floppy drives have been banned (or at least disabled) at many large
corps
> > for years; USB flash drives, CD writers, etc. are headed towards the
same
> > fate.
> >
> > Amusingly, the same corporations often have no problem with email
> > attachments.
>
> yeah, and as long as you can connect to a web server outside the
"perimter"
> you can upload the doc via HTTP POST anyways. Security by mandate from
those
> who do not understand security at all is just an excercice in pointless
> futility.


The whole concept of a "perimeter" is pretty meaningless in the digital
world, and it's flawed at best in the physical world -- it assumes only good
guys are on the inside. Very few corps I've worked with do much in the way
of protecting internal data, other than what's legally required for
financial and HR stuff.

I think the problem is when you let physical security guys take over
information security; they just can't wrap their minds around the types of
threats that guys like us can come up with...

> You either trust people you are letting to handle the sensitive documents
> and can expect them to not play loose with them or they have to be on
> non-networked computers with no removable media. And you had better
> be sure they aren't walking in with a digicam or writing stuff down from
> memory.

I've been to several non-classified military and defense contractor
facilities, and it's amazing the variations on the same broken theme...
Some search your stuff, some just ask what you have. Some hold floppies,
CD-RWs, flash drives, or some subset of those while you're inside, others
don't. Some take away digital cameras only, but others also take computers,
cell phones, etc. None have ever searched me on the way out, even when I'm
visibly bringing out papers or discs I didn't bring in.

A few places are draconian enough that it's more efficient for the staff to
have an off-site facility to meet with vendors, customers, etc. that isn't
subject to any security rules. Our tax dollars at work...

S

--
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov
 
Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Sander Vesik wrote:

> yeah, and as long as you can connect to a web server outside the "perimter"
> you can upload the doc via HTTP POST anyways. Security by mandate from those
> who do not understand security at all is just an excercice in pointless
> futility.

Or you make DNS requests for [counter].[data].outsideparty.com and teh
name server logs whatever [data] is requested, and [serial] increments
to keep data in order and to prevent caching.

This means you need to install a program to do this, but it leaks
information out pretty well.


Thomas
 
Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

In article <1089493638.120739@teapot.planet.gong>,
Rupert Pigott <roo@try-removing-this.darkboong.demon.co.uk> wrote:
>>
>> Can you give one SOLID reason why sparse addressing should be provided
>> by hardware and privileged code? Note that, as usual, I am not talking
>
>There is no explicit support for it in any of the languages I have
>used and it appears that it would be hard to directly map it onto
>C for example...

Actually, no, it's quite easy. The problem (as always with C) is that
the lack of restrictions means that it is too easy to access the data
improperly by oversight or negligence. And the better way (which needs
modern hardware to be upgraded to 1960s levels) would help with that.

>A "Might makes Right" kind of argument would be : On the systems
>I've used it's always been done by the OS (ie: priviledged code +
>hardware).

Yes. The exceptions to that are mostly 1960s.

>> about implementing the current methods in applications and libraries,
>> but about providing equivalent functionality and efficiency.
>
>No ideas are coming to mind about how I would go about faking holes
>with other protection and mapping schemes... I usually can come up
>with a few good/bad ideas fairly quickly. Drawing a blank is usually
>a warning sign for me.

Well, I don't have a blank, so here are two implementations:

1) Access is via macros, which are coded very like getc - i.e.
if the pointer is present, it is accessed directly, otherwise a
function is called. No operating system assistance needed, but
problems as above.

2) The hardware provides user-mode trapping of SIGSEGV, and the
logic is moved from the kernel to the language run-time system.
This is the right way to do this, in the sense that operations that
affect solely the process are handled solely by the process.


Regards,
Nick Maclaren.
 
Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

"Bob Niland" <email4rjn@yahoo.com> wrote in message
news:d97c4731.0407061136.4aa816a2@posting.google.com...
> > ... a number of PCI masters in the field do not support DAC.
>
> Does PCI Express fix this problem by mandating
> 64-bit compliance?
>
> Sometimes the fix for old I/O problems is just
> to junk the old standard. It was my impression
> that PCI itself was in part a way to "solve"
> the lack of shared-IRQ support on ISA.
>
> I'm sure that PCI-E also fixes the voltage problem
> (5v-tolerant 3.3v universal PCI cards are common,
> but universal slots are uneconomical, with the result
> that 66MHz and faster PCI slots are rare in retail PCs,
> even though some of us could use the speed). And, without
> having seen the spec, I'll bet PCI-E fixes the clocking
> problem too (the max speed of shared slots is limited
> to the slowest installed card).

PCI express fixes the "voltage problem" by mandating DC blocking caps.
And it fixes the "clocking problem" by only having one data rate,
although it does now have a "width problem" in that, I believe, like
InfiniBand it negotiates to the largest common width between the two
ends.
>
> > This is a huge problem with EM64T right now.
>
> Since we haven't seen 64-bit benchmarks yet, there
> could be "huger" problems. But in any case, not many
> EM64T systems will be run in 64-bit mode this year,
> and few of those with over 4GB. By year end, Intel
> will likely have fixed this oversight (along with
> some others they missed when they cloned AMD64).
>
> --
> Regards, Bob Niland mailto:name@ispname.tld
> http://www.access-one.com/rjn email4rjn AT yahoo DOT com
> NOT speaking for any employer, client or Internet Service Provider.
 
Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

"del cecchi" <dcecchi.nojunk@att.net> wrote in message
news:2le87nFb8k3mU1@uni-berlin.de...
>
> "Bob Niland" <email4rjn@yahoo.com> wrote in message
> news:d97c4731.0407061136.4aa816a2@posting.google.com...
> > > ... a number of PCI masters in the field do not support DAC.
> >
> > Does PCI Express fix this problem by mandating
> > 64-bit compliance?
> >
> > Sometimes the fix for old I/O problems is just
> > to junk the old standard. It was my impression
> > that PCI itself was in part a way to "solve"
> > the lack of shared-IRQ support on ISA.
> >
> > I'm sure that PCI-E also fixes the voltage problem
> > (5v-tolerant 3.3v universal PCI cards are common,
> > but universal slots are uneconomical, with the result
> > that 66MHz and faster PCI slots are rare in retail PCs,
> > even though some of us could use the speed). And, without
> > having seen the spec, I'll bet PCI-E fixes the clocking
> > problem too (the max speed of shared slots is limited
> > to the slowest installed card).
>
> PCI express fixes the "voltage problem" by mandating DC blocking caps.
> And it fixes the "clocking problem" by only having one data rate,

At least for now. Are you saying that we will never have a "version 2" that
supports a higher signalling rate? The evidence from all (well, at least
most) other serial interfaces is that such things will happen.

--
- Stephen Fuld
e-mail address disguised to prevent spam
 
Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

> The scale of and scope for abuse with USB flash and CD is somewhat bigger
> though. This could be what drives TCPA, or some extansion thereof,
> forwards and into widespread corporate acceptance.

You don't need TCPA for that - traditional access control mechanisms are
quite enough.

How do these guys handle it when the USB ports are required to connect to,
e.g., printers or other peripherals?

Jan
 
Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

=?ISO-8859-1?Q?Jan_Vorbr=FCggen?= <jvorbrueggen-not@mediasec.de> writes:

>> The scale of and scope for abuse with USB flash and CD is somewhat bigger
>> though. This could be what drives TCPA, or some extansion thereof,
>> forwards and into widespread corporate acceptance.

>You don't need TCPA for that - traditional access control mechanisms are
>quite enough.

>How do these guys handle it when the USB ports are required to connect to,
>e.g., printers or other peripherals?

The only feasible thing, I think, is disabling the drivers
for the specific hardware; with USB keyboards being the norm,
I'm sure someone will come up with a USB vampire tap/hub to
use if there are no available or accessible USB slots.

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
 
Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

On Mon, 12 Jul 2004 09:35:38 +0200, Jan Vorbrüggen
<jvorbrueggen-not@mediasec.de> wrote:

>> The scale of and scope for abuse with USB flash and CD is somewhat bigger
>> though. This could be what drives TCPA, or some extansion thereof,
>> forwards and into widespread corporate acceptance.
>
>You don't need TCPA for that - traditional access control mechanisms are
>quite enough.

For what? I'm talking about info theft/security in general. There's no
doubt that high capacity portable devices add risk for all kinds of
corporate info and corporations, even small ones, realized long ago that
people abuse privileges.

>How do these guys handle it when the USB ports are required to connect to,
>e.g., printers or other peripherals?

I'm not sure what was meant by "sealed off" and it hadn't actually happened
last time I umm "talked". I can think of several things: 1) driver shields
in the OS; 2) physical disconnection of all but keyboard & possibly mouse;
3) special interposer connectors. I don't see much need for physical
connection of printers and other peripherals in a corporate environment.

Rgds, George Macdonald

"Just because they're paranoid doesn't mean you're not psychotic" - Who, me??
 
Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

>>How do these guys handle it when the USB ports are required to connect to,
>>e.g., printers or other peripherals?
> The only feasible thing, I think, is disabling the drivers
> for the specific hardware; with USB keyboards being the norm,
> I'm sure someone will come up with a USB vampire tap/hub to
> use if there are no available or accessible USB slots.

No, one should have security policies on classes of devices (vf. VMS).
That would, for instance, allow you to mount a USB disk read-only, if
wanted, or to deny access to that class of device totally, if so desired,
without recurring to such an error-prone procedure as disabling drivers.

Jan
 
Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

>> Here, tho, I have to disagree: I can't think of any type-safe language
>> where the compiler would be able to make good use of segments. You might
>> be able to keep most objects in a flat space and then map every array to
>> a segment (thus benefitting from the segment's bounds check), but it's
>> probably going to be too much trouble considering the risk that it will
>> suffer pathological degradation on programs that use a large number of
>> small arrays (because the hardware would have a hard time managing
>> efficiently thousands of actively used segments).
>>
> After using Pascal & Algol on a Unisys NX (nee. A series) machine, I really
> have to disagree. Both make "segments" for every array dimension, and
> record (structure) that is allocated.

In what way is that "making good use" of segments ?
For arrays, it can reduce the time taken to do array-bounds checks, but for
records it's a waste.

By the way, what do those "segments" look like? I.e. are the bounds
actually checked by hardware (I assume so, but IIRC the A series were fairly
unusual)? If so, where do you keep the size information, and who sets it
up (i.e. what is the cost in terms of memory management and such)?

> The OS and the languages really don't have a problem with this.

Indeed, they shouldn't, but the question is: do you get any benefit
from using segments rather than using explicit software bounds checks
(which might be optimized away, of course)?

>> In theory, yes. In practice, it's very difficult for the compiler to
>> figure out how to compile the thing (I gather that one of the difficulty is
>> to figure out whether "foo *bar" is a pointer to an object `foo' or
>> a pointer to an array of `foo's or a pointer to one of the elements of an
>> array of `foo's).
>>
> Yes, for a C compiler, because C (and the programs written in it) assume
> you can do differences on pointers, that a pointer is a single "word", that
> it can fit into some kind of integer, that the address space is flat, etc,
> etc.

> Use a language that doesn't let you assume those things (Algol or Pascal),
> and a pointer is a pointer.

This part of the thread is specifically about compiling C (or a subset
thereof) safely.


Stefan
 
Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

In Windows there is one little known way to disable automatic installation
of selected classes, based on user permissions.
Article http://support.microsoft.com/default.aspx?scid=kb;en-us;823732 tells
it for USB storage, but can be extended for other classes.

"Casper H.S. Dik" <Casper.Dik@Sun.COM> wrote in message
news:40f28750$0$34762$e4fe514c@news.xs4all.nl...
> =?ISO-8859-1?Q?Jan_Vorbr=FCggen?= <jvorbrueggen-not@mediasec.de> writes:
>
> >> The scale of and scope for abuse with USB flash and CD is somewhat
bigger
> >> though. This could be what drives TCPA, or some extansion thereof,
> >> forwards and into widespread corporate acceptance.
>
> >You don't need TCPA for that - traditional access control mechanisms are
> >quite enough.
>
> >How do these guys handle it when the USB ports are required to connect
to,
> >e.g., printers or other peripherals?
>
> The only feasible thing, I think, is disabling the drivers
> for the specific hardware; with USB keyboards being the norm,
> I'm sure someone will come up with a USB vampire tap/hub to
> use if there are no available or accessible USB slots.
>
> Casper
> --
> Expressed in this posting are my opinions. They are in no way related
> to opinions held by my employer, Sun Microsystems.
> Statements on Sun products included here are not gospel and may
> be fiction rather than truth.
 
Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

>> Indeed, they shouldn't, but the question is: do you get any benefit
>> from using segments rather than using explicit software bounds checks
>> (which might be optimized away, of course)?

> You can implement fine grained security models for less run-time
> hit. Security is important now and will continue to become more
> important as people become more dependant on electronic widgets.

But if you can either trust the compiler or verify the compiler's output,
then you get the same benefit, right?


Stefan "who works on certifying compilation"
 
Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

Stefan Monnier wrote:

> Indeed, they shouldn't, but the question is: do you get any benefit
> from using segments rather than using explicit software bounds checks
> (which might be optimized away, of course)?

You can implement fine grained security models for less run-time
hit. Security is important now and will continue to become more
important as people become more dependant on electronic widgets.


Cheers,
RUpert
 
Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

In comp.arch Jan Vorbr?ggen <jvorbrueggen-not@mediasec.de> wrote:
> >>How do these guys handle it when the USB ports are required to connect to,
> >>e.g., printers or other peripherals?
> > The only feasible thing, I think, is disabling the drivers
> > for the specific hardware; with USB keyboards being the norm,
> > I'm sure someone will come up with a USB vampire tap/hub to
> > use if there are no available or accessible USB slots.
>
> No, one should have security policies on classes of devices (vf. VMS).
> That would, for instance, allow you to mount a USB disk read-only, if
> wanted, or to deny access to that class of device totally, if so desired,
> without recurring to such an error-prone procedure as disabling drivers.

But this disables both usb based flas drives and usb connected cdroms in
one go. what if your machine has a usb (and not sata) based cdrom in a
couple of years?

>
> Jan

--
Sander

+++ Out of cheese error +++
 
Archived from groups: comp.arch,comp.sys.ibm.pc.hardware.chips,comp.sys.intel (More info?)

>>No, one should have security policies on classes of devices (vf. VMS).
>>That would, for instance, allow you to mount a USB disk read-only, if
>>wanted, or to deny access to that class of device totally, if so desired,
>>without recurring to such an error-prone procedure as disabling drivers.
> But this disables both usb based flas drives and usb connected cdroms in
> one go. what if your machine has a usb (and not sata) based cdrom in a
> couple of years?

Note the "mount...read-only" above. Alternatively, you might also want
to stop your lusers from importing malware into your intranet - and then
even CD-ROMs are a no-no.

Jan