University of Minnesota Linux code security issues; banned and to be removed - Page 1
Forum section: electronics / general

author: Tomorokoshi
author_rank: Super Contributor
timestamp: April 23, 2021, 01:18:58 pm
content: Linux kernel security and open-source issues:https://cse.umn.edu/cs/statement-cse-linux-kernel-research-april-21-2021https://www.theregister.com/2021/04/21/minnesota_linux_kernel_flaws_update/https://www.theverge.com/2021/4/22/22398156/university-minnesota-linux-kernal-ban-researchhttps://hothardware.com/news/linux-kernel-developer-bans-updates-from-university-of-minnesotaWorking through what all this means.

author: ataradov
author_rank: Super Contributor
timestamp: April 23, 2021, 04:55:05 pm
content: It means that their research ethics committee is pretty loose on the "ethics" part.I also don't get this "research". There are bugs in the kernel that were non-maliciously contributed. So obviously it is possible to do that maliciously. What did they want to prove with that research?The ban is fully justified, IMO. No need to take the code from people that acted maliciously in the past.

author: JohnnyMalaria
author_rank: Super Contributor
timestamp: April 23, 2021, 05:31:46 pm
content: This is a classic example of the scourge rampant in modern academia.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.Of the two authors, Wu is a PhD student andLu is an assistant professorwho has 37 peer-reviewed (edit: see below) articles published since 2013. He got his PhD in 2017.Looking at the titles of some of the articles, it appears Prof Lu is just a dressed-up version of a teen hacker getting kicks from academic masturbation.https://scholar.google.com/citations?user=1F9N6icAAAAJ&hl=en&oi=sraEDIT: after closer inspection, many of Lu's papers aren't peer-reviewed at all. There are just conference proceedings. i.e., he presented a paper at a conference. Generally, there's no peer-review - you could make up anything and, as long as it seems plausible, get accepted to speak.

author: ataradov
author_rank: Super Contributor
timestamp: April 23, 2021, 06:15:12 pm
content: 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?

author: DrG
author_rank: Super Contributor
timestamp: April 23, 2021, 06:42:43 pm
content: Quote from: JohnnyMalaria on April 23, 2021, 05:31:46 pmI agree, but am not sure that it is accidental that it looks like a research paper...that is, it may have been intended to be a research paper for submission.According to this (published a few days agohttps://www.theregister.com/2021/04/21/minnesota_linux_kernel_flaws_update/) "....Vulnerabilities in Open-Source Software via Hypocrite Commits" , which is slated to be presented at the Proceedings of the 42nd IEEE Symposium on Security and Privacy next month..."https://www.ieee-security.org/TC/SP2021/I also agree with your point about the difference between a presentation and a peer-reviewed publication (having considerable experience with both, but never IEEE 'stuff').This issue seems to me to be more provocative than anything else. While I have not and likely will not spend a lot of time on it, I think that it will garner a lot of attention and a lot of scrutiny as well.Also, from the cite above "It further states that the experiment was vetted by the university's Institutional Review Board (IRB), which determined that the project did not constitute human research and thus granted an ethical review waiver." - my guess is that the IRB board is going to modify some SOP as a result of this - not sure, but that is where I would put my money because, while not within a strict IRB mandate, the University is going to be fielding a lot of questions about why they got a waiver.

author: SilverSolder
author_rank: Super Contributor
timestamp: April 23, 2021, 06:50:08 pm
content: Quote from: ataradov on April 23, 2021, 06:15:12 pmEngineers are asked to do that every day!

author: bd139
author_rank: Super Contributor
timestamp: April 23, 2021, 07:20:13 pm
content: As someone who has to gargle the shit of a couple of hundred software developers every day I think this is a good thing. It sows distrust which in turn causes greater testing and validation to take place.It's also hilarious.

author: ataradov
author_rank: Super Contributor
timestamp: April 23, 2021, 08:13:06 pm
content: It would not cause better validation. There no humanly possible way to make sure that individual patch does not open some sort of a hole in a bigger system. You can do your best to review the patch to make sure that is is not obviously wrong, but not much more. Or you will have to invest a lot more resources, which neither free or commercial software typically has.In fact, I bet there is a much higher probability of intentionally bad code accepted to the closed source code base, as the code was written in a trusted environment. How hard would it be to blackmail, or just buy some programmer at Microsoft to introduce an innocent-looking hole? Or even a rouge employee introducing some code to take advantage later in case employment does not go so well. This is not something that can be done as part of this hack job of a "research", of course.And unlike here, where all contributions by that university are removed from the code base, there is no chance Microsoft would remove and rewrite code after firing an employee.So the whole premise of this effort is wrong.Not so long ago easter eggs were a common place, and I'm not sure how much knowledge management had about them. This practice was stopped at Microsoft, and for a good reason, but the same principle applies.This research is of the same nature as "Hey, look, I can defecate in the middle of the street and not get caught and fined. The system is exploitable."

author: bd139
author_rank: Super Contributor
timestamp: April 23, 2021, 08:18:30 pm
content: Yeah I work in fintech. We have background checks, multiple layers of review, static analysis, vulnerability analysis (DAST/SAST), least privilege implementations everywhere.Linux doesn't yet everything we do is based on it.YMMV but the issue is that the whole industry is a complete amateur shit show and will be like the engineering industry was until the bodies were stacked high enough to mean something...

author: DrG
author_rank: Super Contributor
timestamp: April 23, 2021, 08:31:54 pm
content: Quote from: bd139 on April 23, 2021, 07:20:13 pmBad administrator, no doughnut for you.

author: ataradov
author_rank: Super Contributor
timestamp: April 23, 2021, 08:43:53 pm
content: Quote from: bd139 on April 23, 2021, 08:18:30 pmSo can you 100% say that you never found a bug in the released code base?I'm not saying that Linux people do as much as possible now. They do as much as they realistically can.Some fields require more scrutiny than others. People dealing life sustaining application or even automotive stuff are doing more testing, since there resources are justified.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.

author: bd139
author_rank: Super Contributor
timestamp: April 23, 2021, 08:52:45 pm
content: Oh no my point and the hilarity is that we do all that to increase our quality (100% is impossible) and immediately without thought stick it on top of a Linux kernel which is full of bugs introduced by untrusted university researchers.

author: DrG
author_rank: Super Contributor
timestamp: April 23, 2021, 09:16:06 pm
content: Quote from: ataradov on April 23, 2021, 08:43:53 pmYes, the difference between a 'checker' and a 'doer', but let me ask you something specific...in the "paper" and in the "walk back"https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.pdf...and I have seen enough walk-backs in my time to recognize them and distinguish them from clarifications, so It's only my opinion, but I am sticking with thatThe claim is that suggestions were made for improvement. That is, they went beyond simply showing/saying this is screwed up, do a better job. Do you think that they did that reasonably? (I don't know, but I thinking their suggestions for improvement might be considered under-whelming or unrealistic).In the paper, we provide our suggestions to improve the patching process.- OSS projects would be suggested to update the code of conduct, something like “By submittingthe patch, I agree to not intend to introduce bugs”.- We need automated tools for testing and verifying patches. The relevant techniques includedirected fuzzing, (under-constrained) symbolic execution, formal methods, etc. More details arein the paper.- OSS maintaining is understaffed. We should very much appreciate and honor maintainer efforts,and increase potential incentives if possible to encourage more people to join the maintaining.- We hope both reporters and maintainers are aware of the potential bug-introducing patches. Also,tools can be developed to check “immature vulnerabilities”.(from the 'clarification' cited above)

