| View previous topic :: View next topic |
| Author |
Message |
server
Guest
|
 Posted: Mon Jun 23, 2003 6:10 pm Post subject: A Dark Day... |
 |
|
| message unavailable |
|
| |
|
 Back to top |
Larry M Headlund
Guest
|
| Posted: Mon Jun 23, 2003 6:10 pm Post subject: Re: A Dark Day... |
|
|
In article <q9b7db.a01.ln@teabag.cbhnet>,
Chris Hedley <cbh@ieya.co.REMOVE_THIS.uk> wrote:
| Quote: | According to Brian {Hamilton Kelly} <bhk@dsl.co.uk>:
In the UK one gets a tool called a "slater's axe". This has both the
above features, and also a wicked hooked cutter at the opposite end to
the handle, making it look rather like the sort of halbeards carried by
the orcs in LotR. This can be inserted underneath one slate and used to
rip through the nails, thus allowing a broken slate to be removed without
de-roofing entirely (the new slate being held in position by a Z-shaped
piece of metal looped over the top of the slate below the one removed).
They just don't seem to make interesting tools like that anymore, although
that sort of thing sounds like the type of "tool" that an after-sundown
Harlow denizen might be carrying on their person...
|
For the curious, there is a picture of a slater's axe at
<http://www.right-tool.com/whitslataxe.html>.
--
--
Larry Headlund lmh@world.std.com Mathematical Engineering, Inc.
(617) 242 7741
Unix, X and Motif Consulting Speaking for myself at most. |
|
| |
|
| Back to top |
Ignatios Souvatzis
Guest
|
| Posted: Mon Jun 23, 2003 8:16 pm Post subject: Re: Come from |
|
|
Tom Gardner <tggzzz@blueyonder.co.uk> writes:
| Quote: | foo+2 jump baz
...
baz: comefrom a
after executing the comefrom instruction,
register a contains foo+2
|
Ah, that's different from the Intercal come from.
-is |
|
| |
|
| Back to top |
Chris Hedley
Guest
|
| Posted: Mon Jun 23, 2003 9:53 pm Post subject: Re: A Dark Day... |
|
|
According to Brian {Hamilton Kelly} <bhk@dsl.co.uk>:
| Quote: | In the UK one gets a tool called a "slater's axe". This has both the
above features, and also a wicked hooked cutter at the opposite end to
the handle, making it look rather like the sort of halbeards carried by
the orcs in LotR. This can be inserted underneath one slate and used to
rip through the nails, thus allowing a broken slate to be removed without
de-roofing entirely (the new slate being held in position by a Z-shaped
piece of metal looped over the top of the slate below the one removed).
|
They just don't seem to make interesting tools like that anymore, although
that sort of thing sounds like the type of "tool" that an after-sundown
Harlow denizen might be carrying on their person...
Chris.
--
"If the world was an orange it would be like much too small, y'know?" Neil, '84
Currently playing: random early '80s radio stuff
http://www.chrishedley.com - assorted stuff, inc my genealogy. Gan canny! |
|
| |
|
| Back to top |
Jan Ingvoldstad
Guest
|
| Posted: Tue Jun 24, 2003 12:39 am Post subject: Re: A Dark Day... |
|
|
On 23 Jun 2003 01:49:02 GMT, peter@taronga.com (Peter da Silva) said:
| Quote: | In article <oas4r2hafar.fsf@sex.ifi.uio.no>,
Jan Ingvoldstad <jani+news-comp+@nntp.ifi.uio.no> wrote:
Corrolory: don't use trusting programs for untrusted input
You've forgotten to mention a very important one, that most
programmers keep forgetting:
- Don't give unchecked input to other applications
(because valid, quoted input can still wreck havoc in other
applications)
This is "don't use trusting programs for untrusted input".
|
Well, sort of, but from the other side. _You_ may not have control
over the trusting program on the receiving end. What I tried to point
out would probably come better across as:
- don't send untrusted input to programs you don't control
I think the difference in perspective is worth pointing out, but
YMMV.
| Quote: | If you have an application that is written under the assumption that its
input is untrusted, then you can safely pass it untrusted input.
If you don't, then you have to completely parse the input and
generate new known-safe information for the next program. Which
is MUCH more than "Don't give unchecked input to other
applications".
|
Of course it is, just as there is more to it than what you wrote in
the former article. :)
| Quote: | And "provide known-safe input" may involve
converting the input to BASE64, storing it in a file and
passing a filename, and otherwise going far beyond "checking".
|
Or it might involve rejecting impossible input.
| Quote: | (Interestingly enough, it covers those pesky "pass this to the shell
script" thingies as well as databases and whatnot.)
And if your name is "da Silva" or "O'Shea" you get really tired of
programs that think the best way to handle this problem is to strip
out all possible metacharacters.
|
Relevance to my post?
| Quote: | - Data from other applications is input, too
If you don't follow this, then you are a "trusting program", and
should not be used.
|
Quite. I thought it needed spelling out, though.
| Quote: | Interested parties would definitely benefit from Sverre Huseby's
forthcoming book on secure programming, to be published by Wiley. (No
title set yet, though from what I heard, a publishing date sometime
late this autumn is likely.)
Lord save us.
|
So you don't think that there's a need for literature pointing out
these problems (the ones you yourself raised ...) and show how to deal
with them?
I do, because there is -- to my knowledge -- no such literature yet
today.
Those who don't intuitively understand the problem field should have
at least something to go by, other than a rag-taggle bunch of Usenet
posts. And if this had been bleedingly obvious enough, you wouldn't
be posting about it. :)
--
In the beginning was the Bit, and the Bit was Zero. Then Someone
said, Let there be One, and there was One. And Someone blessed them,
and Someone said unto them, Be fruitful, and multiply, and replenish
the Word and subdue it: and have dominion over every thing that is. |
|
| |
|
| Back to top |
Del Cecchi
Guest
|
| Posted: Tue Jun 24, 2003 1:10 am Post subject: Re: Of what use 64-bit "General Purpose" registers? |
|
|
In article <Xns93A275C423A80tggzzzmadasafishcom@193.38.113.46>,
Tom Gardner <tggzzz@blueyonder.co.uk> writes:
|> "del cecchi" <dcecchi@msn.com> wrote in
|> news:gl9Ja.293$IP6.13732@eagle.america.net:
|>
|> >
|> > "Tom Gardner" <tggzzz@blueyonder.co.uk> wrote in message
|> > news:Xns93A1A547BB9ECtggzzzmadasafishcom@193.38.113.46...
|> >> Bernd Paysan <bernd.paysan@gmx.de> wrote in
|> >> news:ksetcb-723.ln@cohen.paysan.nom:
|> >>
|> >> > Philip Homburg wrote:
|> >> >
|> >> >> On the other hand, you also know the
|> >> >> length of one cycle with an accuracy of about 1 ppm. Which
|> > translates
|> >> >> to 500 ps +/- 500 as.
|> >> >>
|> >> >> (Unless you are assuming that the CPU clock frequency is unstable
|> >> >> enough that it might run at 1 GHz at one moment and at 2 GHz at the
|> >> >> next).
|> >> >
|> >> > The CPU clock frequency might not be that stable, but the VCO of a
|> > PLL
|> >> > is a lot less stable than a chrystal, mostly due to noise injection
|> >> > from the supply. If your designer is careful, you can get some
|> > 10-100
|> >> > ppms, but that's usually only required for RF stuff (e.g. a 2.4GHz
|> >> > band within some 10kHz). A VCO for a CPU PLL would be good enough if
|> >> > it has a cycle-to-cycle jitter of 1%.
|> >>
|> >> The clock frequency is often modulated by a pseudo-random
|> >> noise source, so as to keep EM emissions within limits.
|> >> When this is done, the length of an individual cycle is, by
|> >> design, varied randomly; OTOH, the mean duration
|> >> of an individual cycle is still known.
|> >>
|> > Are you sure about the pseudo random noise source? All of the spread
|> > spectrum oscillators I am familiar with use a carefully designed spread
|> > waveform to spread the energy as even as possible. This idea was
|> > originally patented by Lexmark as I recall.
|> >
|> > Anyway the tolerance of the typical oscillator used in Intel based
|> > Desktops is 300 ppm, and there is jitter on top of that.
|>
|> That's precisely what a pseudo random source does! A good
|> source imitates white noise, i.e. a flat noise spectrum.
|> Easily achieved with a linear feedback shift register with
|> appropriate taps.
|>
I can find no evidence that folks are modulating the clock source with pseudo
random noise. I talked to my clocking buddy and looked briefly through delphion
for patents. Do you have a patent number? Author? I am interested in this.
At least one link technology uses pseudo random symbols as idles on the link to
reduce EMI.
--
Del Cecchi
cecchi@us.ibm.com
Personal Opinions Only |
|
| |
|
| Back to top |
Jack Peacock
Guest
|
| Posted: Tue Jun 24, 2003 1:18 am Post subject: Re: A Dark Day... |
|
|
"Larry M Headlund" <lmh@TheWorld.com> wrote in message
news:bd7fqh$qfs$1@pcls4.std.com...
| Quote: | For the curious, there is a picture of a slater's axe at
http://www.right-tool.com/whitslataxe.html>.
The description under the picture tells an interesting story too, "import |
quality". Made of the finest western [China] alloy steel, no doubt.
Jack Peacock |
|
| |
|
| Back to top |
Eric Smith
Guest
|
| Posted: Tue Jun 24, 2003 1:56 am Post subject: Re: AMD "long mode" deficiencies (Re: Of what use 64-bit "Ge |
|
|
bhurt@spnz.org (Brian Hurt) writes:
| Quote: | The solution (to this problem) is automatic bounds checking on array
accesses.
|
OK. Here's some C code that is a simplified version of real code I've
seen in an application that runs on Linux. The actual code was considerably
more complicated, having more arguments and doing various calculations in
each function, but I've shown the part that's problematic. It can be
argued that the code is simply poorly written, however that was less
obvious in the original version than in this simplified version. Anyhow,
the point of proposing protection mechanisms is that they should catch
cases where the code is poorly written.
In one source file:
void foo (char *s)
{
char s2 [40];
bar (s2, s);
}
In another source file:
void bar (char *a, char *b)
{
sprintf (a, "bar: %s\n", b);
}
How is the compiler (or linker, or run time system) going to perform
automatic bounds checking to solve this problem?
I still maintain that C and C++ are terrible languages for constructing
large scale software systems. |
|
| |
|
| Back to top |
Peter da Silva
Guest
|
| Posted: Tue Jun 24, 2003 1:59 am Post subject: Re: A Dark Day... |
|
|
In article <oas1xxka8iv.fsf@sex.ifi.uio.no>,
Jan Ingvoldstad <jani+news-comp+@nntp.ifi.uio.no> wrote:
| Quote: | This is "don't use trusting programs for untrusted input".
Well, sort of, but from the other side. _You_ may not have control
over the trusting program on the receiving end. What I tried to point
out would probably come better across as:
- don't send untrusted input to programs you don't control
|
I don't think that this is possible, in principle, in the general case.
There are programs you don't control that you have to trust.
Particularly if you're in the situation we started this in: a shell
script. For example, "sed"... you have to trust "sed" to work with
arbitrary stuff on stdin when you're using it to parse the untrusted
input, no?
Consider this example, if you've got a person's name, and that person's
name is first="Michael" middle="" last="de Vega-O'Flannagan", you
need to be able to put that in a database or pass it to a program,
you have to be able to trust that program to handle " " and "'" in
names. Even if you don't "control" it.
If you say:
- don't send untrusted input to programs you don't trust.
I'll agree 100%.
| Quote: | If you don't, then you have to completely parse the input and
generate new known-safe information for the next program. Which
is MUCH more than "Don't give unchecked input to other
applications".
Of course it is, just as there is more to it than what you wrote in
the former article. 
|
Which is why I wrote it. The point is that "checked" carries with it a
bunch of connotations that are really really dangerous. The goal should
be first to remove interfaces where additional parsing steps occur, and
once that is done *then* you look at what you need to do to make sure
it's parsed the right way.
I've already explained why at some length.
| Quote: | And "provide known-safe input" may involve
converting the input to BASE64, storing it in a file and
passing a filename, and otherwise going far beyond "checking".
Or it might involve rejecting impossible input.
|
That's necessary for a whole bunch of reasons beyond security, of
course.
| Quote: | (Interestingly enough, it covers those pesky "pass this to the shell
script" thingies as well as databases and whatnot.)
And if your name is "da Silva" or "O'Shea" you get really tired of
programs that think the best way to handle this problem is to strip
out all possible metacharacters.
Relevance to my post?
|
That pesky word "checked", because people see that word and think
they know what it means, particularly in the context of perl where
"taint checking" all too foten seems to mean a "[^a-zA-Z0-9]"
filter. And the biggest part of the last few posts I made on this
subject were pointing out at length that "checking" is the wrong
place to start to address these kinds of security problems.
| Quote: | So you don't think that there's a need for literature pointing out
these problems (the ones you yourself raised ...) and show how to deal
with them?
|
That depends on the emphasis it places on the solutions. I've run into
literature being authoritatively wrong before.
--
Rev. Peter da Silva, ULC. 29.6852N 95.5770W WWFD?
"Be conservative in what you generate, and liberal in what you accept"
-- Matthew 10:16 (l.trans) |
|
| |
|
| Back to top |
Del Cecchi
Guest
|
| Posted: Tue Jun 24, 2003 2:02 am Post subject: Re: Of what use 64-bit "General Purpose" registers? |
|
|
In article <0u47db.a1n.ln@miriam>,
Bernd Paysan <bernd.paysan@gmx.de> writes:
|> Del Cecchi wrote:
|>
|> > In article <ksetcb-723.ln@cohen.paysan.nom>,
|> > Bernd Paysan <bernd.paysan@gmx.de> writes:
|> > |> A VCO for a CPU PLL would be good enough if it has
|> > |> a cycle-to-cycle jitter of 1%.
|> >
|> > Yes it would. But 1% of 700 ps or 1.5GHz is only 7 ps. Not many CPU PLLs
|> > have jitter of only 7 ps p-p, much less to the +/- 7 sigma comm standard.
|>
|> Well, the tradeoff has to be made between PLL jitter and speed grading. CPUs
|> now offer different speed grades separated by as few as ~5%. If your PLL
|> jitter is 5%, you give away an entire speed grade. Maybe that's ok for
|> POWER, but I doubt that's ok for Intel and AMD. If they can improve the PLL
|> to get one speed grade higher, they'll do it. 1% is around the edge of
|> diminishing return, so that's definitely "good enough". It's not good
|> enough for RF, and RF is 2.4GHz (or 4.8GHz).
|>
|> Fortunately, low jitter PLL design is not exactly rocket science. For a
|> digital designer, 7ps sound a lot, when gate delays are significantly
|> longer. However, PLL jitter does not depend on delays, but on stability of
|> operating conditions, and noise reduction.
|>
|> --
|> Bernd Paysan
|> "If you want it done right, you have to do it yourself"
|> http://www.jwdt.com/~paysan/
Looks like it might be rocket science, or at least good enough to get you into
ISSCC as a presenter. Papers there were in the 1-2 ps RMS range. Depends on how
many sigmas you want, and what the DJ is.
Del.
--
Del Cecchi
cecchi@us.ibm.com
Personal Opinions Only |
|
| |
|
| Back to top |
Forrest Gump
Guest
|
| Posted: Tue Jun 24, 2003 2:41 am Post subject: Re: AMD "long mode" deficiencies (Re: Of what use 64-bit "Ge |
|
|
On Mon, 23 Jun 2003 16:56:20 -0400, Eric Smith wrote:
| Quote: | I still maintain that C and C++ are terrible languages for constructing
large scale software systems.
|
My Momma told me to never take any toys from eunuchs.
She said to me I can basically do whatever I visualize,
so I program in Microsoft Visual Basic for $10 an hour.
Spanked me so hard she did when I spilled java-flavored coffee
on her keyboard as I danced while watching the Sun go down. |
|
| |
|
| Back to top |
Greg Lindahl
Guest
|
| Posted: Tue Jun 24, 2003 3:05 am Post subject: Re: AMD "long mode" deficiencies (Re: Of what use 64-bit "Ge |
|
|
In article <qhu1agjyx7.fsf@ruckus.brouhaha.com>,
Eric Smith <eric-no-spam-for-me@brouhaha.com> wrote:
| Quote: | How is the compiler (or linker, or run time system) going to perform
automatic bounds checking to solve this problem?
|
You turn pointers into triples: (ptr, base, bound). Purify did this
ages ago, and gcc has a patch available to do it. It would be nice if
every C/C++ project had this kind of debugging used. At least we can
dream...
greg |
|
| |
|
| Back to top |
Carlo Razzeto
Guest
|
| Posted: Tue Jun 24, 2003 3:09 am Post subject: Re: AMD "long mode" deficiencies (Re: Of what use 64-bit "Ge |
|
|
Just out of curiosity, what do you think would be a good language for large
scale programs?
Carlo
"Eric Smith" <eric-no-spam-for-me@brouhaha.com> wrote in message
news:qhu1agjyx7.fsf@ruckus.brouhaha.com...
| Quote: | bhurt@spnz.org (Brian Hurt) writes:
The solution (to this problem) is automatic bounds checking on array
accesses.
OK. Here's some C code that is a simplified version of real code I've
seen in an application that runs on Linux. The actual code was
considerably
more complicated, having more arguments and doing various calculations in
each function, but I've shown the part that's problematic. It can be
argued that the code is simply poorly written, however that was less
obvious in the original version than in this simplified version. Anyhow,
the point of proposing protection mechanisms is that they should catch
cases where the code is poorly written.
In one source file:
void foo (char *s)
{
char s2 [40];
bar (s2, s);
}
In another source file:
void bar (char *a, char *b)
{
sprintf (a, "bar: %s\n", b);
}
How is the compiler (or linker, or run time system) going to perform
automatic bounds checking to solve this problem?
I still maintain that C and C++ are terrible languages for constructing
large scale software systems. |
|
|
| |
|
| Back to top |
Gene Wirchenko
Guest
|
| Posted: Tue Jun 24, 2003 3:46 am Post subject: Re: A Dark Day... |
|
|
Bernd Felsche <bernie@innovative.iinet.net.au> wrote:
| Quote: | Jan Ingvoldstad <jani+news-comp+@nntp.ifi.uio.no> writes:
On 22 Jun 2003 12:25:44 GMT, peter@taronga.com (Peter da Silva) said:
- Don't give unchecked input to other applications
(because valid, quoted input can still wreck havoc in other
applications)
But it's my job to wreck havoc.
|
"wreak", please.
Or, maybe, you do mean to do repairs?
Sincerely,
Gene Wirchenko
Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices. |
|
| |
|
| Back to top |
Greg Lindahl
Guest
|
| Posted: Tue Jun 24, 2003 4:33 am Post subject: Re: AMD "long mode" deficiencies (Re: Of what use 64-bit "Ge |
|
|
In article <crLJa.9522$C83.938124@newsread1.prod.itd.earthlink.net>,
Kojak <kojak@nospam.com> wrote:
| Quote: | That gcc patch hasnt been updated in 3 years 
|
See:
http://web.inter.nl.net/hcc/Haj.Ten.Brugge/
For a patch relative to gcc-3.3, the latest version.
-- greg |
|
| |
|
| Back to top |
|
