Simon's postings would tend to indicate that he believes that
anything not subject to constant probing by hundreds or thousands
of hack.., er, security researchers is just full of latent bugs
waiting to be discovered.
Hundreds of researchers are only a few times as effective as one. I've
done some of this, and worked with people who do more: given good tools,
a few man-months can make significant improvements. In the order in which they were used:
Valgrind is a binary instrumentation tool: it decompiles an executable
into a higher-level abstract machine language, inserts instrumentation
and recompiles that into the machine language. It doesn't need source, although it does need debug symbols. https://valgrind.org/ It gets used
for building many kinds of execution monitors and checking tools.
The only one I've used is Memcheck, which finds usage of uninitialised
data, by the brute-force technique of tracking the initialisation status
of every byte of memory in the process. This is too slow to use in production, but I spent a few months tracking down and fixing all the
uses of uninitialised memory, and we basically stopped getting
unrepeatable run-time errors. Now one of the junior engineers keeps it running through all our tests on a regular basis and fixing newly added
uses of uninitialised data.
Our QA team use another Valgrnd tool, Callgrind, to track which files and functions are called by all of our tests. Keeping this up to date keeps a
few machines busy full-time, but it's invaluable. The data is kept in an
SQL database in inverted form, so when developers change source, they can find out which test cases go through the changed files in seconds, and
run those test cases to find and fix regressions before they release
changes into source-management.
Valgrind runs on Unix-like operating systems. I run it on x86-64 Linux,
which is by far the most-used platform.
Static analysis starts with a compile-like process, in which you run all
your source through an analysis tool that behaves like a compiler.
There's then a pretty heavyweight process of matching up all the
functions, variables and possible execution paths, and then you have data that can be used to spot security problems, via further automatic
analysis. It's kind of like "lint" on a whole-program basis. The tool I
use is Coverity, which is commercial, and got picked for us by the larger company. It isn't brilliant, but it works. It runs on Windows, Linux and
Mac.
<https://www.synopsys.com/software-integrity/static-analysis-tools-sast/co verity.html>
Fuzz testing is the main thing that security researchers do. Digging
through disassembly listings for vulnerabilities by eye is very slow and unreliable. You need to be able to run the software you're "fuzzing" and
to be able to feed it a data file. You use a fuzz testing tool which runs
the software and monitors it for segmentation violations and other exceptions. It also mutates the data file, by modifying, inserting and removing bytes. A bit of correlation analysis lets it find its way to
minimal test cases for exceptions. This burns up a fair bit of CPU power: people in my team have had four or eight threads on an old x86-64 box
running for about a year. In that time, we've found and fixed a bit more
than one defect per working day.
There are lots of frameworks for fuzzing, but AFL <https://en.wikipedia.org/wiki/American_Fuzzy_Lop_(software)> is
considered pretty good, and is what we use.
On 1/19/2024 4:46 PM, John Dallman wrote:
Valgrind runs on Unix-like operating systems. I run it on x86-64
Linux, which is by far the most-used platform.
Those tools are mostly C/C++ centric right?
If one would be a little cynical: tools to mitigate those languages
lack of the strictness found in other languages.
In article <uof4t2$3c1i2$1@dont-email.me>, arne@vajhoej.dk (Arne Vajhøj) wrote:
On 1/19/2024 4:46 PM, John Dallman wrote:
Valgrind runs on Unix-like operating systems. I run it on x86-64
Linux, which is by far the most-used platform.
Those tools are mostly C/C++ centric right?
* Valgrind works on binaries and has no idea what HLL you used. Most
fuzzers are the same AFAIK.
I wonder how difficult it would be to get it running
on VMS x86-64. ELF image format and x86-64 instruction
set are already done. But I assume it would need to know
about various RTL.
In article <uogs7c$3o3e0$2@dont-email.me>, arne@vajhoej.dk (Arne Vajhøj) wrote:
I wonder how difficult it would be to get it running
on VMS x86-64. ELF image format and x86-64 instruction
set are already done. But I assume it would need to know
about various RTL.
It certainly needs to know about run-times. Valgrind itself is C. The project's platforms page says:
Windows is not under consideration because porting to it would require
so many changes it would almost be a separate project. ... Also,
non-open-source OSes are difficult to deal with; being able to see
the OS and associated (libc) source code makes things much easier.
VMS is not Windows, but their respective difference from Linux are on a similar scale. VSI could presumably port it, but it is clearly a long way from being the most urgent thing for them to do.
VSI could presumably port [valgrind], but it is clearly a long
way from being the most urgent thing for them to do.
VSI could presumably port [valgrind], but it is clearly a longOn the other hand, it would be something else that they could get
way from being the most urgent thing for them to do.
essentially for free with a Linux port.
That's two quite hard
things, and starting on them now makes less sense than carrying on with
the current strategy, for good or ill.
On Sun, 21 Jan 2024 10:10 +0000 (GMT Standard Time), John Dallman wrote:
That's two quite hard
things, and starting on them now makes less sense than carrying on with
the current strategy, for good or ill.
I think that?s called the ?sunk-cost fallacy?.
On 2024-01-21, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Sun, 21 Jan 2024 10:10 +0000 (GMT Standard Time), John Dallman wrote:
That's two quite hard
things, and starting on them now makes less sense than carrying on with
the current strategy, for good or ill.
I think that?s called the ?sunk-cost fallacy?.
So VSI's choices are to either continue selling x86-64 systems to customers >and complete the missing bits, or they stop selling systems for 3 years
while they write a migration tool from the ground up for something that
will never be as close in operation as the first option above.
Hmmm, I wonder which option they will choose ? :-)
Lawrence, you manage to make the current bunch of extreme zealots on both >sides of the political landscape in the US seem reasonable.
Lawrence, you manage to make the current bunch of extreme zealots on
both sides of the political landscape in the US seem reasonable.
On 2024-01-21, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Sun, 21 Jan 2024 10:10 +0000 (GMT Standard Time), John Dallman wrote:
That's two quite hard things, and starting on them now makes less sense
than carrying on with the current strategy, for good or ill.
I think that?s called the ?sunk-cost fallacy?.
So VSI's choices are to either continue selling x86-64 systems to
customers and complete the missing bits, or they stop selling systems
for 3 years while they write a migration tool from the ground up for something that will never be as close in operation as the first option
above.
Hmmm, I wonder which option they will choose ? :-)
Lawrence, you manage to make the current bunch of extreme zealots on
both sides of the political landscape in the US seem reasonable.
In article <uolqc2$o1rq$4@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
On 2024-01-21, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Sun, 21 Jan 2024 10:10 +0000 (GMT Standard Time), John Dallman wrote: >>>
That's two quite hard
things, and starting on them now makes less sense than carrying on with >>>> the current strategy, for good or ill.
I think that?s called the ?sunk-cost fallacy?.
So VSI's choices are to either continue selling x86-64 systems to customers >>and complete the missing bits, or they stop selling systems for 3 years >>while they write a migration tool from the ground up for something that >>will never be as close in operation as the first option above.
Hmmm, I wonder which option they will choose ? :-)
Lawrence, you manage to make the current bunch of extreme zealots on both >>sides of the political landscape in the US seem reasonable.
I would suggest respectfully to stop feeding the troll. Or, as
I suspect he's less a troll than just a crank, perhaps stop
turning the crank.
On 2024-01-22, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
In article <uolqc2$o1rq$4@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
On 2024-01-21, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Sun, 21 Jan 2024 10:10 +0000 (GMT Standard Time), John Dallman wrote: >>>>
That's two quite hard
things, and starting on them now makes less sense than carrying on with >>>>> the current strategy, for good or ill.
I think that?s called the ?sunk-cost fallacy?.
So VSI's choices are to either continue selling x86-64 systems to customers >>> and complete the missing bits, or they stop selling systems for 3 years
while they write a migration tool from the ground up for something that
will never be as close in operation as the first option above.
Hmmm, I wonder which option they will choose ? :-)
Lawrence, you manage to make the current bunch of extreme zealots on both >>> sides of the political landscape in the US seem reasonable.
I would suggest respectfully to stop feeding the troll. Or, as
I suspect he's less a troll than just a crank, perhaps stop
turning the crank.
I know Dan. I'm finally at the end of trying to reason with him, and
I have come to the same conclusion that others have, but I consider it
rude to just stop talking to someone without explaining why, which
I have now done. :-)
Simon.
What is really rude is talking about Linux on c.o.v ...
On 2024-01-23, Dave Froble <davef@tsoft-inc.com> wrote:
What is really rude is talking about Linux on c.o.v ...
Unless you consider VMS to be perfect and not in need of any improvement, other operating systems offer some good ideas that it would be nice to
see in VMS, especially around security and internal isolation in general.
Simon.
On 1/23/2024 5:36 PM, Dave Froble wrote:
On 1/23/2024 8:13 AM, Simon Clubley wrote:
On 2024-01-22, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
In article <uolqc2$o1rq$4@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
On 2024-01-21, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
On Sun, 21 Jan 2024 10:10 +0000 (GMT Standard Time), John Dallman wrote: >>>>>>
That's two quite hard
things, and starting on them now makes less sense than carrying on with >>>>>>> the current strategy, for good or ill.
I think that?s called the ?sunk-cost fallacy?.
So VSI's choices are to either continue selling x86-64 systems to customers
and complete the missing bits, or they stop selling systems for 3 years >>>>> while they write a migration tool from the ground up for something that >>>>> will never be as close in operation as the first option above.
Hmmm, I wonder which option they will choose ? :-)
Lawrence, you manage to make the current bunch of extreme zealots on both >>>>> sides of the political landscape in the US seem reasonable.
I would suggest respectfully to stop feeding the troll. Or, as
I suspect he's less a troll than just a crank, perhaps stop
turning the crank.
I know Dan. I'm finally at the end of trying to reason with him, and
I have come to the same conclusion that others have, but I consider it
rude to just stop talking to someone without explaining why, which
I have now done. :-)
Simon.
What is really rude is talking about Linux on c.o.v ...
I don't know about rude, but even suggesting that the VMS kernel
(which now runs just fine on x86-64) should be replaced with a
Linux kernel has to be the stupidest idea I have ever seen here.
bill
Not gonna happen. Not until well after VSI is a whole lot bigger and a
whole lot better funded, and is encountering some hard limits in their
chosen hardware platform and tooling.
And I still haven't heard a sales pitch for which kernel to pick, as
Linux is but one of many fine choices. And GPL'd Linux quite possibly
not the best choice for grafting a closed-source commercial platform.
I don't know about rude, but even suggesting that the VMS kernel (which
now runs just fine on x86-64) should be replaced with a Linux kernel has
to be the stupidest idea I have ever seen here.
On Mon, 22 Jan 2024 14:04:13 -0500, Stephen Hoffman wrote:
Not gonna happen. Not until well after VSI is a whole lot bigger and a
whole lot better funded, and is encountering some hard limits in their
chosen hardware platform and tooling.
You tell me: either it is too late, or it’s not. If it is, then VMS is already essentially circling the plughole.
And I still haven't heard a sales pitch for which kernel to pick, as
Linux is but one of many fine choices. And GPL'd Linux quite possibly
not the best choice for grafting a closed-source commercial platform.
Businesses like to take, but not give back, don’t they?
Many have criticized the GPL on this basis, but one thing it has helped to ensure is a level playing field. That’s why so many businesses have
adopted GPL’d software, regardless of their earlier carping--because their competitors had done so, and they didn’t want to be left behind.
Compare the BSDs: there have been several startups over the years that
took the BSD code and made it proprietary, because the licence allows you
to do that. Most startups fail, as you may know. When those startups
failed, their proprietary code died with them. And so the BSD ecosystem
lost yet another bit of its lifeblood.
But when startups build their product on GPL’d code, then if/when they
die, their code lives on, perhaps to fertilize the soil where another
startup can grow.
This reminds me of something. Anybody remember the Sun employee that
used to come here and harass us? Andrew something maybe?
On 1/27/2024 12:36 AM, Dave Froble wrote:
This reminds me of something. Anybody remember the Sun employee that used to
come here and harass us? Andrew something maybe?
Andrew Harrison
Arne
On 1/27/2024 8:44 AM, Arne Vajhøj wrote:
On 1/27/2024 12:36 AM, Dave Froble wrote:
This reminds me of something. Anybody remember the Sun employee that used to
come here and harass us? Andrew something maybe?
Andrew Harrison
You think maybe he changed his name?
In article <up3ltv$c4l$1@reader1.panix.com>,
cross@spitfire.i.gajendra.net (Dan Cross) wrote:
In article <up3dc9$3f7b4$1@dont-email.me>,
Dave Froble <davef@tsoft-inc.com> wrote:
You think maybe he changed his name?I doubt the current troll could have gotten a job at Sun.
I met some remarkably useless Sun marketing managers.
In article <up3dc9$3f7b4$1@dont-email.me>,
Dave Froble <davef@tsoft-inc.com> wrote:
You think maybe he changed his name?I doubt the current troll could have gotten a job at Sun.
In article <up3dc9$3f7b4$1@dont-email.me>,
Dave Froble <davef@tsoft-inc.com> wrote:
On 1/27/2024 8:44 AM, Arne Vajhøj wrote:
On 1/27/2024 12:36 AM, Dave Froble wrote:
This reminds me of something. Anybody remember the Sun employee that used to
come here and harass us? Andrew something maybe?
Andrew Harrison
You think maybe he changed his name?
I doubt the current troll could have gotten a job at Sun.
- Dan C.
Dave Froble <davef@tsoft-inc.com> wrote:
On 1/27/2024 8:44 AM, Arne Vajhøj wrote:
On 1/27/2024 12:36 AM, Dave Froble wrote:
This reminds me of something. Anybody remember the Sun employee that used to
come here and harass us? Andrew something maybe?
Andrew Harrison
You think maybe he changed his name?
I doubt the current troll could have gotten a job at Sun.
Also I would expect anyone from Sun to be strongly anti-Linux. Here's a nickel, kid. Get yourself a real computer.
On 1/27/2024 8:44 AM, Arne Vajh�j wrote:
On 1/27/2024 12:36 AM, Dave Froble wrote:
This reminds me of something. Anybody remember the Sun employee that used to
come here and harass us? Andrew something maybe?
Andrew Harrison
Arne
You think maybe he changed his name?
On 2024-01-27, Dave Froble <davef@tsoft-inc.com> wrote:
On 1/27/2024 8:44 AM, Arne Vajhøj wrote:
On 1/27/2024 12:36 AM, Dave Froble wrote:
This reminds me of something. Anybody remember the Sun employee that used to
come here and harass us? Andrew something maybe?
Andrew Harrison
Arne
You think maybe he changed his name?
I'm not sure enough to post a link (and I am not joining LinkedIn to read
the full details), but it looks like he _may_ be working for Oracle in
their cloud division.
Do a search for "andrew harrison sun microsystems" (without quotes) and
see what you think...
Simon.
On 29/01/2024 13:20, Simon Clubley wrote:
On 2024-01-27, Dave Froble <davef@tsoft-inc.com> wrote:
On 1/27/2024 8:44 AM, Arne Vajh�j wrote:
On 1/27/2024 12:36 AM, Dave Froble wrote:
This reminds me of something. Anybody remember the Sun employee that used to
come here and harass us? Andrew something maybe?
Andrew Harrison
You think maybe he changed his name?
I'm not sure enough to post a link (and I am not joining LinkedIn to read
the full details), but it looks like he _may_ be working for Oracle in
their cloud division.
Do a search for "andrew harrison sun microsystems" (without quotes) and
see what you think...
Does that mean he passed away, and is advising from 'upstairs' ?
No. :-) Oracle really do have a cloud division and it looks like
Andrew might be working for them (if it is the same Andrew).
In article <up8pc2$id8p$1@dont-email.me>, clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote:
No. :-) Oracle really do have a cloud division and it looks like
Andrew might be working for them (if it is the same Andrew).
There's certainly an "Andy Harrison" working for Oracle as a "Cloud
Services Solution Architect" which may well be "Technical backup for
Sales, plus a fancy title". He is based in Reading, UK, and was acquired
by Oracle along with Sun. He's had a wide variety of experience in UNIX sysadmin and development; this is from his LinkedIn page.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 399 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 56:28:48 |
| Calls: | 8,343 |
| Calls today: | 3 |
| Files: | 13,159 |
| Messages: | 5,892,913 |