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