/-//
A thorough search of the scientific literature reveals that the paper isn't a peer-reviewed article. It's just a PDF that looks like a research paper stored on Github.
/--/
Yep. That's pretty much it.
When I was working with wireless networks, we've got so many academic security researches telling us that the network does not work in the presence of strong interference. Well, no shit. What do you want us to do about it? Change how physics works?
It's also hilarious.
Yeah I work in fintech. We have background checks, multiple layers of review, static analysis, vulnerability analysis (DAST/SAST), least privilege implementations everywhere.So can you 100% say that you never found a bug in the released code base?
Yeah I work in fintech. We have background checks, multiple layers of review, static analysis, vulnerability analysis (DAST/SAST), least privilege implementations everywhere./---/
I think people that suggest that one project or the other needs to do more review - go and do that review. It is easy to tell what others should and should not do.
To be fair that clause is in our employment contracts under "malicious intent".Isn't most of an employment contract there with malicious intent?
There’s no contributor contract as such so there’s no legal agreement in place. Usually your only agreement would be to surrender copyright to the project in some way. Thus you could roll up and steaming turd and drop the patch and if they accept it then it’s the maintainer’s funeral, which in this case it should be.
There is a lot of distraction here by the community from the fact that there is a massive vulnerability in the process. Imagine how many times that has been exploited potentially. There are a hell of a lot of contributors.
Both sides of this process are to blame.
The whole OpenBSD IPSEC and DARPA thing is another example of the plausible scenarios.
A quick glance at responses to Greg's mass-revert shows that most stuff from that university was legit fixes.The bad patches were also masqueraded as legit fixes. They just had unintended side effects.
There’s no contributor contract as such so there’s no legal agreement in place. Usually your only agreement would be to surrender copyright to the project in some way. Thus you could roll up and steaming turd and drop the patch and if they accept it then it’s the maintainer’s funeral, which in this case it should be.
There is a lot of distraction here by the community from the fact that there is a massive vulnerability in the process. Imagine how many times that has been exploited potentially. There are a hell of a lot of contributors.
Both sides of this process are to blame.
The whole OpenBSD IPSEC and DARPA thing is another example of the plausible scenarios.
Do you think that there will be some substantial process changes as a result of this or a lot of saber rattling until the smoke clears and then business as usual...or something in between?
Do you think that there will be some substantial process changes as a result of this or a lot of saber rattling until the smoke clears and then business as usual...or something in between?I don't think anything substantial will change. The process as it is works fine for what it is. There is no way to improve it unless you are willing to invest more resources. And those resources should come from the parties benefiting from the improvements. If the companies using Linux in their products think that Linux community is not doing enough - they should invest more money, or even hire third-party reviewers.
Things clearly don't work well if anyone signed off on their shit patches. And those who did have just been caught with their pants down. It's the whole point of review to catch errors, intentional or not.Code reviews are never 100% effective. Otherwise we would not have bugs in the software, since majority of big companies have code reviews.
In the FPGA universe, it is common to build test benches to verify component behavior.And the review in this case was focused on the component. The issues are introduced in the integration part.
There may be a lot of poor judgement here, especially by the author, and I would not want to be in that fellow's shoes or his supervisor....but I don't see that something very severe will be done...and I may find out otherwise as it is story that is unfolding.
There may be a lot of poor judgement here, especially by the author, and I would not want to be in that fellow's shoes or his supervisor....but I don't see that something very severe will be done...and I may find out otherwise as it is story that is unfolding.
Don't get me wrong. The ban won't be forever. I expect that trust will resume once a change of leadership has happened. It's up to them.
So, what, if anything, do you do to this fellow and his supervisor if you are the University?Get them out. Do so with the review board too. They should know better that unethical behaviour does not just starts at human experimentation. And if they really think it does - they need to go just for that reason.
Let's say the proceedings folks cancel it - same situation...if it was accepted, what has changed?The understanding that this childish behaviour should not be encouraged. Because even if kernel people are no longer talking to you, presenting that at a conference may be a decent "get" anyway.
If they now decide it is unethical, what changed?This "research" is clear waste of time and money. To anyone with half a brain, it should be obvious that you can get the bad code into the kernel. This happens all the time unintentionally. Obviously doing so intentionally is even easier. How is this not obvious? The topic of the paper is just dumb, it demonstrates absolutely nothing, as there is no way to address the supposed issue.
Somebody want to start litigation of some kind - ok, now show damages.I would not. Why waste time? Not dealing with people that intentionally waste my time is the best I can do.
I don't know who gets really hurt there...one way of telling is if the Univ says...we have done x y z to prevent this from happening ....and then the ban gets lifted.I'm pretty sure this is resolvable. The University just need to talk in private, and not issue more stupid suggestions to update the code of conduct. Get someone who is not too woke to do that.
I don't know who gets really hurt there...one way of telling is if the Univ says...we have done x y z to prevent this from happening ....and then the ban gets lifted.I'm pretty sure this is resolvable. The University just need to talk in private, and not issue more stupid suggestions to update the code of conduct. Get someone who is not too woke to do that.
I think the author was the one who made the suggestion to update the code of conduct (maybe the Univ did also). But, what are they going to say in private? I don't think they want the attention period, but if they really screwed up somewhere along the line - and I do not know that they did, they will have to change something I would think.Just promise to change the review process and not submit malicious code would be enough. This just needs to come from high enough level at the Uni.
So, what, if anything, do you do to this fellow and his supervisor if you are the University?Get them out. Do so with the review board too. They should know better that unethical behaviour does not just starts at human experimentation. And if they really think it does - they need to go just for that reason.
I think it is not too late for the University to resolve the issue in general, just talk to the kernel people in private.Let's say the proceedings folks cancel it - same situation...if it was accepted, what has changed?The understanding that this childish behaviour should not be encouraged. Because even if kernel people are no longer talking to you, presenting that at a conference may be a decent "get" anyway.If they now decide it is unethical, what changed?This "research" is clear waste of time and money. To anyone with half a brain, it should be obvious that you can get the bad code into the kernel. This happens all the time unintentionally. Obviously doing so intentionally is even easier. How is this not obvious? The topic of the paper is just dumb, it demonstrates absolutely nothing, as there is no way to address the supposed issue.Somebody want to start litigation of some kind - ok, now show damages.I would not. Why waste time? Not dealing with people that intentionally waste my time is the best I can do.
you can start withdrawing papers that you already cleared (assuming they did) because it was childish.But this already happens all the time. Most of the time it happens because results were not interpreted correctly, or experiment was not clean.
would not, necessarily,"litigate" well.It is great that kernel developers are just a private people that can chose to not deal with a certain organization "just because". They don't need to litigate.
I think the author was the one who made the suggestion to update the code of conduct (maybe the Univ did also). But, what are they going to say in private? I don't think they want the attention period, but if they really screwed up somewhere along the line - and I do not know that they did, they will have to change something I would think.Just promise to change the review process and not submit malicious code would be enough. This just needs to come from high enough level at the Uni.
The public reaction of the kernel developers is fully justified. If they let it slide, there will be a competition among haxors who can submit the biggest hole into the kernel unnoticed. This behavior needs to be nipped in the bud. People need to understand that there is not much to be gained and quite a bit to be lost here.
Zero tolerance policies may appear cruel at times, but they are often the only way to prevent unwanted behaviour.
you can start withdrawing papers that you already cleared (assuming they did) because it was childish.But this already happens all the time. Most of the time it happens because results were not interpreted correctly, or experiment was not clean.
The article can absolutely be pulled by the University. And from the IEEE conference. In fact, if they did not do this already, it kind of shows that they want to burn the bridges entirely.would not, necessarily,"litigate" well.It is great that kernel developers are just a private people that can chose to not deal with a certain organization "just because". They don't need to litigate.
But what if the supervisor does not feel that way?That is fine. You start by going to Linus or anyone on top in charge and disclose the proposal. Or even ask more than just the supervisor. Peer review your proposal. But in that specific place IRB was supposed to be that review, which has also failed. And that is something Uni should address.
I had a dissertation proposal meeting and it lasted for hours...it was not just my supervisor, it was 4-5 others including someone not at the Univ....that was the SOP. So, at that proposal meeting, you hashed out any problems with your plan...you had to show all sorts of stuff...feasibility, statistical expertise and an analysis plan, preliminary or supporting data - the whole ball game, and you, of course, you had to have the blessing of your supervisor.Exactly. And this means that this system failed. And that is what you go as a Uni - admit that you pushed the edge too far and promise to do a better job reviewing this stuff.
So, my point, assuming I have one, is that I don't want to see a lot of new restrictions put in place that are not need and will have other consequences and will suck up resources.But because of malicious "research" like this, kernel developers now have to suck up more resources on their side to prevent others from trying the same stunt.
First, I want to know precisely what was done wrong here.In short - poor experiment setup passed the review process.
Hang on a minute. Papers are not routinely withdrawn because "results were not interpreted correctly, or experiment was not clean." - a paper like that, should not have been cleared, submitted, reviewed and accepted.
I would add, when people or entities engage in punitive action without giving a reason, it invites trouble.The reason - you wasted their time. At first having to deal with the fallout of the bogus article, and then having to remove all the previously submitted code as potentially vulnerable.
Well, I appreciate the dialog. But, what you are saying, as I understand it, is that the Univ has to own up to some mistakes and take solid corrective measures....well maybe they will, but we'll see. :)
You guys are funny :P
The offending patches have not been submitted form the university's domain, but from throwaway gmail accounts. It's all described in the paper, but of course no one who has an opinion about the paper has actually read it, as usual.
You guys are funny :P
The offending patches have not been submitted form the university's domain, but from throwaway gmail accounts. It's all described in the paper, but of course no one who has an opinion about the paper has actually read it, as usual.
The patches were never meant to damage anything, they say they informed the maintainers about the experiment as soon as the malicious patches received approval on the mailing list and suggested correct fixes.
Unfortunately we won't get to see the details of those exchanges without some extensive digging, because they have been redacted from the paper to protect the guilty maintainers. That was indeed done to calm down the ethics review guys.
OTOH, the paper is perhaps not very useful and the solutions they propose are either "no shit Sherlock" or plain dumb. But I would say it may still be worth it for the publicity stunt alone >:D Perhaps a lesson has been learned, do such things anonymously and don't brag about them under your real name later.
All this is academic. Excuse the pun.
Are you aware of any real adversaries who have an ethical experimentation framework? Nope!
This has exposed a huge vulnerability in the process which was an extremely valuable activity. And people are complaining at the university here. Where is the vitriol for the kernel team? Our entire society is built on their work and they fucked up monumentally.
You guys are funny :P
The offending patches have not been submitted form the university's domain, but from throwaway gmail accounts. It's all described in the paper, but of course no one who has an opinion about the paper has actually read it, as usual.
The patches were never meant to damage anything, they say they informed the maintainers about the experiment as soon as the malicious patches received approval on the mailing list and suggested correct fixes.
Unfortunately we won't get to see the details of those exchanges without some extensive digging, because they have been redacted from the paper to protect the guilty maintainers. That was indeed done to calm down the ethics review guys.
They passed ethics review by insisting that no personal information will be collected or published and they only test "the development process" as such.
Finally, all the patches nuked by Greg were patches from random students looking for issues or playing with static analyzers. Most appear to have been accepted, a few have been found suboptimal, a few were rejected because they don't work.
I'm disappointed that Greg hasn't followed up with the obvious and requested a review of patches submitted from other students around world (and from random strangers with gmail accounts). Like they should be doing in the first place :P
OTOH, the paper is perhaps not very useful and the solutions they propose are either "no shit Sherlock" or plain dumb. But I would say it may still be worth it for the publicity stunt alone >:D Perhaps a lesson has been learned, do such things anonymously and don't brag about them under your real name later.
From: Kangjie Lu <kjlu@umn.edu>
To: open list <linux-kernel@vger.kernel.org>
Cc: Qiushi Wu <wu000273@umn.edu>, Aditya Pakki <pakki001@umn.edu>
Subject: An open letter to the Linux community
Date: Sat, 24 Apr 2021 17:30:50 -0500
An apology, posted yesterday....https://lore.kernel.org/lkml/CAK8KejpUVLxmqp026JY7x5GzHU2YJLPU8SzTZUNXU2OXC70ZQQ@mail.gmail.com/
This has exposed a huge vulnerability in the process which was an extremely valuable activity.It exposed absolutely nothing. We do this experiment every single day. Commits with issues that have to be reverted appear in the kernel all the time. So it it obvious you can get one though intentionally.
An apology, posted yesterday....As I said, in the spirit of that apology, they should not benefit from the article. So remove it from the IEEE conference.
From: Kangjie Lu <kjlu@umn.edu>
To: open list <linux-kernel@vger.kernel.org>
Cc: Qiushi Wu <wu000273@umn.edu>, Aditya Pakki <pakki001@umn.edu>
Subject: An open letter to the Linux community
Date: Sat, 24 Apr 2021 17:30:50 -0500
An apology, posted yesterday....https://lore.kernel.org/lkml/CAK8KejpUVLxmqp026JY7x5GzHU2YJLPU8SzTZUNXU2OXC70ZQQ@mail.gmail.com/
@Dr. G, if you were to post that you had been mugged yesterday, you would get one or two comments defending the mugger...
From: Kangjie Lu <kjlu@umn.edu>
To: open list <linux-kernel@vger.kernel.org>
Cc: Qiushi Wu <wu000273@umn.edu>, Aditya Pakki <pakki001@umn.edu>
Subject: An open letter to the Linux community
Date: Sat, 24 Apr 2021 17:30:50 -0500
An apology, posted yesterday....https://lore.kernel.org/lkml/CAK8KejpUVLxmqp026JY7x5GzHU2YJLPU8SzTZUNXU2OXC70ZQQ@mail.gmail.com/
@Dr. G, if you were to post that you had been mugged yesterday, you would get one or two comments defending the mugger...
Nahh, if I posted that I got mugged, I would probably get a ton of "likes" ;)
More seriously, I admit that I am fascinated by the dynamics of these situations....I try to come up with the principles in play as they unfold.
We see the dynamics almost everyday in the media...someone screws up...they apologize...does it stick or do they get cancelled?
IMO, this fellow is throwing himself at the mercy of the court, so to speak. It is one step in the process....does he get cancelled or does this blow over and he can continue, hopefully, smarter and more humble?
In my view, Community Opinion, much like Reality itself, can be a harsh mistress and one should not try to f**k with either.
IF <AnotherPerson> DID <something I would not be ashamed of doing myself> THENThis is not a bad algorithm. After all, all societal norms are what majority of people in the society see as acceptable. For better or worse.
Defend;
ELSE
Condemn;
IF <AnotherPerson> DID <something I would not be ashamed of doing myself> THENThis is not a bad algorithm. After all, all societal norms are what majority of people in the society see as acceptable. For better or worse.
Defend;
ELSE
Condemn;
...
IF <AnotherPerson> DID <something I would not be ashamed of doing myself> THENThis is not a bad algorithm. After all, all societal norms are what majority of people in the society see as acceptable. For better or worse.
Defend;
ELSE
Condemn;
And percentage of defending of condemning show how much of a grey area the behaviour is.
The same person can be ashamed of something as a teenager that they then routinely do later in life, and vice versa.Sure, but you can make finer subdivisions of the society and apply the same algorithm.
It is also possible to be "incorrectly ashamed" of something that is actually natural.For sure, and that would represent societal flaw. Those happen too in real life and societies need to work on fixing those.
Basically, the feeling of being ashamed of something is not really a sound basis for condemning others?May be not, but it is one of the factors.
"Finally, all the patches nuked by Greg were patches from random students looking for issues or playing with static analyzers. Most appear to have been accepted, a few have been found suboptimal, a few were rejected because they don't work."Yes, you are very boring, trying to understand stuff instead of getting triggered :D
So, I just read this: https://lore.kernel.org/linux-nfs/YH%2F8jcoC1ffuksrf@kroah.com/
...
It is difficult to unravel all the facts and I have repeatedly stated that I want to understand clearly what was done and why is it wrong...so even as I continue to get details wrong, I am not that funny.
On Wed, Apr 21, 2021 at 02:56:27AM -0500, Aditya Pakki wrote:
> Greg,
>
> I respectfully ask you to cease and desist from making wild accusations
> that are bordering on slander.
>
> These patches were sent as part of a new static analyzer that I wrote and
> it's sensitivity is obviously not great. I sent patches on the hopes to get
> feedback. We are not experts in the linux kernel and repeatedly making
> these statements is disgusting to hear.
>
> Obviously, it is a wrong step but your preconceived biases are so strong
> that you make allegations without merit nor give us any benefit of doubt.
>
> I will not be sending any more patches due to the attitude that is not only
> unwelcome but also intimidating to newbies and non experts.
https://lore.kernel.org/linux-nfs/20210423214850.GI10457@fieldses.org/
Just as expected :-DD :popcorn:
The guy wrote some tools looking for bugs in Linux and submitted fixes for what he found, wrote a paper about it, all under his real name.https://lore.kernel.org/linux-nfs/20210423214850.GI10457@fieldses.org/
Just as expected :-DD :popcorn:
Can you explain what is amusing for those of us playing along at home?
Loudest ego wins in 2021 and that appears to be the kernel team.
What I am learning from this is that we're in the hands of asshats.
But the spirit of CoC is not to be dicks to each other, and knowingly submitting malicious code pretty much falls into being a dick.That's one student who did it.
And what can we say about all the developersNothing. When acting on behalf of an organization, the whole organization is suspect. They did not accuse anyone, they said that they don't know what to think and how many of those patches are intentionally buggy. Bug given the overall low value of the patches, it is easier to remove all of them.
Reminder: there is no obligation to be competent when you submit stuff. It's on the team to handle everything you throw at them.Yes, but there is moral obligation to submit patches in good faith.
They did not accuse anyone, they said that they don't know what to think and how many of those patches are intentionally buggy.
I will now have to ban all future contributions from
your University and rip out your previous contributions, as they were
obviously submitted in bad-faith with the intent to cause problems.
Bug given the overall low value of the patches, it is easier to remove all of them.Based on my quasi-random sampling of the mega-review thread, most reverted patches were found to be alright. Of course my random clicking on random message titles may have been biased by whatever factors and things may have changed since two days ago, ICBA to do a proper analysis.
Bug given the overall low value of the patches, it is easier to remove all of them.Based on my quasi-random sampling of the mega-review thread, most reverted patches were found to be alright. Of course my random clicking on random message titles may have been biased by whatever factors and things may have changed since two days ago, ICBA to do a proper analysis.
News
[03/03/2021] I will be on the program committee of IEEE S&P 2022.
[02/12/2021] Our work on detecting unsafe DMA accesses was accepted to USENIX Security'21. Unchecked and inconsistent DMA accesses are very common in drivers; we found about 300 such bugs in Linux drivers.
....
The whole point of my previous argument is that the kernel team's process is completely flawed and that's where the responsibility lies and they need to fess up to that rather than shitting on the researchers.Their model matches standard industry practices. You can do this with any other project, open, or closed.
The researchers did the equivalent of driving a tank through a hole in the fence at Area 51, donning chicken suits and dancing around making clucking noises. Everyone is complaining at them rather than wondering why there is a massive hole in the fence.This is criminal trespass, at least in the US. This is very much illegal whether there is a hole in the fence or a simple "NO TRESPASSING" sign and no fence at all.
Those guys are lucky they did not get into more trouble than this.
Letter requesting withdrawal (April 26, 2021):
https://www-users.cs.umn.edu/~kjlu/papers/withdrawal-letter.pdf (https://www-users.cs.umn.edu/~kjlu/papers/withdrawal-letter.pdf)
There's more info on his page, including a letter to the Linux foundation from the department head:
https://drive.google.com/file/d/1z3Nm2bfR4tH1nOGBpuOmLyoJVEiO9cUq/view (https://drive.google.com/file/d/1z3Nm2bfR4tH1nOGBpuOmLyoJVEiO9cUq/view)
Looks like the he has been removed from the program committee of IEEE S&P 2022:
https://www.ieee-security.org/TC/SP2022/cfpapers.html (https://www.ieee-security.org/TC/SP2022/cfpapers.html)
But this has not been updated on his home page:
https://www-users.cs.umn.edu/~kjlu/ (https://www-users.cs.umn.edu/~kjlu/)Code: [Select]News
[03/03/2021] I will be on the program committee of IEEE S&P 2022.
[02/12/2021] Our work on detecting unsafe DMA accesses was accepted to USENIX Security'21. Unchecked and inconsistent DMA accesses are very common in drivers; we found about 300 such bugs in Linux drivers.
....
I'd hire them in a snap. They'd be good for an adversarial security programme.
Their model matches standard industry practices. You can do this with any other project, open, or closed.You are an embedded developer, we get it. You guys are infamous for your level of security :P
I was under impression that OS kernels do belong to this group.That is up to kernel authors to decide how to run their project. If you think their code quality is not sufficient - don't use it.
For starters, you wouldn't even be able to submit patches like that to Windows.Do you really think that out of 1000's of programmers at Microsoft nobody left a juicy hole for later use? Are you sure that some of the huge holes that we are observing weekly are not introduced on purpose?
I think they understand that a threat exists and must have review in place, or things would be much worse like they used to be in the past. And Windows is a much more juicy target too.
And if you want to compare Windows vs Linux, don't forget to include all bugs in GNOME and systemd :P
Subject: [PATCH] SUNRPC: Add a check for gss_release_msg
Date: Tue, 6 Apr 2021 19:16:56 -0500
Message-ID: <20210407001658.2208535-1-pakki001@umn.edu> (raw)
In gss_pipe_destroy_msg(), in case of error in msg, gss_release_msg
deletes gss_msg. The patch adds a check to avoid a potential double
free.
Signed-off-by: Aditya Pakki <pakki001@umn.edu>
---
net/sunrpc/auth_gss/auth_gss.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/sunrpc/auth_gss/auth_gss.c b/net/sunrpc/auth_gss/auth_gss.c
index 5f42aa5fc612..eb52eebb3923 100644
--- a/net/sunrpc/auth_gss/auth_gss.c
+++ b/net/sunrpc/auth_gss/auth_gss.c
@@ -848,7 +848,8 @@ gss_pipe_destroy_msg(struct rpc_pipe_msg *msg)
warn_gssd();
gss_release_msg(gss_msg);
}
- gss_release_msg(gss_msg);
+ if (gss_msg)
+ gss_release_msg(gss_msg);
}Is this just a general grievance thread now? How incorrect setup of nginx is related to possible code review issues in the kernel?
The design issues are also not a question here. Linux is what it is. Don't like it - don't use it. I personally more concerned with Windows sending your data to Microsoft in an advertised way. That's why I don't use Windows.
There is no need to put solving all the world's problems on kernel developer's shoulders.
Lot's of your personal data are handled by Loonix servers AND desktops probably too, just so you know.We get it, you hate Linux. Now move on.
The point is that the process is flawed so why should we trust it.You should not. But there is no place where a non-flawed version of the process is implemented. So you pick whichever you consider better and move on with your life.
If a reviewer misses that then he will miss everything. And if the actual maintainer of the code in question misses it, then what's wrong with a student missing it when he saw such suspiciously looking code in the output of a static analyzer?There is nothing wrong with missing it. Admitting to intentionally submitting a buggy code and writing an article about is wrong.
The point is that the process is flawed so why should we trust it.You should not. But there is no place where a non-flawed version of the process is implemented. So you pick whichever you consider better and move on with your life.
No, I hate Greg and all those other "peace, love and open sores" hippie idiots who are surely turning it into cancer.
I know bd139 will say it's always been cancer, but I used to be younger so maybe I just didn't see it :-DD