GNU social JP
  • FAQ
  • Login
GNU social JPは日本のGNU socialサーバーです。
Usage/ToS/admin/test/Pleroma FE

  • Public

    • Public
    • Network
    • Groups
    • Featured
    • Popular
    • People

Notices by Greg K-H (gregkh@social.kernel.org)

  1. Embed this notice
    Greg K-H (gregkh@social.kernel.org)'s status on Sunday, 17-Nov-2024 02:27:50 JST Greg K-H Greg K-H
    in reply to
    • Gustavo A. R. Silva :tux:
    @gustavoars I'm not even going to try :)
    In conversation about 5 days ago from social.kernel.org permalink
  2. Embed this notice
    Greg K-H (gregkh@social.kernel.org)'s status on Sunday, 17-Nov-2024 02:03:36 JST Greg K-H Greg K-H

    {sigh} Go home CodeQL, you are drunk…

    int main(int argc, char *argv[]) Poorly documented function: fewer than 2% comments for a function of 129 lines.

    Code in question is at: https://github.com/gregkh/usbutils/blob/master/lsusb.c#L3835 if people are curious. It’s as if the tool hasn’t seen C code before…

    In conversation about 5 days ago from social.kernel.org permalink

    Attachments

    1. Domain not in remote thumbnail source whitelist: opengraph.githubassets.com
      usbutils/lsusb.c at master · gregkh/usbutils
      USB utilities for Linux, including lsusb. Contribute to gregkh/usbutils development by creating an account on GitHub.
  3. Embed this notice
    Greg K-H (gregkh@social.kernel.org)'s status on Saturday, 16-Nov-2024 23:59:27 JST Greg K-H Greg K-H
    in reply to
    • Greg K-H
    • Emil Velikov
    To followup up on this, @xexaxo sent a pull request to get rid of these "code in the meson temp files are security issues" false-warnings: https://github.com/gregkh/usbutils/pull/211

    Many thanks for this, now to whittle down the other pointless `switch case is too big` and `FIXME is left in a comment` warnings that are left so that if anything "real" ever shows up, it will actually be noticed...
    In conversation about 5 days ago from social.kernel.org permalink

    Attachments

    1. Domain not in remote thumbnail source whitelist: opengraph.githubassets.com
      ci: codeql ignore meson generated files, et al by evelikov · Pull Request #211 · gregkh/usbutils
      Hey Greg, here's a quick PR to silence most of the CodeQL dubious reports. I've also added a couple more CI commits just to keep you on your toes ;-)
  4. Embed this notice
    Greg K-H (gregkh@social.kernel.org)'s status on Saturday, 16-Nov-2024 19:47:44 JST Greg K-H Greg K-H
    in reply to
    • Emil Velikov
    @xexaxo Yes, thank you! And thanks for the PR, I'll go merge that now and see how it goes.
    In conversation about 6 days ago from social.kernel.org permalink
  5. Embed this notice
    Greg K-H (gregkh@social.kernel.org)'s status on Saturday, 16-Nov-2024 17:47:04 JST Greg K-H Greg K-H
    in reply to
    • Greg K-H
    • tbodt
    @tbodt Nope, didn't work. Or I got the yaml wrong, which is probably the real reason here...
    In conversation about 6 days ago from social.kernel.org permalink
  6. Embed this notice
    Greg K-H (gregkh@social.kernel.org)'s status on Saturday, 16-Nov-2024 17:38:31 JST Greg K-H Greg K-H
    in reply to
    • tbodt
    @tbodt Oh, nice, let me attempt that...
    In conversation about 6 days ago from social.kernel.org permalink
  7. Embed this notice
    Greg K-H (gregkh@social.kernel.org)'s status on Saturday, 16-Nov-2024 17:38:20 JST Greg K-H Greg K-H
    in reply to
    • tbodt
    @tbodt codeql really wants to build the code, as I'm guessing it is doing so with a compiler hack to get at the files needed to analyze. I guess we can turn that off, let me try that out...
    In conversation about 6 days ago from social.kernel.org permalink
  8. Embed this notice
    Greg K-H (gregkh@social.kernel.org)'s status on Saturday, 16-Nov-2024 16:49:19 JST Greg K-H Greg K-H
    in reply to
    • Adolph
    • tbodt
    @tbodt @captainepoch Yes, enabling it is good. Stupid tests claiming problems that are not actually present at all are not good.

    Drowns out any potential real issues.
    In conversation about 6 days ago from social.kernel.org permalink
  9. Embed this notice
    Greg K-H (gregkh@social.kernel.org)'s status on Saturday, 16-Nov-2024 16:48:05 JST Greg K-H Greg K-H
    in reply to
    • Greg K-H

    As it turns out that “code scanning” isn’t public, here’s the error message that github is putting up saying that meson temp build files are security problems:

    build/meson-private/tmpzhj7u8eq/testfile.c:2 Test Poor global variable name 'i'. Prefer longer, descriptive names for globals (eg. kMyGlobalConstant, not foo). Rule ID cpp/short-global-name Description This rule finds global variables which have a name of length three characters or less. It is particularly important to use descriptive names for global variables. Use of a clear naming convention for global variables helps document their use, avoids pollution of the namespace and reduces the risk of shadowing with local variables.
    In conversation about 6 days ago from social.kernel.org permalink
  10. Embed this notice
    Greg K-H (gregkh@social.kernel.org)'s status on Saturday, 16-Nov-2024 16:45:54 JST Greg K-H Greg K-H
    • Adolph
    @captainepoch Ok, sorry about that. I'll respond to the original with the full error message...
    In conversation about 6 days ago from social.kernel.org permalink
  11. Embed this notice
    Greg K-H (gregkh@social.kernel.org)'s status on Saturday, 16-Nov-2024 16:41:48 JST Greg K-H Greg K-H
    • Adolph
    @captainepoch Odd, works for me!

    How about this https://github.com/gregkh/usbutils/security/code-scanning

    And it's obviously picking up the temp files that meson uses for "does this compiler have this feature" but that's temp files, and not actually in the repo itself. Surely tools like meson are handled properly, right?
    In conversation about 6 days ago from social.kernel.org permalink

    Attachments


  12. Embed this notice
    Greg K-H (gregkh@social.kernel.org)'s status on Saturday, 16-Nov-2024 16:38:42 JST Greg K-H Greg K-H
    Dear lazyweb,

    For the usbutils project, developers have helpfully set up a bunch of github actions to help with build tests and the like, and it also includes github's "security scanning" toolsets. Unfortunately the output of such tools is pretty useless and unhelpful to a fault.

    Example, this "result": https://github.com/gregkh/usbutils/security/code-scanning/2291
    which claims "short global name" yet there is no such actual global variable `i` in the codebase at all.

    Because of stuff like this, the tools "claim" there are 63 "security" issues in the usbutils project. Since when did using single character names become a security issue, even if we were doing that, but ok...

    So, how to turn this off, or better yet, fix the test to not report issues that are actually in the tests themselves?
    In conversation about 6 days ago from social.kernel.org permalink

    Attachments


  13. Embed this notice
    Greg K-H (gregkh@social.kernel.org)'s status on Thursday, 14-Nov-2024 17:07:23 JST Greg K-H Greg K-H
    in reply to
    • Thorsten Leemhuis (acct. 1/4)
    • mxk
    @kernellogger @mxk Totally understand.

    Here's a link to Todd's latest Plumbers conference calling out how they are going to support devices for 7+ years by moving to new kernel versions over time: https://lpc.events/event/18/contributions/1703/attachments/1391/2998/LPC%202024%20-%20Android%20Device%20Longevity.pdf
    In conversation about 8 days ago from social.kernel.org permalink

    Attachments


  14. Embed this notice
    Greg K-H (gregkh@social.kernel.org)'s status on Thursday, 14-Nov-2024 17:02:04 JST Greg K-H Greg K-H
    in reply to
    • Thorsten Leemhuis (acct. 1/4)
    • mxk
    @kernellogger @mxk That's not how Android kernels are working anymore. Vendors can have huge numbers of external kernel drivers/modules (i.e. pixel 6 has 300+ of them), but the "core" kernel is managed by Android/Google, in public, in their GKI kernel branches, and that is what is the "base" of the kernel that all vendors can then add drivers to.

    If a vendor wants to change the "core" parts of the kernel, they must either submit the changes upstream for merging first (and then backport the change to the GKI kernel and submit it to Android), or somehow convince Android to take it into their GKI kernel (with reasons why upstream rejected it), or add a "hook" to the GKI kernel so that they can put their changes in a kernel module (like many do for scheduler changes.)

    The -lts releases get merged into the Android/GKI kernel branches on a monthly basis, which then gets pushed out to all devices "quickly" as there are no in-kernel-abi breaks between the GKI kernel and all external kernel modules used by vendors.

    Android has followed the "old" enterprise kernel module here, with the exception of the hook additions, that companies have used for decades (the abi stability changes were taken directly from RHEL and SLES). It's not exciting kernel work, but allows security fixes to get pushed out to devices MUCH faster which is helping everyone out, AND it has forced the vendors to work upstream to get their features merged properly, which has been happening for years now to much success.

    There was a plumbers talk all about this this year (and last, and the year before), if you want more details.
    In conversation about 8 days ago from social.kernel.org permalink
  15. Embed this notice
    Greg K-H (gregkh@social.kernel.org)'s status on Saturday, 05-Oct-2024 18:23:44 JST Greg K-H Greg K-H
    @hikari What firmware blobs? The old ones were all in text format anyway (arrays of bytes in a .c or .h file), so that's never really been an issue. I think they are almost all gone from the tree now so that shouldn't be an issue.

    For the linux-firmware project, you can send binary diffs to them, in email, git handles that just fine. You aren't reviewing a binary file anyway, it's either you take it or you don't.
    In conversation about 2 months ago from social.kernel.org permalink
  16. Embed this notice
    Greg K-H (gregkh@social.kernel.org)'s status on Sunday, 22-Sep-2024 15:35:05 JST Greg K-H Greg K-H
    in reply to
    • uis
    @uis oooh, nice, and the documentation for it says it is for something like "a system call in an operating system". Odd, who added it to the compiler and why didn't they talk to any kernel developers about it if this feature is supposed to be for us?

    Is there a different operating system out there that uses newer versions of gcc as their primary compiler that is using this?

    That being said, it's a good start, and will require us to use -fanalyzer which I think people are working toward, so maybe there is hope!
    In conversation about 2 months ago from gnusocial.jp permalink
  17. Embed this notice
    Greg K-H (gregkh@social.kernel.org)'s status on Saturday, 14-Sep-2024 16:42:39 JST Greg K-H Greg K-H
    in reply to
    • Greg K-H
    In the same topic of "use frameworks to make bugs very hard to create", Alice Ryhl's patches for using a "range" api to access data from userspace:

    https://lore.kernel.org/r/20240913210031.20802-1-aliceryhl@google.com

    along with examples of how recent binder bugs were affected by this issue in C, and also were present in the Rust implementation, along with a proposal for how to prevent that are another good example of how the language can help us in kernel land by creating apis to help us do the right thing.
    In conversation about 2 months ago from social.kernel.org permalink

    Attachments

    1. No result found on File_thumbnail lookup.
      [PATCH 1/2] rust: harden index manipulation using ownership - Alice Ryhl
  18. Embed this notice
    Greg K-H (gregkh@social.kernel.org)'s status on Saturday, 14-Sep-2024 10:48:26 JST Greg K-H Greg K-H
    This "untrusted data" patch series from Benno Lossin is the result of conversations at last weekend's Rust Linux kernel conference in Copenhagen:

    https://lore.kernel.org/all/20240913112643.542914-1-benno.lossin@proton.me/

    It's not a "silver bullet" for why we should be using rust in the Linux kernel, but it is a "big giant sledgehammer" to help squash and prevent from happening MANY common types of kernel vulnerabilities and bugs (remember, "all input is evil!" and this change forces you to always be aware of that, which is something that C in the kernel does not.)

    I had always felt that Rust was the future for what we need to do in Linux, but now I'm sure, because if we can do stuff like this, with no overhead involved (it's all checked at build time), then we would be foolish not to give it a real try.

    And yes, I've asked for this for years from the C developers, and maybe we can also do it there, but it's not obvious how and no one has come up with a way to do so. Maybe now they will have some more incentive :)
    In conversation about 2 months ago from social.kernel.org permalink

    Attachments

    1. No result found on File_thumbnail lookup.
      [PATCH 0/3] Untrusted data abstraction - Benno Lossin
  19. Embed this notice
    Greg K-H (gregkh@social.kernel.org)'s status on Saturday, 14-Sep-2024 10:48:25 JST Greg K-H Greg K-H
    in reply to
    • Aho
    @aho Others have done research on how long it would take to reimplement code bases based on their size and importance, see that research for details.

    In short, it's not going to happen, and no one is asking for it to happen. Just evolve like normally and all will be fine. The Linux kernel you run today has almost no code that was in the kernel you used 25 years ago, so why would it have the same code you use 25 years from now?

    Except for the tty layer, that beast is almost identical to what was around in the beginning, and probably will outlive us all...
    In conversation about 2 months ago from social.kernel.org permalink
  20. Embed this notice
    Greg K-H (gregkh@social.kernel.org)'s status on Wednesday, 11-Sep-2024 15:18:53 JST Greg K-H Greg K-H
    in reply to
    • 🐧sima🐧
    @sima Right after this happened, I went and checked the LDD3 book, and yes it says this in the chapter about memory:

    (internally performed by calling, eventually, __get_free_pages, which is the source of the GFP_ prefix))

    So I have no excuse for not remembering this either...
    In conversation about 2 months ago from social.kernel.org permalink
  • Before

User actions

    Greg K-H

    Greg K-H

    Tags
    • (None)

    Following 0

      Followers 1

      • Alexandre Oliva

      Groups 0

        Statistics

        User ID
        101452
        Member since
        24 Feb 2023
        Notices
        63
        Daily average
        0

        Feeds

        • Atom
        • Help
        • About
        • FAQ
        • TOS
        • Privacy
        • Source
        • Version
        • Contact

        GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.

        Creative Commons Attribution 3.0 All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.