The new website www.crispeditor.co.uk is live, and its interesting to
watch who is accessing it. Right now, there are two main attempts
at cracking it - one is a WordPress vulnerability and the other, is
a PHP one. I guess the bots are hungry for food.
Also, it is interesting how quickly both Google and Bing start their bot
machines. That is encouraging. Very soon, I will be the most popular
website in the solar system - just keep clicking
and we might make it into the Interweb Hall of Fame.
Post created by CRiSP v12.0.6a-b6833
Sunday, 3 May 2015
Saturday, 2 May 2015
http://www.crispeditor.co.uk - now live
The domain transfer and contents transfer is complete - the links on the
website can now be used to download copies of CRiSP, DTrace and other tools.
I will need to tidy up some of the very old contents.
Please mail me at crispeditor at gmail.com if you see any issues.
Post created by CRiSP v12.0.6a-b6833
website can now be used to download copies of CRiSP, DTrace and other tools.
I will need to tidy up some of the very old contents.
Please mail me at crispeditor at gmail.com if you see any issues.
Post created by CRiSP v12.0.6a-b6833
Thursday, 30 April 2015
http://www.crispeditor.co.uk
The new replacement and home for the very old Demon website, where
you can download copies of CRiSP is nearly ready. You can visit the website
at
http://www.crispeditor.co.uk
and you will find content and download links, but the links will be a bit
stale as I copy things around. Hope to have this at parity in the next day
or so.
You may not be able to actually download anything, but thats high
on the list to fix.
Post created by CRiSP v12.0.5a-b6832
you can download copies of CRiSP is nearly ready. You can visit the website
at
http://www.crispeditor.co.uk
and you will find content and download links, but the links will be a bit
stale as I copy things around. Hope to have this at parity in the next day
or so.
You may not be able to actually download anything, but thats high
on the list to fix.
Post created by CRiSP v12.0.5a-b6832
Sunday, 26 April 2015
Goodbye Demon - shame the service is so bad
I joined Demon Internet back in 1992 - the first service provider
in the UK, and home for CRiSP (www.crisp.demon.co.uk) for the last 23y.
Despite various ownership changes of the company, it seems that the
FTP service is no longer functioning and I will finally retire my
Demon account this year.
For those of you looking to find CRiSP, you will find that eventually
that website will vanish, and I will replace with another site - once
I have decided on the best options.
My gmail accounts will continue to work, but my demon email address will
stop working at some point.
This is just a heads up.
I hope I am wrong and the FTP service recovers, but it seems like Demon
are transferring the hosting services to another provider, and nobody at
Demon understands the product they own, so it appears.
Post created by CRiSP v12.0.5a-b6832
in the UK, and home for CRiSP (www.crisp.demon.co.uk) for the last 23y.
Despite various ownership changes of the company, it seems that the
FTP service is no longer functioning and I will finally retire my
Demon account this year.
For those of you looking to find CRiSP, you will find that eventually
that website will vanish, and I will replace with another site - once
I have decided on the best options.
My gmail accounts will continue to work, but my demon email address will
stop working at some point.
This is just a heads up.
I hope I am wrong and the FTP service recovers, but it seems like Demon
are transferring the hosting services to another provider, and nobody at
Demon understands the product they own, so it appears.
Post created by CRiSP v12.0.5a-b6832
Sunday, 1 March 2015
another dtrace delay
Everything was looking promising to release a new dtrace sometime last
week. It was working on the 3.16 kernel, 3.8, 3.4 and then onto RH5.6 (2.6.18).
I ran into a lot of issues on 2.6.18 - not surprising, given the code
mutations. Much of the last 2 weeks was on the execve() system call.
It would panic the kernel. Despite a lot of experiments and reading
of the assembler and kernel code, I kept doing silly things. It
really doesnt help that the 2.6.18 kernel will hard panic on a stray
GPF - made it very difficult to figure out what was going on.
Eventually I got every line of assembler and issues with registers in C
code to work.
Along the way I had an issue with the "old_rsp" symbol. This is not exposed
in /proc/kallsyms, and not even in the /boot/System.map code. I had
to write a tool to extract this from inside the kernel. But this ran into
complications because /proc/kcore is broken on the RH/Centos kernels. I
had to create a new device driver, which has to be loaded into the kernel
prior to the build of dtrace ("/proc/dtrace_kmem"). Its a very simple
driver only designed to handle the scenario of building dtrace.
Having got this work, then the next roadblock was the rt_sigreturn() syscall
which paniced the kernel. Careful investigation showed a missing line
of assembler (for the 2.6.18 kernel). Now that works.
Now everything is looking good on RH5/Centos5 but before going on the
trawl of later kernels and proving I didnt break anything, I have an
issue with x_call.c. Either I use the native smp_call_function() interface -
which works great, until we panic the kernel, or I use my implementation,
which doesnt seem to be broadcasting to the cpus - this means
certain probes get "lost".
So, hopefully this week or next weekend - depending on the xcall issues.
Post created by CRiSP v12.0.3a-b6808
week. It was working on the 3.16 kernel, 3.8, 3.4 and then onto RH5.6 (2.6.18).
I ran into a lot of issues on 2.6.18 - not surprising, given the code
mutations. Much of the last 2 weeks was on the execve() system call.
It would panic the kernel. Despite a lot of experiments and reading
of the assembler and kernel code, I kept doing silly things. It
really doesnt help that the 2.6.18 kernel will hard panic on a stray
GPF - made it very difficult to figure out what was going on.
Eventually I got every line of assembler and issues with registers in C
code to work.
Along the way I had an issue with the "old_rsp" symbol. This is not exposed
in /proc/kallsyms, and not even in the /boot/System.map code. I had
to write a tool to extract this from inside the kernel. But this ran into
complications because /proc/kcore is broken on the RH/Centos kernels. I
had to create a new device driver, which has to be loaded into the kernel
prior to the build of dtrace ("/proc/dtrace_kmem"). Its a very simple
driver only designed to handle the scenario of building dtrace.
Having got this work, then the next roadblock was the rt_sigreturn() syscall
which paniced the kernel. Careful investigation showed a missing line
of assembler (for the 2.6.18 kernel). Now that works.
Now everything is looking good on RH5/Centos5 but before going on the
trawl of later kernels and proving I didnt break anything, I have an
issue with x_call.c. Either I use the native smp_call_function() interface -
which works great, until we panic the kernel, or I use my implementation,
which doesnt seem to be broadcasting to the cpus - this means
certain probes get "lost".
So, hopefully this week or next weekend - depending on the xcall issues.
Post created by CRiSP v12.0.3a-b6808
Monday, 23 February 2015
dtrace update ...
Still delaying the dtrace release. Having gotten 3.16 kernels to work,
I started working backwards on random 3.x kernels, to validate it
still worked there. I fixed a number of issues there, and then headed
into RedHat 5.6 / Centos 5.6 land (2.6.18+ kernel).
I spent some time trying to get execve() syscall tracing to work - and
am still working on that.
Along my journey, I noticed a few things. Firstly dtrace4linux is too
complicated - trying to support 32+64b kernels, along the entire
path back to 2.6.18 or earlier, is painful. I cannot easily automate
regression testing (not without a lot more hard-disk space, and not
worthwhile whilst I am aware of obvious bugs to fix). I could simplify
testing by picking any release, and just rebooting with different kernels -
rather than full ISO images of RedHat/Centos/Ubuntu/Arch and so on.
I also noticed that the mechanism dtrace4linux uses to find addresses in
the kernel is slightly overkill. It hooks into the kernel to find symbols
which cannot be resolved at link time. The mechanism I have is pretty
interesting - relying on a Perl script to locate the things it needs.
I found a case where one of the items I need is not visible at all
in user space - its solely in the kernel - part of the syscall interrupt
code (the per-cpu area). Despite what latest kernels do, some older
kernels *dont*. And catering for them is important. In one case
I have had to go searching the interrupt code to find this value.
I ended up writing a C program to run in user space, prior to the build,
and really, it would have been better to generalise this so that everything
we need is simply defined in a table compiled in to the code, rather than
the /dev/fbt code to read from the input stream. This would ensure
that a build compiles and works. Today, sometimes I debug issues with
old kernels because a required symbol is missing and we end up
dereferencing a null pointer (not a nice thing to do in the kernel).
One problem I had with the above, was that gdb on the older distro releases
cannot be used to read kernel memory due to a bug in the kernel
precluding reading from /proc/kcore. Fortunately, I include a script
in the release which emits a vmlinux.o, complete with symbol table,
from the distribution vmlinuz file.
I havent reverified the ARM port of dtrace, but thats something for a
different rainy or snowy day.
Post created by CRiSP v12.0.3a-b6808
I started working backwards on random 3.x kernels, to validate it
still worked there. I fixed a number of issues there, and then headed
into RedHat 5.6 / Centos 5.6 land (2.6.18+ kernel).
I spent some time trying to get execve() syscall tracing to work - and
am still working on that.
Along my journey, I noticed a few things. Firstly dtrace4linux is too
complicated - trying to support 32+64b kernels, along the entire
path back to 2.6.18 or earlier, is painful. I cannot easily automate
regression testing (not without a lot more hard-disk space, and not
worthwhile whilst I am aware of obvious bugs to fix). I could simplify
testing by picking any release, and just rebooting with different kernels -
rather than full ISO images of RedHat/Centos/Ubuntu/Arch and so on.
I also noticed that the mechanism dtrace4linux uses to find addresses in
the kernel is slightly overkill. It hooks into the kernel to find symbols
which cannot be resolved at link time. The mechanism I have is pretty
interesting - relying on a Perl script to locate the things it needs.
I found a case where one of the items I need is not visible at all
in user space - its solely in the kernel - part of the syscall interrupt
code (the per-cpu area). Despite what latest kernels do, some older
kernels *dont*. And catering for them is important. In one case
I have had to go searching the interrupt code to find this value.
I ended up writing a C program to run in user space, prior to the build,
and really, it would have been better to generalise this so that everything
we need is simply defined in a table compiled in to the code, rather than
the /dev/fbt code to read from the input stream. This would ensure
that a build compiles and works. Today, sometimes I debug issues with
old kernels because a required symbol is missing and we end up
dereferencing a null pointer (not a nice thing to do in the kernel).
One problem I had with the above, was that gdb on the older distro releases
cannot be used to read kernel memory due to a bug in the kernel
precluding reading from /proc/kcore. Fortunately, I include a script
in the release which emits a vmlinux.o, complete with symbol table,
from the distribution vmlinuz file.
I havent reverified the ARM port of dtrace, but thats something for a
different rainy or snowy day.
Post created by CRiSP v12.0.3a-b6808
Friday, 20 February 2015
new dtrace .. small update
The next release of dtrace is hopefully this weekend. Having
resolved the issues I had previously, have been doing more
testing - so far only really on the 3.16 kernel, and found that
some of the syscalls were behaving badly due to reimplementation
in the kernel. Hopefully when I have fixed the last two or three,
then I can finish my merges and push out the latest release. I will
do a cursory check on some of the older kernels - it is likely I
have made a mistake somewhere and broken older kernels, but will
be easier to fix having made some internal changes.
Note that no new functionality is in here - the issues with
libdwarf remain - I may try again to solve that issue, and
"dtrace -p" is still a long way off from being functional.
Given that 3.20 is now the current kernel, I may need to see
if that works and pray that 3.17-3.20 didnt affect how dtrace works,
or, if it does, the work to make it compile should be much less
than the issues that 3.16 raised.
Post created by CRiSP v12.0.3a-b6801
resolved the issues I had previously, have been doing more
testing - so far only really on the 3.16 kernel, and found that
some of the syscalls were behaving badly due to reimplementation
in the kernel. Hopefully when I have fixed the last two or three,
then I can finish my merges and push out the latest release. I will
do a cursory check on some of the older kernels - it is likely I
have made a mistake somewhere and broken older kernels, but will
be easier to fix having made some internal changes.
Note that no new functionality is in here - the issues with
libdwarf remain - I may try again to solve that issue, and
"dtrace -p" is still a long way off from being functional.
Given that 3.20 is now the current kernel, I may need to see
if that works and pray that 3.17-3.20 didnt affect how dtrace works,
or, if it does, the work to make it compile should be much less
than the issues that 3.16 raised.
Post created by CRiSP v12.0.3a-b6801
Subscribe to:
Posts (Atom)