[ros-dev] Bye bye

Brian briandabrain at gmail.com
Thu Jan 19 21:00:09 CET 2006

Beautiful. I am happy. Alex, from what i have seen, i agree with the "black
sheep" statement. I haven't seen a better msg on the list since this. Now
that makes me feel that my work is done.
I will continue to watch the project, but i feel to useless not working on
it, and realy am not comfortable with the code (I am a *n*x clone kernel
programer myself ). I plan to write an OS of my own soon ( "AHGG, Not
another enama!!!" ) and may look for help. I will keep a link on my site up
to reactos.org, but for now, until a day i am needed again...

friend of reactos
my site: <psudobuddha's site> <http://www.metawire.org/%7Epsudobuddha>

On 1/19/06, Alex Ionescu <ionucu at videotron.ca> wrote:
> Hi,
> I'm going to answer generically, not point-by-point, since I don't have
> much time, but I hope I can cover everything:
> 1) Those magic sizes were calculated in my head and I didn't have time
> to make them into constants as I did many of them.
> 0x29C is the pre-defined value of NPX_FRAME_LENGTH + KTRAP_FRAME_LENGTH.
> 0x48 is the differerence in the KTRAP_FRAME between the registers that
> we will skip. I could've done (KTRAP_FRAME_XXX - KTRAP_FRAME_YYY).
> 2) This is not a matter of driver compatibility. The fast system call
> stub is a mostly hardware-defined entrypoint, handled by low-level
> software logic. In implementing it, there are only 3 available sources
> of information: Whatever minimal info the Intel manual gives, the Linux
> sources, the Windows kernel binary. It is almost simply impossible to
> "guess" how the stub should work. Filip tried to make it work more then
> a year ago, and even he gave up (the AMD version), beacuse it is simply
> too hard and confusing unless you have some available code to look at.
> As such, my first and foremost source was the Linux source code. It
> helped me understand how to setup the LSTAR MSR register, as well as the
> other register values. Then, through several mailing list posts, I was
> able to understand some bugs in the way ReactOS had its segments set up,
> which caused problems in the code. Then, to understand the way Windows
> chose between INT2E and SYSENTER, I found a document online written by a
> person called Elicz, which described the stub and what it should do,
> much in the same way people argued "clean-room reverse engineering" is
> done. With this information, I was able to write more then 85% of the
> stub. My next, and final remaining possible step, was to use IDA to look
> at the Windows code. I used it as a learning tool, not as a copying
> tool. It is hard to argue that what I did was "Reverse-engineering",
> which, to my knowledge, implies taking something apart to re-create it,
> since this usually implies converting the assembly code to functional C
> code or otherwise. But I don't view as looking at assembly in order to
> understand a low-level hardware interface as "reverse engineering". And
> yes, as described above, it -was- my last choice. Additionally, the
> parts which were supposedly "copied" are NOT part of the functional part
> of the code. They are debug helpers, offering nothing else but
> assertions in case of problems.
> 3) I find the idea of removing code that "Violates policy" ludicrous. No
> one has the right to dermine if some piece of code violates policy or
> not, especially if the author writing it denies it. Only a judge or
> lawyer should be able to make that decision. Additionally, in this
> specific case, what could be done? The code is in SVN and even if
> rewritten it will 1) look the same, excpt "edx" would become "esi" and
> vice-versa 2) a judge would still argue that "hey, you had the previous
> code in SVN for over a year, you've all been tainted and could've just
> as easily looked at it". Furthermore, such attitude might start
> devolving into a dangerous witchhunt. Don't like someone's code? Report
> them and have it removed! This communist-era and fascist-era behaviour
> deeply scares me and reminds me of a country and regime which I fled. I
> do not want to see it happen, because it would slowly kill and rip apart
> this project.
> These monthly Alex-bashings are starting to tire me very much and maybe
> it's time I took an offensive position instead of a defensive one. I do
> not want to start naming names, but many of our developers have already
> violated our policy in different ways. If you actively start enforcing
> it, then it will be my duty as an active developer to enforce it as
> well, meaning that hiding any information I have concerning other
> developers' violations would be considered as complicity, so I would be
> legally bound to report them. In other words, this would mean that the
> project would lose half of its developers.
> I am sick of being treated as the black sheep and the "example". This
> stops here. I have always been put in the spotlight for almost any
> action I took, and I've always taken steps to repair it. But these
> public trials of guilt have passed a limit. Either start questionning
> everyone and treating every developer the same, or stop using me as a
> tool.
> Best regards,
> Alex Ionescu
> Steven Edwards wrote:
> >On 1/19/06, WaxDragon <waxdragon at gmail.com> wrote:
> >
> >
> >>You are not a judge with years of experience in law. Whether or not
> >>you have any kernel internal knowledge is also irrelevant to this
> >>thought experiment.
> >>
> >>
> >
> >No but I am someone trying to be objective that has spent a good part
> >of the past few years reviewing case history for reverse engineering
> >cases. Its more than we are going tot get from some judges.
> >
> >
> >
> >>>Why did you have to do this? Is it not possible to write a driver that
> >>>abuses fastcall to make a mostly working implementation without having
> >>>to 1. look at and 2. copy the existing object code of Windows?
> >>>
> >>>
> >>Alex clearly stated that there is only one way to perform that stack
> >>check, let's quote him properly:
> >>
> >>"Note however, that there is only one way to check the stack: cmp ebp,
> >>esp. Unless you want to consider cmp esp, ebp as an alternate method."
> >>
> >>As Casper said, it is legal to use that information, but not legal to
> >>*copy/paste* it into ReactOS.  Alex clearly comprehends what that bit
> >>of assembly does.
> >>
> >>
> >
> >Once again he may have stated this but he also states he disassembled
> >Windows. The issue is the methods used to gather the information.
> >Reverse engineering is legal if there is no other method to gather the
> >information which is why I clearly asked "Was there no other way to
> >get this information" or let me put it another way....
> >
> >Alex: did you even bother doing some sort of clean room examination of
> >Windows behavior based on third party drivers or some sort of testing
> >or was IDA your first step? Checked Microsoft driver assertions and
> >debug symbols don't count.
> >
> >
> >
> >>>OK so someone else sneaked something in that violates the rules and it
> >>>was not caught. Lets just check your argument for a moment and say you
> >>>could be wrong about your development methods. Being ..."clearly
> >>>commented, organized and structured..." does not amount to a hill of
> >>>beans if I am violating the law and or project rules. I can make bank
> >>>robbing plans that are "...clearly commented, organized and
> >>>structured..." I don't think that will gain me much ground in court.
> >>>
> >>>
> >>This analogy is invalid.  The legality of this issue stems directly
> >>from whether or not he wrote the code.  Robbing a bank is _always_
> >>illegal, writing code is only illegal if you copy/paste it from a
> >>legitimate author, or implement a patented method.
> >>
> >>
> >
> >No its perfectly a valid question. In law there is this concept called
> >Mens Rea which means intent. Was his intent to create a independent
> >unique work he himself created and he just needed the information for
> >compatibly reasons or did he intend to just make it work without
> >caring of the consequences to everyone else. Hence the question above.
> >Was IDA the first step or the last?
> >
> >
> >
> >>Alex's structured and commented code demonstrates comprehension.  In
> >>this case, where the code's function is clear, and constrained by
> >>implementation details, the code will be similar by anyone who
> >>implements it.  Alex's comments and code structure shows that he
> >>understands what is going on in the assembly, and most likely shows
> >>that he wrote the code, as opposed to just copy/pasting existing code.
> >>
> >>
> >
> >Just because he understands the code now is irrelevant. Its the method
> >of which that understanding came. Because our work is going to be
> >similar to windows the arguments about a derived work hangs upon the
> >notion that we are independently creating our own implementation
> >rather than looking at the original. We can read documentation about
> >the original all day long, we can examine applications and drivers
> >that use the original all day long but when we start to crack open the
> >book of the original implementation we run the legal risk of being
> >declared a derived work.
> >
> >
> >
> >>It only looks suspicious since you are not a kernel developer.  Again,
> >>not something a judge would concern himself with.  Now the
> >>prosecutor.....
> >>
> >>
> >>
> >>>    /* Skip the other registers */
> >>>    sub esp, 0x48
> >>>
> >>>
> >>>
> >
> ><snip>
> >
> >
> >
> >>>ie.  why 0x29C, why 0x48?
> >>>
> >>>
> >>Since he is making room on the stack for another frame, this is a
> >>predefined size.
> >>
> >>
> >
> >Hmm ok. So another size won't work? Where is it predefined? I ask not
> >to accuse but to try to understand to be fair to all parties involved.
> >But according to Hartmut this is a clear case of copy and paste. This
> >is why we cannot allow this to continue. If dirty-room reverse
> >engineering was the last resort then it would be a original
> >implementation
> >
> >
> >
> >>further.   Now, I do agree he could have used the safer "clean-room"
> >>method, but I'm not convinced that it would have yielded a
> >>significantly different implementation, and we might still be in the
> >>same position.
> >>
> >>
> >
> >You admit that his implementation was not based on "clean-room". My
> >question once again was why did it have to be dirty room? If there is
> >no other option for making a compatible implementation then this
> >discussion holds no water but if by your own words he could have used
> >a safer method then there is a problem.
> >
> >So we are back to the first question. What development methods were
> >used. IDA first or last?
> >
> >--
> >Steven Edwards - ReactOS and Wine developer
> >
> >"There is one thing stronger than all the armies in the world, and
> >that is an idea whose time has come." - Victor Hugo
> >
> >_______________________________________________
> >Ros-dev mailing list
> >Ros-dev at reactos.org
> >http://www.reactos.org/mailman/listinfo/ros-dev
> >
> >
> >
> _______________________________________________
> Ros-dev mailing list
> Ros-dev at reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.reactos.org/pipermail/ros-dev/attachments/20060119/dc8b880a/attachment-0001.html

More information about the Ros-dev mailing list