author: bd139
author_rank: Super Contributor
timestamp: April 23, 2021, 09:26:19 pm
content: To be fair that clause is in our employment contracts under "malicious intent".

author: coppice
author_rank: Super Contributor
timestamp: April 23, 2021, 09:31:26 pm
content: Quote from: bd139 on April 23, 2021, 09:26:19 pmIsn't most of an employment contract there with malicious intent?

author: bd139
author_rank: Super Contributor
timestamp: April 23, 2021, 09:33:12 pm
content: Yep

author: magic
author_rank: Super Contributor
timestamp: April 23, 2021, 10:05:21 pm
content: Anyone has seen links to the bad patches and how the review process went for them?A quick glance at responses to Greg's mass-revert shows that most stuff from that university was legit fixes.

author: DrG
author_rank: Super Contributor
timestamp: April 23, 2021, 10:38:32 pm
content: I'm probably thinking about this more than I should, but I was reading this thread:https://github.com/QiushiWu/qiushiwu.github.io/issues/1(That is the PHD candidate - right?)First off, let this be a lesson to the kids out there- don't piss off the people above you unless you are really, really good (ok, I am saying that with aOne big issue that comes to mind, and I don't know enough to even speculate, does this constitute penetration testing without authorization? If so, that would have some consequences, I would think - anybody have a more educated opinion than mine?The other issue concerns the IRB, when did they get approval and the waiver, and whether that is going to be 'changed', the process or otherwise, in the near future. I already weighed in on that and I am sticking with that opinion.From that thread, this fellow is gearing up to make an apology (not a clarification) and, as could be anticipated, is getting a lot of heat. Some justifiable, some maybe not so not so much.I wonder how the presentation goes (if it is not retracted) - a lengthy apology to begin? Concentration on this idea of “immature vulnerability”, which does not seem all that original, but I don't know.Right now, I think there is a lot of scrambling going on - what do we have to change and how do we do that?....I once had to take a mandatory Jeep Safety Training and Motorcycle Safety Training...as far as I know, I have never been in a Jeep and except for a brief period of time in my youth (EZ-Rider period) I don't own or use a motorcycle. It took me a while to understand how those mandates came to be and it was quite a lesson in bureaucratic processes.

author: bd139
author_rank: Super Contributor
timestamp: April 23, 2021, 10:50:59 pm
content: 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.

author: DrG
author_rank: Super Contributor
timestamp: April 23, 2021, 11:03:52 pm
content: Quote from: bd139 on April 23, 2021, 10:50:59 pmDo 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?

author: ataradov
author_rank: Super Contributor
timestamp: April 23, 2021, 11:20:10 pm
content: Quote from: magic on April 23, 2021, 10:05:21 pmThe bad patches were also masqueraded as legit fixes. They just had unintended side effects.And the removal is more of a deterrent. I'm sure most of that code is fully legit, but you don't want to encourage this type of childish and stupid behavior. It might turn into a stupid trend of trying to push bad code into the kernel in a more and more escalating ways.In fact, I personally would cancel the conference talk too, just to signal to others that there is absolutely nothing to be gained from that.

author: bd139
author_rank: Super Contributor
timestamp: April 23, 2021, 11:21:46 pm
content: Quote from: DrG on April 23, 2021, 11:03:52 pmLoudest ego wins in 2021 and that appears to be the kernel team.But adversaries know it’s a process vulnerability now so not acting would be socially irresponsible. Also this is now on everyone’s risk assessment and if it happened again the paid up vendors will be on the hook.Could go either way but this is a massive “oh shit” moment that will affect the industry for years. Not immediately though!

author: ataradov
author_rank: Super Contributor
timestamp: April 23, 2021, 11:25:12 pm
content: Quote from: DrG on April 23, 2021, 11:03:52 pmI 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.I use Linux on my PCs and I'm personally fine with the Linux as it is. I don't think their model of development is flawed in any way here.I would not ascribe Linux developers some grand social responsibility. They are just writing software. The responsibility lies on the users. If someone truly believes that malicious intent clause in the contract would prevent proprietary software from having bugs, then they are free to switch to that proprietary software.And if as a result Linux sees significant drop in use, then they will have problem that they would have to address.

author: magic
author_rank: Super Contributor
timestamp: April 24, 2021, 07:35:13 am
content: 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.Only if no one did, then the students have indeed wasted everybody's time for no gain and should have never published their paper out of embarrassment.By the way, a few years ago many RAID0 SSD arrays lost data because of a buggy fix to a hypothetical bug that affected nobody, which ended up destroying every array every time trim was used on it. It's painfully obvious no one had even tested the alleged fix, and it got backported to all stable releases, thank you very much.So it's not even the first time shit happens. I'm inclined to agree that they are understaffed, probably overambitious, and as a result - overworked. Oh well.editFrom limited personal experience (n=1) I can say that pushing fixes for obvious bugs is indeed not very hard and some maintainers seem to treat it as a nuisance and just want to be done with it. In particular, I was a bitwhen somebody from the stable team just emailed me a question which releases the patch is compatible with, with little indication that my answer will receive any scrutiny.So if you want to introduce a very stealthy vulnerability into Linux, come up with a commit which fixes some current problem while subtly breaking whatever -stable release is currently used by Ubuntu

author: ataradov
author_rank: Super Contributor
timestamp: April 24, 2021, 04:58:29 pm
content: Quote from: magic on April 24, 2021, 07:35:13 amCode reviews are never 100% effective. Otherwise we would not have bugs in the software, since majority of big companies have code reviews.Code reviews make sure that coding style is fine and the code is generally not complete garbage. Reviews would take forever if they had to review how specific patch affects the rest of the system.I don't see why this is an issue that someone may intentionally introduce a hole. This sounds like a lot of work, it is much easier to find existing holes if you want them. There are plenty, for sure. And not only in the kernel, but in the rest of the user land too.

author: rstofer
author_rank: Super Contributor
timestamp: April 24, 2021, 07:57:03 pm
content: In the FPGA universe, it is common to build test benches to verify component behavior. I don't know that program code gets this level of testing. Maybe...If builders built buildings like programmers write programs, the first woodpecker to come along would destroy civilization.

author: tunk
author_rank: Super Contributor
timestamp: April 24, 2021, 10:47:38 pm
content: The "Call For Papers" for this symposium is below; all submitted papersare reviewed (no description of what this means). This paper was accepted,so the review process can't be very rigorous. And maybe IEEE shouldreconsider the acceptance?https://www.ieee-security.org/TC/SP2021/cfpapers.html

author: ataradov
author_rank: Super Contributor
timestamp: April 24, 2021, 10:59:19 pm
content: Quote from: rstofer on April 24, 2021, 07:57:03 pmAnd the review in this case was focused on the component. The issues are introduced in the integration part.If FPGA process was so good, we would not have erratas. Yet there are pages of them for simplest of the MCUs.And buildings also experience issues that need fixing occasionally. Get off your high horse and don't assume you are somehow better than everyone else.

author: Ed.Kloonk
author_rank: Super Contributor
timestamp: April 24, 2021, 11:56:37 pm
content: From the earliest days, the Kernel devs have made it clear that you must not waste their time with submitting code that does not work as advertised. Anyone with even an outer-orbit involvement of the Linux kernel knows this.The uni scrambled to put together a statement so as to avoid getting sued. If that had happened to a tech company, not a community as such, the uni would be getting sued back into the stone age. Notice the difference if your were to 'test' the IT infrastructure of a govt department. Someone's ass would be heading for jail.The uni dept heads are culpable because they should have peer-reviewed code sent up stream and thus been aware of the malicious intent. Either that or they are lying about knowing.Greg KH's response is justified.

author: DrG
author_rank: Super Contributor
timestamp: April 25, 2021, 02:07:45 am
content: There is being an asshole and there is being an asshole who has done something tangibly wrong in a moral, ethical and legal sense, that you can prove.There has to be a sound and clearly stated reason to be punitive and the degree of punishment needs to at least appear to be commensurate with the wrongdoing.So, what, if anything, do you do to this fellow and his supervisor if you are the University?I believe the author has admitted wasting their time and apologized. Some rationale about not knowing how else to demonstrate what he wanted to demonstrate. Looks like there is no big argument here, but how much punishment can be meted out for that?Let's say the University can and does withdraw the paper - they need to have some sound reasons to do that, if they already approved the submission (passively or actively). The question becomes, what new information has come to light since then that can justify that action?Let's say the proceedings folks cancel it - same situation...if it was accepted, what has changed?IOW, would either party say....well we screwed up and did not know what we were clearing.....whoa.Let's say it is determined that the IRB should not have granted a human use waiver, or, if it is in their jurisdiction, should have found it be unethical. If they now say that it constitutes human use, there is a whole shitload of ramifications. If they now decide it is unethical, what changed?So, trying to un-ring the bell has some serious problems. Adding new regs....added agreements, signed promises, however you want to say it - yeah, that can certainly be done.Somebody want to start litigation of some kind - ok, now show damages.We all know that we put more checks and balances in place than the resources to manage, let alone, enforce themThere 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.

author: Ed.Kloonk
author_rank: Super Contributor
timestamp: April 25, 2021, 02:19:40 am
content: The code was submitted under the banner of the name of the Uni. Not as an individual.

author: Ed.Kloonk
author_rank: Super Contributor
timestamp: April 25, 2021, 02:21:23 am
content: Quote from: DrG on April 25, 2021, 02:07:45 amDon'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.

author: DrG
author_rank: Super Contributor
timestamp: April 25, 2021, 02:29:20 am
content: Quote from: Ed.Kloonk on April 25, 2021, 02:21:23 amNo, I think I understand what you are saying. The ban is for submissions from their .edu. So, how damaging is that for the Univ? 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.edited: I mean, the Linuxites seem to be within their rights....we got these bogus patch requests from your .edu and they wasted our time, so we are not going to accept such requests from your .edu. How bad is that and for whom?

author: ataradov
author_rank: Super Contributor
timestamp: April 25, 2021, 02:32:54 am
content: Quote from: DrG on April 25, 2021, 02:07:45 amGet 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.Quote from: DrG on April 25, 2021, 02:07:45 amThe 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.Quote from: DrG on April 25, 2021, 02:07:45 amThis "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.Quote from: DrG on April 25, 2021, 02:07:45 amI would not. Why waste time? Not dealing with people that intentionally waste my time is the best I can do.

author: ataradov
author_rank: Super Contributor
timestamp: April 25, 2021, 02:35:19 am
content: Quote from: DrG on April 25, 2021, 02:29:20 amI'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.

author: DrG
author_rank: Super Contributor
timestamp: April 25, 2021, 02:41:04 am
content: Quote from: ataradov on April 25, 2021, 02:35:19 amI 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.

author: ataradov
author_rank: Super Contributor
timestamp: April 25, 2021, 02:45:33 am
content: Quote from: DrG on April 25, 2021, 02:41:04 amJust 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.

author: DrG
author_rank: Super Contributor
timestamp: April 25, 2021, 02:47:28 am
content: Quote from: ataradov on April 25, 2021, 02:32:54 amThe thing is, and I am really not trying to be confrontational, is that if you are being administrative and being official, youcancan't start withdrawing papers that you already cleared (assuming they did) because it was childish."clear waste of time and money" IYO but the defense is that "we did it to show this dangerous situation and blah blah blah" - again, not trying to contradict you but I have to point out that some of what your saying is really opinionated and would not, necessarily,"litigate" well. If it was specified very well, operationally defined, concisely, it could be codified I suppose...but that is a lot of work.

author: ataradov
author_rank: Super Contributor
timestamp: April 25, 2021, 02:52:30 am
content: Quote from: DrG on April 25, 2021, 02:47:28 amBut 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.Quote from: DrG on April 25, 2021, 02:47:28 amIt 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.

author: DrG
author_rank: Super Contributor
timestamp: April 25, 2021, 03:00:47 am
content: Quote from: ataradov on April 25, 2021, 02:45:33 amOK, let me come at iy differently because I do think that you are more right than wrong, but when you want to regulate something (or stop something) you have to be down right brilliant in how you codify it or you will get all kinds of unintended effects.What, should have happened to have prevented this? Hypothetically...s supervisor saying "I do not support this line of research, or this methodology (or both) because I don't thing it is novel or significant or likely to yield information of real value". That should have stopped it and that happens all the time (much to the dismay of graduate students). But what if the supervisor does not feel that way?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.A mini version of all of that had to take place if you wanted to any research.So, did that happen here? Should it have - I'm sure you would say yes, but academic freedom is a big deal as I'm sure you know. It is very complicated and you, in general, want to keep it that way so that you are not turning out factory style work (some would argue that happens anyways).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.First, I want to know precisely what was done wrong here.

author: DrG
author_rank: Super Contributor
timestamp: April 25, 2021, 03:08:35 am
content: Quote from: ataradov on April 25, 2021, 02:52:30 amHang 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. Having to withdraw it means that something happened in the meantime and in my world that was a huge rarity and I never withdrew a paper like that, ever. Now, I can remember telling someone to remove my name from a presentation unless you do this or that because I am not going to be part of those conclusions given those data and those analyses...that was more than enough...and all that took place before it was submitted for local clearance.I am not saying the Univ can't withdraw the paper (I did say, assuming that they can). Let's stipulate that they can...they have to state a reason...they can't say, after they allowed it to be submitted, well we want it withdrawn because they are childish - you get what I am saying?The Linuxites are well within their rights to reject patch requests from an .edu and whether they have to or not, they did give a reason. I would add, when people or entities engage in punitive action without giving a reason, it invites trouble.

author: ataradov
author_rank: Super Contributor
timestamp: April 25, 2021, 03:16:49 am
content: Quote from: DrG on April 25, 2021, 03:00:47 amThat 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.If Linus agrees that this may be a valid test, he will outline exact boundaries (I bet it would exclude the code reaching stable kernel). I would trust Linus to not tell everyone to expect this check (unlike most of the certification checks I've been a part of at various jobs).Quote from: DrG on April 25, 2021, 03:00:47 amExactly. 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.And if all of those people did not just robber-stamp this and for real though it was a valid thing to do, then their qualification should be questioned too.Quote from: DrG on April 25, 2021, 03:00:47 amBut 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.Just to be clear, I'm not saying that this article somehow revealed that it is easy to push bad patches. No, this is well known, and I'm sure state actors take advantage of that already. The point is to prevent flood gates of low grade crap like this.Quote from: DrG on April 25, 2021, 03:00:47 amIn short - poor experiment setup passed the review process.If anything, I fee like this shows disconnect between industry and academia. Academics think that no bad code must ever pass the review. But this is not attainable in real life without stopping the development process entirely. This does not just affect OSS project. Commercial projects suffer from the same issue. So may be review board need to include more people from the industry with a realistic view of the world.

author: DrG
author_rank: Super Contributor
timestamp: April 25, 2021, 03:26:44 am
content: 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.

author: ataradov
author_rank: Super Contributor
timestamp: April 25, 2021, 03:28:59 am
content: Quote from: DrG on April 25, 2021, 03:08:35 amThe definition of "all the time" is vague, so I withdraw thatBut it happens quite a bit. That's why sites likehttps://retractionwatch.com/exist.One of the most recent example of such "research" is this -https://retractionwatch.com/2021/04/21/journal-retracts-paper-suggesting-smoking-is-linked-to-lower-covid-19-risk/. I'm not involved with the scientific process, so I'm not too familiar with it, but this article should have never made it out of the door of any legit institution.Quote from: DrG on April 25, 2021, 03:08:35 amThe 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.

author: ataradov
author_rank: Super Contributor
timestamp: April 25, 2021, 03:34:12 am
content: And this behaviour overall is reminding me of the researches attempting to show that peer review is also questionable by submitting and passing review on AI generated garbage articles.Again, seemingly shows vulnerability of the system. In reality it shows nothing. Sure, it would be better if peer review process caught complete nonsense. But at the same time, who cares if that nonsense is of no real significance.

author: Ed.Kloonk
author_rank: Super Contributor
timestamp: April 25, 2021, 04:09:44 am
content: Quote from: DrG on April 25, 2021, 03:26:44 amI think that due to the personal situation of those involved, public opinion may force Greg KH to walk back his statement.

author: magic
author_rank: Super Contributor
timestamp: April 25, 2021, 06:24:53 am
content: You guys are funnyThe 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 placeOTOH, 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 alonePerhaps a lesson has been learned, do such things anonymously and don't brag about them under your real name later.

author: Ed.Kloonk
author_rank: Super Contributor
timestamp: April 25, 2021, 06:35:37 am
content: Quote from: magic on April 25, 2021, 06:24:53 amCan you point to the spot in said paper?Gmail accounts are historically how Linux people communicate.

author: magic
author_rank: Super Contributor
timestamp: April 25, 2021, 06:41:04 am
content: You start with downloading the PDF and then CTRL+F gmailSection VI on page 8.

author: ataradov
author_rank: Super Contributor
timestamp: April 25, 2021, 06:51:32 am
content: It does not matter what emails were used. The work is endorsed by the University. And the "publicity stunt" is the reason why that uni should be forever banned from submitting anything. It would start a war of one upping each other. There must be real consequences for publicity stunts.It is like gender reveal parties. The further it goes, the stupider and more dangerous it gets.And their recent apology letter should be followed up by withdrawing that article from the IEEE conference. As it stands, their words still say one thing, and the actions say completely the opposite.The work on the article started quite some time ago. Those things have a pipeline. So who knows what other articles they were working on, and what consecutive patches from them are trying to test other things? It is safer to just remove all of them. Especially given that their contributions were not significant in any way.

author: hans
author_rank: Super Contributor
timestamp: April 25, 2021, 07:27:14 am
content: Quote from: magic on April 25, 2021, 06:24:53 amThat still doesn't change the situation for the better. You can prove that personal information won't be gathered from your test subjects, however, that is par of the course in any scientific experiments regarding test subjects (maintainers in this case).The thing that disgusts me the most is that the test subjects did not agree to be experimented on; there is no mutual consent; which is quite clearly described byunethical human experimentsand very clearly inhuman subject rights.Certainly I'm citing documents for medical tests that may involve needles or new medicines. However, I don't really see why engineering should be an exception to that rule. It's just not common practice in our field to worry about these things..Like I said.. you can only do these kinds of experiments in controlled environments on toy projects.Quote from: magic on April 25, 2021, 06:24:53 amYep... I still really don't understand what novelty the paper is trying to show. Review processes are not airtight processes, because they are controlled by humans. This happens in academia, will happen in code reviews, and probably also just as often in budget approvals within companies.I'm too lazy to look it up rn, but I'm pretty sure that psychology, (engineering) philosophy and/or behavioural science has done research on controlling review processes and associated cognitive biases.Even student supervisors or (direct) colleagues can't always catch fraudulent entities. This happens plenty of times in academia, unfortunately. Some students or profs are feeling they're on their back foot in terms of research progress, number of publications, their time frame, etc. Some may also feel they deserve more recognition and thereby force the results. And it's a very trivial thing to do... Being impartial e.g. cherry picking hypotheses that fits the curve is just as bad as making stuff up.

author: bd139
author_rank: Super Contributor
timestamp: April 25, 2021, 08:30:13 am
content: 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.

author: Ed.Kloonk
author_rank: Super Contributor
timestamp: April 25, 2021, 09:09:00 am
content: Quote from: bd139 on April 25, 2021, 08:30:13 amNar.It gets back to my original point. Don't fuck with the kernel devs.There are many more peeps reviewing the code than there are those risking excommunication by serving up a shit show.Go watch Meet the Fockers. Embrace the concept of circle of trust.

author: DrG
author_rank: Super Contributor
timestamp: April 25, 2021, 03:41:37 pm
content: Quote from: magic on April 25, 2021, 06:24:53 amAs the song goes...lotta people funny - now you funny too.I did read the original paper and no I did not try to study it intently and yes, you and a kazillion other nerds know much more about Linux than I. I thought the ban was against .edu and maybe I am wrong...probably I am wrong even.In your indictment about funny people above, "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."and"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."So, I just read this:https://lore.kernel.org/linux-nfs/YH%2F8jcoC1ffuksrf@kroah.com/"> > > They introduce kernel bugs on purpose. Yesterday, I took a look on 4> > > accepted patches from Aditya and 3 of them added various severity security> > > "holes".> >> > All contributions by this group of people need to be reverted, if they> > have not been done so already, as what they are doing is intentional> > malicious behavior and is not acceptable and totally unethical. I'll> > look at it after lunch unless someone else wants to do it..."Yes, there are snips and so on and it is hard to follow the thread, but it does not look like these are all from random students, as you said. It looks like these are from a known and small group of students. [edit: the ones that really pissed people off]There also appear to have been two rounds of this and "the paper" is distinct from the "analyzer" round. Even though you mentioned the analyzer, you don't seem to appreciate that difference when you suggest "it's all in the paper'.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.

author: DrG
author_rank: Super Contributor
timestamp: April 25, 2021, 03:44:49 pm
content: 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 communityDate: Sat, 24 Apr 2021 17:30:50 -0500An apology, posted yesterday....https://lore.kernel.org/lkml/CAK8KejpUVLxmqp026JY7x5GzHU2YJLPU8SzTZUNXU2OXC70ZQQ@mail.gmail.com/

author: SilverSolder
author_rank: Super Contributor
timestamp: April 25, 2021, 04:41:46 pm
content: Quote from: DrG on April 25, 2021, 03:44:49 pm@Dr. G, if you were to post that you had been mugged yesterday, you would get one or two comments defending the mugger... on the Internet, there is always someone taking the opposite view, that's how debate works!

author: ataradov
author_rank: Super Contributor
timestamp: April 25, 2021, 04:54:12 pm
content: Quote from: bd139 on April 25, 2021, 08:30:13 amIt 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.If anything, you can call it a conversation starter. But it is like starting a conversation on how to feeds kids in Africa. There are no practical short term solutions, so the whole effort is pointless.Also, why kernel? Go bother Apache people, for example. There are a ton of projects that are susceptible to the same exact issue.Or go further, and show that not only OSS is susceptible, figure out a way to infiltrate a closed source company.They did absolute minimal and lamest amount of work. And then blown it up to the article size. This is now a lot of modern "research" goes.

author: ataradov
author_rank: Super Contributor
timestamp: April 25, 2021, 04:58:33 pm
content: Quote from: DrG on April 25, 2021, 03:44:49 pmAs I said, in the spirit of that apology, they should not benefit from the article. So remove it from the IEEE conference.As of now, they are saying they are sorry, yet going forward with all if their plans.

author: DrG
author_rank: Super Contributor
timestamp: April 25, 2021, 05:08:52 pm
content: Quote from: SilverSolder on April 25, 2021, 04:41:46 pmNahh, 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.

author: SilverSolder
author_rank: Super Contributor
timestamp: April 25, 2021, 05:13:07 pm
content: Quote from: DrG on April 25, 2021, 05:08:52 pmI think the algorithm that most people go by is this:IF <AnotherPerson> DID <something I would not be ashamed of doing myself> THENDefend;ELSECondemn;

author: ataradov
author_rank: Super Contributor
timestamp: April 25, 2021, 05:17:23 pm
content: Quote from: SilverSolder on April 25, 2021, 05:13:07 pmThis 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.And percentage of defending of condemning show how much of a grey area the behaviour is.

author: DrG
author_rank: Super Contributor
timestamp: April 25, 2021, 05:23:36 pm
content: Quote from: ataradov on April 25, 2021, 05:17:23 pmNote that there is a difference between not being ashamed of doing something and not being ashamed of getting caught doing something that you are not ashamed of doing....just ask a sociopath

author: SilverSolder
author_rank: Super Contributor
timestamp: April 25, 2021, 05:24:42 pm
content: Quote from: ataradov on April 25, 2021, 05:17:23 pmWhere that algorithm falls down is that what makes you ashamed is defined by your upbringing and culture, as much as (or more than) what you are actually doing...The same person can be ashamed of something as a teenager that they then routinely do later in life, and vice versa.It is also possible to be "incorrectly ashamed" of something that is actually natural.Basically, the feeling of being ashamed of something is not really a sound basis for condemning others?

author: ataradov
author_rank: Super Contributor
timestamp: April 25, 2021, 05:30:26 pm
content: Quote from: SilverSolder on April 25, 2021, 05:24:42 pmSure, but you can make finer subdivisions of the society and apply the same algorithm.Quote from: SilverSolder on April 25, 2021, 05:24:42 pmFor sure, and that would represent societal flaw. Those happen too in real life and societies need to work on fixing those.Quote from: SilverSolder on April 25, 2021, 05:24:42 pmMay be not, but it is one of the factors.I personally would be more supportive of the researches if they research was actually novel or proposed a real path to a solution of the exposed problem. It is neither in this case.I would draw parallel with HeartBleed vulnerability discovery. It opened the flood gate of similar speculation and cache-timing attacks. It caused short term havoc. But it also had concrete path to fixing the issue, even if it was hard and required redesign of a lot of silicon, and potentially losing some performance.

author: hans
author_rank: Super Contributor
timestamp: April 25, 2021, 06:08:39 pm
content: Well, if all research must find an even balance between the number of problems they find and solve, we wouldn't get anywhere. It's almost cliche, but: “We can’t solve problems by using the same kind of thinking we used when we created them.”Nonetheless, I do think that this work and actions is basically firing a shotgun at point blank range and pointing at the huge exit wound it created. No shit sherlock. That's why we have huge collections of static analysis tools, formal verification tools unit test frameworks and heuristics to combat bugs and regressions. But in virtually any equation, humans will be the limiting factor in how well we do.

author: bjbb
author_rank: Contributor
timestamp: April 25, 2021, 06:22:55 pm
content: 18USC1030(a)(5) and (b)I am just a simple-minded engineer, but I can read. My (legally worthless) opinion is that this Lu person could be prosecuted as part of a conspiracy to intentionaly commit a felony described by the above statute. That said, this law is bad because it is, by design, overly broad code intended to cast a wide net such that the feds can easily go after any hacker that pisses them off.There is only way that is both ethical and enables actual research. Inform a senior officer of the organization that you want to submit bad stuff, explain your research process, and request permission. This is the defacto process for many penetration research projects.The 'research' students lied about about the nature of the submitted kernel patches, thus expulsion is an academic (IRB) requirement; to wit, the kernel people accused the linux kernel people of "making wild accusations that are bordering on slander" in writing. This alone casts the doubt on any an all computer science 'research' programs at that school. The chain of messages indicates other lies and misrepresentations after the kernel people called them out. And There are other messages in the list that claim no changes made it to stable, but at least one did.I have been criticized in this venue per my comments on the generally poor performance of academia, and I sincerely do not intend to insult educators. But wrong is wrong, and disingenuous actions are not mitigated by 'good' intentions.

author: DrG
author_rank: Super Contributor
timestamp: April 25, 2021, 07:50:23 pm
content: ....We take this situation extremely seriously. We have immediately suspended this line of research. We will investigate the research method & the process by which this research method was approved, determine appropriate remedial action, & safeguard against future issues, if needed....From the University's 'official' response (4 days ago in case you missed it)https://twitter.com/UMNComputerSci/status/1384948683821694976

author: ataradov
author_rank: Super Contributor
timestamp: April 25, 2021, 08:08:46 pm
content: They can apologize all they want. They say nothing about retracting the article, especially from IEEE conference. The authors should not benefit from this, otherwise it just legitimizes the approach of doing something and then apologizing later. You know, Silicon Valley approach of moving fast and breaking things.For the same reason as illegally obtained evidence is not admisible in the court. They don't say "this was bad, but since we've got it, lets use it". No, they just reject it without questions to not encourage more of the same behaviour.

author: magic
author_rank: Super Contributor
timestamp: April 26, 2021, 06:29:52 am
content: Quote from: DrG on April 25, 2021, 03:41:37 pmYes, you are very boring, trying to understand stuff instead of getting triggeredThis thread does make the ban look more reasonable, but the nature of Aditya Pakki's patches is still unclear. He/she is not one of the authors of the "hypocrite commits" paper and those didn't post from their .edu addresses. It's not clear how Leon Romanovsky made the connection, save for the obvious similarity in the technical quality of said patches.Here Greg quotes from appears to be the AP's answer to the shitshow, the archive doesn't contain the original email for some reason.https://lore.kernel.org/linux-nfs/YH%2FfM%2FTsbmcZzwnX@kroah.com/QuoteSo either their ethics review board greenlighted a next level project which includes working in the open and lying blatantly, or perhaps it really is another group this time, principally honest but perhaps not as competent as they considered themselves to beHence my remark, why stop at one university, just review everything that gets submitted, you never know what's thereI wonder if Theo de Raadt has posted anything. On one hand, he would probably enjoy taking the piss at Linux security. On the other, it could nivite attention...

author: magic
author_rank: Super Contributor
timestamp: April 26, 2021, 07:35:53 am
content: https://lore.kernel.org/linux-nfs/20210423214850.GI10457@fieldses.org/Just as expected

author: Ed.Kloonk
author_rank: Super Contributor
timestamp: April 26, 2021, 07:42:47 am
content: Quote from: magic on April 26, 2021, 07:35:53 amCan you explain what is amusing for those of us playing along at home?

author: ataradov
author_rank: Super Contributor
timestamp: April 26, 2021, 07:54:34 am
content: There may be some legit patches. Or may be not. Once the trust is broken, it is safer to assume the whole organization to be malicious.It is reasonable to remove all code from them until it is reviewed. And if all they did was post static code analysis patches, then not a whole lot of value would be lost of they are removed forever. Static code checker patches are always the lowest grade.There are a ton of people running static code checkers on the kernel, there is nothing particularly interesting about that work.

author: magic
author_rank: Super Contributor
timestamp: April 26, 2021, 08:00:16 am
content: Quote from: Ed.Kloonk on April 26, 2021, 07:42:47 amThe 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.Some fixes were dumb and got rejected, some were subtly wrong but the devs took them anyway.Some other guy went "what the heck, let's look what happens if we send them rubbish deliberately from throwaway gmail accounts".Now the kernel tries to put all blame on Project Rubbish and pretends that everything that they accepted that wasn't correct must have originated from there

author: SilverSolder
author_rank: Super Contributor
timestamp: April 26, 2021, 12:38:42 pm
content: Never waste a good crisis!

author: bd139
author_rank: Super Contributor
timestamp: April 26, 2021, 02:46:03 pm
content: Quote from: bd139 on April 23, 2021, 11:21:46 pmI retract the latter part of my previous commentWhat I am learning from this is that we're in the hands of asshats.

author: mikerj
author_rank: Super Contributor
timestamp: April 26, 2021, 08:03:11 pm
content: Quote from: bd139 on April 26, 2021, 02:46:03 pmWelcome to the modern world.

author: magic
author_rank: Super Contributor
timestamp: April 26, 2021, 08:44:02 pm
content: Lol, wasn't Greg KH one of the supporters of the infamous C.O.C.K. aka the Kernel Code Of Conduct? Something about a welcoming environment for everyone, regardless of education and level of experience (haha), freedom from insults and harassment, blah blah? Well, well, well...

author: bd139
author_rank: Super Contributor
timestamp: April 26, 2021, 09:15:11 pm
content: Yeah that’s the one...Children the lot of them. Then again on the commercial software market it’s no better.

author: Ed.Kloonk
author_rank: Super Contributor
timestamp: April 26, 2021, 09:47:40 pm
content: Funny how it is sometimes implied that GKH could have, within his rights, rejected the K.C.o.C.

author: ataradov
author_rank: Super Contributor
timestamp: April 26, 2021, 10:31:40 pm
content: Yeah, the top developers were bullied into accepting the CoC. It is always a sad day when a project is forced to implement CoC.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.

author: magic
author_rank: Super Contributor
timestamp: April 27, 2021, 05:23:51 am
content: They wouldn't have fired everybody if everybody rejected it. Besides, I'm not just talking tolerating it, but actually walking around and telling everyone it's a good idea. Linus wasn't doing the latter if memory serves me, Greg wasQuote from: ataradov on April 26, 2021, 10:31:40 pmThat's one student who did it.And what can we say about all the developers who publicly accused other students of doing the same, instead of admitting that they are incompetent or lazy fools who failed to notice problems with patches for potential security vulnerabilities submitted by a bunch of kids?Reminder: there is no obligation to be competent when you submit stuff. It's on the team to handle everything you throw at them. They cannot ban you for lack of experience, kernel development background or education, they cannot ban you for mental disability even.

author: ataradov
author_rank: Super Contributor
timestamp: April 27, 2021, 06:48:53 am
content: Quote from: magic on April 27, 2021, 05:23:51 amNothing. 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.Quote from: magic on April 27, 2021, 05:23:51 amYes, but there is moral obligation to submit patches in good faith.Again, bugs get through regularly. This is a known thing. That is unavoidable part of the development process.But submitting the bugs intentionally is a good reason to be banned from ever submitting anything ever again.Some people seem to think that is it possible to detect all errors, manually or automatically. It is not possible in practice. So everyone just has to do their best effort to catch whatever they can. And the reset would be found and debugged later on.

author: magic
author_rank: Super Contributor
timestamp: April 27, 2021, 10:30:58 am
content: It is obvious that we could continue this back and forth about "trust in contributors" vs "security of the process" indefinitely, so I will just stop at the following.Quote from: ataradov on April 27, 2021, 06:48:53 amQuoteQuote from: ataradov on April 27, 2021, 06:48:53 amBased 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.

author: madires
author_rank: Super Contributor
timestamp: April 27, 2021, 01:42:01 pm
content: Quote from: magic on April 27, 2021, 10:30:58 amThe removal of old patches is a security precaution because the re-review of them will take some time. With version control tools you can remove the patches quickly to return to an "untainted" state. My guess is that the good patches will be added again after kernel experts verified them.From my understanding the bad patches didn't add any security issues and were just some nonsense, which is annoying enough to be angry. Additionally to breaking the trust in the university's contributions they also indicate a lack of due diligence of the kernel maintainers regarding security and QA. That process needs to be improved which won't be easy.

author: ataradov
author_rank: Super Contributor
timestamp: April 29, 2021, 08:17:49 pm
content: Well, it looks like the article was withdrawn and will not be presented. And the actual (non-malicious) patches would remain in place after additional review.Although I personally would place a ban on any future contributions, at least for a few years, provided that there is no other way to hold them accountable.

author: Ed.Kloonk
author_rank: Super Contributor
timestamp: April 29, 2021, 08:42:37 pm
content: I suspected the K devs would back down. Oh well. Too bad.

author: tunk
author_rank: Super Contributor
timestamp: April 29, 2021, 08:47:37 pm
content: Letter requesting withdrawal (April 26, 2021):https://www-users.cs.umn.edu/~kjlu/papers/withdrawal-letter.pdfThere's more info on his page, including a letter to the Linux foundation from the department head:https://drive.google.com/file/d/1z3Nm2bfR4tH1nOGBpuOmLyoJVEiO9cUq/viewLooks like the he has been removed from the program committee of IEEE S&P 2022:https://www.ieee-security.org/TC/SP2022/cfpapers.htmlBut this has not been updated on his home page:https://www-users.cs.umn.edu/~kjlu/Code: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.....

author: ataradov
author_rank: Super Contributor
timestamp: April 29, 2021, 08:54:01 pm
content: There is nothing to back down from. Those guys are lucky they did not get into more trouble than this.You don't go to the store and start testing their security by shoplifting stuff. The laws exist against what they did. It is all fun and games until someone goes to jail.

author: bd139
author_rank: Super Contributor
timestamp: April 29, 2021, 09:04:54 pm
content: There's actually no legal consequence here because quite frankly it's not illegal to do this. 18USC1030(a)(5) and (b) as previously mentioned does not apply because the authorization of the code is implicit in the patch acceptance process and they haven't accessed any protected computers. If they introduced a law to cover this, we'd probably have to ban pull requests on github and it would open everyone up to being sued in the sector.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.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.The hole in the fence scares the shit out of me more than the finger pointing game.Whether or not that is a reasonable position to be in from a software sourcing perspective i.e. "should we trust the Linux kernel" is a massive can of compliance and security worms this entire thing has opened which is now on my plate as well."perhaps we should use zOS instead of Linux" is looking like a good option on paper...

author: ataradov
author_rank: Super Contributor
timestamp: April 29, 2021, 09:11:05 pm
content: Quote from: bd139 on April 29, 2021, 09:04:54 pmTheir model matches standard industry practices. You can do this with any other project, open, or closed.Sure, it would be better if that was not possible. It would be better if bugs did not exist at all. But we live in a reality-based world.Quote from: bd139 on April 29, 2021, 09:04:54 pmThis 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.

author: bd139
author_rank: Super Contributor
timestamp: April 29, 2021, 09:22:13 pm
content: It's not. Our legal counsel in the US has actually checked.Also it'd be Computer Trespass under CFAA, not Criminal Trespass as that applies to physical properly only.Realistically it's more a parallel to the point of if someone gave you a car and you accepted it contractually with no warranty, then parked it in your garage and it burned your house down then it's the house owner's mess to deal with not the car's original owner mess (really it's the insurers problem - another side issue to consider!). If they introduced a statutory law to prove causality then there would be no second hand goods because the entire ownership chain of the goods would be responsible for future events. Also every software bug would end in a lawsuit.YMMV but "the law" doesn't cover this as it stands at least in the US and UK.The only tenable issue from this is the chain of trust was proven to be chock full of holes.

author: DrG
author_rank: Super Contributor
timestamp: April 29, 2021, 09:43:40 pm
content: Quote from: ataradov on April 29, 2021, 08:54:01 pmOn the one quoted point, I'm not sure that you can evaluate the trouble they got into since it is not yet complete. Even at this point, how do you think that this "issue" looks to potential employers?

author: bd139
author_rank: Super Contributor
timestamp: April 29, 2021, 09:45:47 pm
content: I'd hire them in a snap. They'd be good for an adversarial security programme.

author: DrG
author_rank: Super Contributor
timestamp: April 29, 2021, 10:35:26 pm
content: Quote from: tunk on April 29, 2021, 08:47:37 pmThanks for these cites. The University letter is the most interesting to me. A couple of things that I see:The Linux folks issued some requests (demands, whatever you want to call them) and that letter is a response.The signatures are Dept head and Deputy Dept. Head - no Deans or higher ups are involved on paper. IOW, they are keeping it at as low a level as possible, which is reasonable in my view.The University did not withdraw the paper. The authors withdrew the paper. This is not to say that some pointed discussions may have taken place. If the authors refused to withdraw the paper, my view is that the University would have done so.The IRB is, in a sense, off the hook. This is what I thought would happen. These folks have roles and charters and in the US, these are pretty close to being standardized and there is CFR around them. Interestingly, this situation may changes some things, at least potentially. These are complicated issues (seehttps://www.hhs.gov/ohrp/regulations-and-policy/regulations/45-cfr-46/index.html).The issue of ethics in research, however is much larger.In my opinion (and only my opinion), is that the Univ seems to be saying that they are going to modfy their procedures to include/expand training and discussion with regard to research ethics. Some will view this as simple CYA and cosmetic attention. Maybe yes, maybe no. Their response in 3 and 4 does not seem, to me, to be weasel words....although I might change my mind at some point.Does this satisfy doing X Y and Z as I mentioned earlier? Yeah, probably.

author: DrG
author_rank: Super Contributor
timestamp: April 29, 2021, 10:37:10 pm
content: Quote from: bd139 on April 29, 2021, 09:45:47 pmMake them an offer, they might be interested.

author: magic
author_rank: Super Contributor
timestamp: April 30, 2021, 06:35:16 am
content: Quote from: ataradov on April 29, 2021, 09:11:05 pmYou are an embedded developer, we get it. You guys are infamous for your level of securityNot everybody enjoys the same luxury, though. Some software needs to has less bugs than industry average and has to face severely adversarial environment, such as just about any network or a multi-user machine for example. I was under impression that OS kernels do belong to this group.I disagree about every other project, open or closed. For starters, you wouldn't even be able to submit patches like that to Windows. And even if you did, say by including them with an email to security@microsoft.com warning about a 0-day you just found, something makes me feel that they would review your fix quite thoroughly before shipping it.And remember, Linux is the guys who used to laugh at Microsoft 10 years ago.It's simply pathetic, there is no excuse.editIt's doubly pathetic because I still have seen no evidence nor admission from the submitters that the patches which actually made it to stable kernelswere malicious. Remember, the deliberately malicious patches have been "outed" by the submitters themselves as soon as they received approval on the mailing list.

author: ataradov
author_rank: Super Contributor
timestamp: April 30, 2021, 06:42:13 am
content: Quote from: magic on April 30, 2021, 06:35:16 amThat 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.Quote from: magic on April 30, 2021, 06:35:16 amDo 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?And even if we say that there are no intentional bugs. Why is Microsoft so bad at developing that their stuff gets hacked all the time? May be we need UoM to write an article how Microsoft needs to do better code reviews before accepting new code? I bet improved CoC would go a long way.Is there any indication that Linux has more bugs than Windows as a result of their "poor" development process?

author: magic
author_rank: Super Contributor
timestamp: April 30, 2021, 06:44:20 am
content: 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

author: ataradov
author_rank: Super Contributor
timestamp: April 30, 2021, 06:49:36 am
content: Linux also has a review in place. Reviews do not catch everything. As I said, this is pretty standard in any practical industry. You can bog everything down in reviews that you will never do anything. And yes, the most secure software is the one that does not exist.And which is juicier is a question for server environment.

author: bd139
author_rank: Super Contributor
timestamp: April 30, 2021, 07:18:21 am
content: Quote from: magic on April 30, 2021, 06:44:20 amWindows being a juicer target is the big deal. If one day it isn’t then it’s game over. There are numerous really bad privsep problems in Linux. A fine example is asking yourself what a compromised Firefox process can access. The answer is anything in your home directory. People make a big deal about that not being a system level compromise but if your data is borked then there’s no point having the system.There is at least proper sandboxing on macOS and windows for that scenario…Server side isn’t much better. I’ve never seen anyone set up nginx properly for example. LXC is slowly fixing that but it’s probably better to subcontract that concern out to amazon and use their product abstractions as your security layering now.

author: magic
author_rank: Super Contributor
timestamp: April 30, 2021, 07:30:23 am
content: No, this whole drama proves that Linux has a rubber stamping process in place, which is not quite the same as review.This seems to be the patch that directly triggered Greg's rage:Code:Subject:  SUNRPC: Add a check for gss_release_msgDate: Tue, 6 Apr 2021 19:16:56 -0500Message-ID: <20210407001658.2208535-1-pakki001@umn.edu> (raw)In gss_pipe_destroy_msg(), in case of error in msg, gss_release_msgdeletes gss_msg. The patch adds a check to avoid a potential doublefree.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.cindex 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);}It's pointless because gss_msg is a refcounted object and you can't double-free it by calling gss_release_msg - that's how they explained the problem on the mailing list.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?

author: ataradov
author_rank: Super Contributor
timestamp: April 30, 2021, 07:35:17 am
content: 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.

author: magic
author_rank: Super Contributor
timestamp: April 30, 2021, 07:38:25 am
content: Lot's of your personal data are handled by Loonix servers AND desktops probably too, just so you know.And as I said, it's not Microsoft who advertises Linux as more secure than Windows because "given enough eyes, all bugs are shallow".

author: bd139
author_rank: Super Contributor
timestamp: April 30, 2021, 07:39:37 am
content: Quote from: ataradov on April 30, 2021, 07:35:17 amThe point is that the process is flawed so why should we trust it.

author: ataradov
author_rank: Super Contributor
timestamp: April 30, 2021, 07:40:20 am
content: Quote from: magic on April 30, 2021, 07:38:25 amWe get it, you hate Linux. Now move on.

author: ataradov
author_rank: Super Contributor
timestamp: April 30, 2021, 07:41:14 am
content: Quote from: bd139 on April 30, 2021, 07:39:37 amYou 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.

author: magic
author_rank: Super Contributor
timestamp: April 30, 2021, 07:42:05 am
content: 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

author: ataradov
author_rank: Super Contributor
timestamp: April 30, 2021, 07:43:52 am
content: Quote from: magic on April 30, 2021, 07:30:23 amThere is nothing wrong with missing it. Admitting to intentionally submitting a buggy code and writing an article about is wrong.At the time of that response it was not known what patches were intentionally buggy and what not. All the non-intentionally buggy patches will be returned to the code.

author: bd139
author_rank: Super Contributor
timestamp: April 30, 2021, 07:45:55 am
content: Quote from: ataradov on April 30, 2021, 07:41:14 amOk I’m going to buy a Mac and start writing zOS stuff

author: bd139
author_rank: Super Contributor
timestamp: April 30, 2021, 07:48:38 am
content: Quote from: magic on April 30, 2021, 07:42:05 amThose dudes were always a joke. I come from a commercial Unix background (Sun) and there’s two types of Unix hippies:1. The traditional bell labs guys. Those guys were engineers through and through despite the lore.2. The rest.The rest are the vocal majority.If you look at the remaining old school engineers they tend to be working on Go and using macs at Google. YMMV but inside with strong engineering not conspicuous moral values.This is why I’ve got a commercial Unix machine on my wrist and in my pocket…

author: Ed.Kloonk
author_rank: Super Contributor
timestamp: May 01, 2021, 07:43:36 pm
content: The cathedral and the bazaar.

author: bd139
author_rank: Super Contributor
timestamp: May 01, 2021, 10:38:30 pm
content: Commercial open source is a winner for me on that basis.Oh lookhttps://opensource.apple.com

author: magic
author_rank: Super Contributor
timestamp: May 02, 2021, 02:05:13 am
content: You have never built anything from those sources.I thought the era of pretending that there is something open source about Darwin has ended decade agoI can't even find launchd anymore, have they migrated to systemd or what