The last time I filed a Linux kernel bug report, it was to report that you could plug in a Firewire cable and directly read or write memory, which is a security bug.
But only the first 4GB of memory, because the bug that allowed this was from the 32-bit days. There's are registers which set the upper and lower limits of the accessible area, and they were set for a range of 0..0xffffffff.
Loud complaints from someone who had a debugger which used that exploit. Wasn't fixed.
my understanding is there are so many vulnerabilities when someone has physical device access that the security community essentially suggests you assume any device is compromised if you lost physical access
I use this facility on FreeBSD (dcons) to do debugging. Works great. There's a knob to explicitly turn on DMA, though. It looks like Linux has something similar. Is that not sufficient?
Not a "Linux" issue, but I once had to do a presentation to all developers / testers for a major product.
It's quite important to set clear standards for what is, and isn't, in a bug report. Otherwise, far too much time is spent chasing down information that the reporter (unintentionally) neglected to provide.
It's also important to realize that whoever is fixing a bug isn't responsible for onboarding the submitter in writing a good bug report. That also wastes time.
I think one of the most important responsibilities of a QA dept is to translate user complaints into an actionable bug report.
The systematic erasure of QA from the “modern” development process is pure arrogance and I hope we grow the fuck up before I retire. I’ll take early retirement over continuing as we are.
Error or crash-based telemetry share is actually very efficient way to make valid bug reports. You would be able to catch many hard bugs automatically.
There is a bit of a self-reinforcing effect going on: If I spend the 2-3 hours required to write a good bug report, and I see no indication that any human even looked at that work, I'll be less likely to put that effort in. After a few iterations, my bug reports, if I'm still filing them, are probably going to be quite bad, which isn't going to make it more likely that they'll be picked up...
It's also a great list of why most people will never report bugs, and why many of the people who do come away from the experience unhappy about doing it.
Not really applicable to Linux kernel bugs, but I have a story of it being much harder than one would expect to convince my ISP (a generally cool company, as opposed to some behemoth telecom) that their payment system would allow me to pay them essentially nothing, but their system recorded it as a payment in full.
I pay my ISP using a method where I use an app on my phone to scan a QR code and I can then pay with my credit card (and get associated rewards).
For reasons of maximising my rewards, I decided one month to try split the payment and pay a small part with one credit card, and the remainder with a different one.
I opened the app, scanned the QR code, changed the default payment amount to about 10%. A moment later their system says “Thank you, paid in full!”.
I send customer service an email explaining that there is a flaw in their system which has allowed me to me to underpay.
Them: “Don’t worry, we can see you’ve paid us.”
I reply: “I really haven’t, you need to escalate this to someone technical over there to investigate this further.”
Them: “I can confirm you’ve paid.”
Fortunately for my ISP, I’m a good person and they have a presence on a local forum, I PM’d one of the reps on there who based on their posts was possibly one of the founders.
And he responds saying something to the effect of “thank you very much, I have no idea why customer service didn’t escalate this” and goes on to explain that the payment app evidently did not respect a flag in the QR code which should prevent me from editing the payment amount and he had fixed their code to actually check the incoming amount.
Same rep a few years later was able to resolve unstable Spotify streaming issue I reported by getting Akamai to fix their DNS resolution to use the PoP on my ISPs network as opposed to the one on a different ISPs network which was throttling their peering link.
You mean many don't want to spend time bisecting and building the kernel with proposed fixes to test if they work?
If the bug really bugs them, they'll probably overcome the reluctance to do the above. Not sure if it's many, but it's usually enough in case it's not some obscure component of the kernel but something more widely used like amdgpu for example.
The more obscure the use case though, the worse it gets.
Are there any good guides on compiling the Linux kernel from source and testing it on a VM? Many resources seem to assume that you want to install it next to your existing kernel, but I'd prefer not to risk my filesystem or hardware if something goes wrong.
The easiest thing is just to follow said guide in a VM. Setting up a full system VM is the simpler path since it's such a common tasks that all the VM tooling is already built around the idea you'll want to do that. If you absolutely must compile outside the VM for whatever reason you can just transfer the resulting files over.
It's a bit of a dead end if your kernel issue has to do with your hardware of course. I once had to patch a bug about specific NVMe drives I was working with so there was no choice but to do that with the actual hardware.
Wireguard testsuite comes with a pretty good userland for testing kernel facilities (obviously wireguard itself). It's been integrated in the kernel tree, I can't remember where, but it's great to use for experimentation.
I will fix your bug if I find it interesting. I will fix your bug if you pay me. I will fix your bug if I get assigned it at work, or if I know you personally. Otherwise, fix it yourself. No one owes you anything, and if someone does, they can fix it for you.
I like it when you create bug reports. However submitting a bug report to an open source project is not issuing a work order. If you have any urgency to your bug then you should pay to have it fixed.
However this article is not about open source devs being treated as free labor. This article is all about how to file a good bug report. Having a bug report being politely submitted with all the correct details and in the appropriate channel is a skill many users are lacking. We should really be promoting this sort of document.
The them-and-us mindset on display here is faulty. If you’re reporting a Linux kernel bug, then you are now a Linux kernel developer. Doesn’t matter that your name ain’t in MAINTAINERS or whatever, you still just joined the club. Please add your stone to the cauldron.
Linus never shouted at random people reporting bugs, or anything like that. He occasionally shouted (or still shouts?) at people breaking stuff they really shouldn't have broken, and who really should have known better.
What you think of that is up to you, but the suggestion that Linus is somehow a complete asshole and rude to everyone and everything is just not true, and has never been true.
Besides, "hey, can you help me?" and "I gave you responsibility over this part and you broke stuff for users you numpty" are fundamentally different positions to start with.
The positions of two parties are different, they are not symmetric.
Person who is asking someone else to spend time on his problem should be aware of his tone. Unless bug reporter send report to RedHat or some other company he has business relationship with, it matters.
[+] [-] Animats|1 year ago|reply
Loud complaints from someone who had a debugger which used that exploit. Wasn't fixed.
[+] [-] mushufasa|1 year ago|reply
[+] [-] cwillu|1 year ago|reply
[+] [-] maybeben|1 year ago|reply
[+] [-] ykonstant|1 year ago|reply
[+] [-] Deebster|1 year ago|reply
[+] [-] gwbas1c|1 year ago|reply
It's quite important to set clear standards for what is, and isn't, in a bug report. Otherwise, far too much time is spent chasing down information that the reporter (unintentionally) neglected to provide.
It's also important to realize that whoever is fixing a bug isn't responsible for onboarding the submitter in writing a good bug report. That also wastes time.
[+] [-] hinkley|1 year ago|reply
The systematic erasure of QA from the “modern” development process is pure arrogance and I hope we grow the fuck up before I retire. I’ll take early retirement over continuing as we are.
[+] [-] nicce|1 year ago|reply
But people don't like it for privacy reasons.
[+] [-] mcguire|1 year ago|reply
[+] [-] tgsovlerkhgsel|1 year ago|reply
[+] [-] JohnFen|1 year ago|reply
It's also a great list of why most people will never report bugs, and why many of the people who do come away from the experience unhappy about doing it.
[+] [-] jonathanlydall|1 year ago|reply
I pay my ISP using a method where I use an app on my phone to scan a QR code and I can then pay with my credit card (and get associated rewards).
For reasons of maximising my rewards, I decided one month to try split the payment and pay a small part with one credit card, and the remainder with a different one.
I opened the app, scanned the QR code, changed the default payment amount to about 10%. A moment later their system says “Thank you, paid in full!”.
I send customer service an email explaining that there is a flaw in their system which has allowed me to me to underpay.
Them: “Don’t worry, we can see you’ve paid us.”
I reply: “I really haven’t, you need to escalate this to someone technical over there to investigate this further.”
Them: “I can confirm you’ve paid.”
Fortunately for my ISP, I’m a good person and they have a presence on a local forum, I PM’d one of the reps on there who based on their posts was possibly one of the founders.
And he responds saying something to the effect of “thank you very much, I have no idea why customer service didn’t escalate this” and goes on to explain that the payment app evidently did not respect a flag in the QR code which should prevent me from editing the payment amount and he had fixed their code to actually check the incoming amount.
Same rep a few years later was able to resolve unstable Spotify streaming issue I reported by getting Akamai to fix their DNS resolution to use the PoP on my ISPs network as opposed to the one on a different ISPs network which was throttling their peering link.
[+] [-] shmerl|1 year ago|reply
If the bug really bugs them, they'll probably overcome the reluctance to do the above. Not sure if it's many, but it's usually enough in case it's not some obscure component of the kernel but something more widely used like amdgpu for example.
The more obscure the use case though, the worse it gets.
[+] [-] unknown|1 year ago|reply
[deleted]
[+] [-] adamc|1 year ago|reply
[+] [-] LegionMammal978|1 year ago|reply
[+] [-] zamadatix|1 year ago|reply
It's a bit of a dead end if your kernel issue has to do with your hardware of course. I once had to patch a bug about specific NVMe drives I was working with so there was no choice but to do that with the actual hardware.
[+] [-] rwmj|1 year ago|reply
[+] [-] ndesaulniers|1 year ago|reply
https://github.com/ClangBuiltLinux/boot-utils
https://docs.kernel.org/kbuild/llvm.html
[+] [-] commandersaki|1 year ago|reply
[+] [-] exe34|1 year ago|reply
[+] [-] OsrsNeedsf2P|1 year ago|reply
[+] [-] gamepsys|1 year ago|reply
However this article is not about open source devs being treated as free labor. This article is all about how to file a good bug report. Having a bug report being politely submitted with all the correct details and in the appropriate channel is a skill many users are lacking. We should really be promoting this sort of document.
[+] [-] jmclnx|1 year ago|reply
* Fixing the bug will not add value to the various Fortune 500 Companies that control Linux.
[+] [-] brcmthrowaway|1 year ago|reply
[+] [-] sobkas|1 year ago|reply
[+] [-] inopinatus|1 year ago|reply
[+] [-] unknown|1 year ago|reply
[deleted]
[+] [-] hinkley|1 year ago|reply
That a group that contains Linus Torvalds is policing tone is hilariously tone deaf.
[+] [-] arp242|1 year ago|reply
What you think of that is up to you, but the suggestion that Linus is somehow a complete asshole and rude to everyone and everything is just not true, and has never been true.
Besides, "hey, can you help me?" and "I gave you responsibility over this part and you broke stuff for users you numpty" are fundamentally different positions to start with.
[+] [-] moomin|1 year ago|reply
[+] [-] mnau|1 year ago|reply
Person who is asking someone else to spend time on his problem should be aware of his tone. Unless bug reporter send report to RedHat or some other company he has business relationship with, it matters.