[ros-dev] Bye bye

[Alex Ionescu]

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
>
>  
>