6 ms·

Interesting. The article mentions "spicy discussions" in the kernel mailing list. Is there any insider who can summarize objections and concerns? I tend to a

Interesting. The article mentions "spicy discussions" in the kernel mailing list. Is there any insider who can summarize objections and concerns? I tend to avoid reading the mailing list itself since it can get too spicy, and my headaches are already strong enough! The mechanism itself seems reasonable, but I am surprised that something like this doesn't already exist in the kernel.

ziddoap 2y ago
Not sure if there was much more to it than the thread linked to, but it was basically Linus being Linus. He said stuff that made sense in a pretty blunt fashion. There were flags proposed that allowed the seal to be ignored. >So you say "we can't munmap in this *one* place, but all others ignore the sealing". Later was the spice. >And dammit, once something is sealed, it is SEALED. None of this crazy "one place honors the sealing, random other places do not". And later, even spicier, Linus says that seals cannot be ignored and that is non-negotiable. Any further suggestions to ignore a seal via a flag would result in the person being added to Linus' ignore list. (He, of course, said this with some profanities and capitals sprinkled in.)
- js2 2y ago
  Wasn't just Linus. Earlier, from Theo de Raadt: > I don't think you understand the problem space well enough to come up with your own solution for it. I spent a year on this, and ship a complete system using it. You are asking such simplistic questions above it shocks me. https://lwn.net/ml/linux-kernel/95482.1697587015@cvs.openbsd.org/ https://lwn.net/ml/linux-kernel/95482.1697587015@cvs.openbsd... Via https://lwn.net/Articles/948129/ https://lwn.net/Articles/948129/
  - 0xbadcafebee 2y ago
    Not a great perspective... "It took me a year [or more] to understand this. The fact that you don't understand it shocks me." Dude, not everybody's as smart or experienced as you. Here's an opportunity to be a mentor.
    - nativeit 2y ago
      > Google has no shortage of experienced developers who could have reviewed this submission before it was posted publicly, but that does not appear to have happened, with the result that a relatively inexperienced developer was put into a difficult position. Feedback on the proposal was resisted rather than listened to. The result was an interaction that pleased nobody.
      - refulgentis 2y ago
        > Google has no shortage of experienced developers who could have reviewed this submission before it was posted publicly, You'd be surprised. My understanding from folks on Chrome OS is they've already shedded most, if not all, of the most experienced old hands. (n.b. Chrome OS was absorbed by Android and development is, by and large, ceased on it according to same sources directly, and indirectly via Blind.)
    - vlovich123 2y ago
      My reading of this is a lot more generous to the maintainers and a lot less sympathetic to the author than yours is. The maintainers highlighted the problems and the author came back basically with "I don't believe you so let's go with my approach to stay more general" - it's one thing to disagree, it's another to straight up not acknowledge the feedback. The author ate a lot of very senior people's time arguing instead of listening to them and learning from their experience and that was justifiably frustrating forcing much more direct feedback. The kind of mistake the author made - having to enforce at each individual syscall level instead of it being a protection on the memory itself enforced on all accesses - indicates a poor understanding of how to think about security and build security APIs which is a problem when you're proposing a security API. It's particularly impressive how misguided the patch is given that they took inspiration from the OpenBSD API implementation, changed both API & implementation, & then argued with both Linus and Theo who started Linux & OpenBSD respectively and were trying to give direct feedback about how OpenBSD is different and why it took the approach it did. Hopefully the author has taken the more forceful feedback as a learning opportunity about listening to feedback when the people giving it to you have a lot more experience. Or their team is coaching them about what went wrong now that this became so visible to learn what they got wrong. From Matthew Wilcox who is another senior Linux maintainer: > I concur with Theo & Linus. You don't know what you're doing. I think the underlying idea of mimmutable() is good, but how you've split it up and how you've implemented it is terrible. It's delivered directly and bluntly but it's not mean or personal. The author proposed a bad patch & argued from a position of ignorance.
  - deleted 2y ago
    [deleted]
  - Affric 2y ago
    Thank you. That was beautiful. Demonstrated the difference in design/engineering philosophies from two of the greats.
  - benreesman 2y ago
    You’re asking me how a watch works, let’s just try to keep an eye on the time. https://youtu.be/vkYqs9iuJqY?feature=shared&t=109 https://youtu.be/vkYqs9iuJqY?feature=shared&t=109
- santiagobasulto 2y ago
  Is that considered "spicy"? Is the sensitivity threshold maybe too low?
  - f1shy 2y ago
    Extremely too low. My personal opinion: people who cannot take that kind of criticism, has no place in such a project. Period.
- f1shy 2y ago
  And the reason why SW development sucks in enterprise, is the lack of people that can speak clearly like Linus.
lathiat 2y ago
This may help a bit: https://lwn.net/Articles/948129/ https://lwn.net/Articles/948129/
- ykonstant 2y ago
  Very nice, thanks! Edit: I always find it funny that these articles on the mailing list tend to read like a sports announcer describing a boxing match!
greenavocado 2y ago
https://lwn.net/ml/linux-kernel/7071.1697661373@cvs.openbsd.org/ https://lwn.net/ml/linux-kernel/7071.1697661373@cvs.openbsd.... From: Theo de Raadt <deraadt-AT-openbsd.org> To: Jeff Xu <jeffxu-AT-google.com> > On Wed, Oct 18, 2023 at 8:17 AM Matthew Wilcox <willy@infradead.org> wrote: > > > > Let's start with the purpose. The point of mimmutable/mseal/whatever is > > to fix the mapping of an address range to its underlying object, be it > > a particular file mapping or anonymous memory. After the call succeeds, > > it must not be possible to make any address in that virtual range point > > into any other object. > > > > The secondary purpose is to lock down permissions on that range. > > Possibly to fix them where they are, possibly to allow RW->RO transitions. > > > > With those purposes in mind, you should be able to deduce for any syscall > > or any madvise(), ... whether it should be allowed. > > > I got it. > > IMO: The approaches mimmutable() and mseal() took are different, but > we all want to seal the memory from attackers and make the linux > application safer. I think you are building mseal for chrome, and chrome alone. I do not think this will work out for the rest of the application space because 1) it is too complicated 2) experience with mimmutable() says that applications don't do any of it themselves, it is all in execve(), libc initialization, and ld.so. You don't strike me as an execve, libc, or ld.so developer.
greenavocado 2y ago
From: Matthew Wilcox <willy-AT-infradead.org> To: Jeff Xu <jeffxu-AT-google.com> ... Yes, thank you for demonstrating that you have no idea what you need to block. > It is practical to keep syscall extentable, when the business logic is the same. I concur with Theo & Linus. You don't know what you're doing. I think the underlying idea of mimmutable() is good, but how you've split it up and how you've implemented it is terrible. ...

ziddoap 2y ago

Not sure if there was much more to it than the thread linked to, but it was basically Linus being Linus. He said stuff that made sense in a pretty blunt fashion. There were flags proposed that allowed the seal to be ignored. >So you say "we can't munmap in this *one* place, but all others ignore the sealing". Later was the spice. >And dammit, once something is sealed, it is SEALED. None of this crazy "one place honors the sealing, random other places do not". And later, even spicier, Linus says that seals cannot be ignored and that is non-negotiable. Any further suggestions to ignore a seal via a flag would result in the person being added to Linus' ignore list. (He, of course, said this with some profanities and capitals sprinkled in.)

js2 2y ago
Wasn't just Linus. Earlier, from Theo de Raadt: > I don't think you understand the problem space well enough to come up with your own solution for it. I spent a year on this, and ship a complete system using it. You are asking such simplistic questions above it shocks me. https://lwn.net/ml/linux-kernel/95482.1697587015@cvs.openbsd.org/ https://lwn.net/ml/linux-kernel/95482.1697587015@cvs.openbsd... Via https://lwn.net/Articles/948129/ https://lwn.net/Articles/948129/
- 0xbadcafebee 2y ago
  Not a great perspective... "It took me a year [or more] to understand this. The fact that you don't understand it shocks me." Dude, not everybody's as smart or experienced as you. Here's an opportunity to be a mentor.
  - nativeit 2y ago
    > Google has no shortage of experienced developers who could have reviewed this submission before it was posted publicly, but that does not appear to have happened, with the result that a relatively inexperienced developer was put into a difficult position. Feedback on the proposal was resisted rather than listened to. The result was an interaction that pleased nobody.
    - refulgentis 2y ago
      > Google has no shortage of experienced developers who could have reviewed this submission before it was posted publicly, You'd be surprised. My understanding from folks on Chrome OS is they've already shedded most, if not all, of the most experienced old hands. (n.b. Chrome OS was absorbed by Android and development is, by and large, ceased on it according to same sources directly, and indirectly via Blind.)
  - vlovich123 2y ago
    My reading of this is a lot more generous to the maintainers and a lot less sympathetic to the author than yours is. The maintainers highlighted the problems and the author came back basically with "I don't believe you so let's go with my approach to stay more general" - it's one thing to disagree, it's another to straight up not acknowledge the feedback. The author ate a lot of very senior people's time arguing instead of listening to them and learning from their experience and that was justifiably frustrating forcing much more direct feedback. The kind of mistake the author made - having to enforce at each individual syscall level instead of it being a protection on the memory itself enforced on all accesses - indicates a poor understanding of how to think about security and build security APIs which is a problem when you're proposing a security API. It's particularly impressive how misguided the patch is given that they took inspiration from the OpenBSD API implementation, changed both API & implementation, & then argued with both Linus and Theo who started Linux & OpenBSD respectively and were trying to give direct feedback about how OpenBSD is different and why it took the approach it did. Hopefully the author has taken the more forceful feedback as a learning opportunity about listening to feedback when the people giving it to you have a lot more experience. Or their team is coaching them about what went wrong now that this became so visible to learn what they got wrong. From Matthew Wilcox who is another senior Linux maintainer: > I concur with Theo & Linus. You don't know what you're doing. I think the underlying idea of mimmutable() is good, but how you've split it up and how you've implemented it is terrible. It's delivered directly and bluntly but it's not mean or personal. The author proposed a bad patch & argued from a position of ignorance.
- deleted 2y ago
  [deleted]
- Affric 2y ago
  Thank you. That was beautiful. Demonstrated the difference in design/engineering philosophies from two of the greats.
- benreesman 2y ago
  You’re asking me how a watch works, let’s just try to keep an eye on the time. https://youtu.be/vkYqs9iuJqY?feature=shared&t=109 https://youtu.be/vkYqs9iuJqY?feature=shared&t=109
santiagobasulto 2y ago
Is that considered "spicy"? Is the sensitivity threshold maybe too low?
- f1shy 2y ago
  Extremely too low. My personal opinion: people who cannot take that kind of criticism, has no place in such a project. Period.
f1shy 2y ago
And the reason why SW development sucks in enterprise, is the lack of people that can speak clearly like Linus.

lathiat 2y ago

This may help a bit: https://lwn.net/Articles/948129/ https://lwn.net/Articles/948129/

ykonstant 2y ago
Very nice, thanks! Edit: I always find it funny that these articles on the mailing list tend to read like a sports announcer describing a boxing match!

greenavocado 2y ago

https://lwn.net/ml/linux-kernel/7071.1697661373@cvs.openbsd.org/ https://lwn.net/ml/linux-kernel/7071.1697661373@cvs.openbsd.... From: Theo de Raadt <deraadt-AT-openbsd.org> To: Jeff Xu <jeffxu-AT-google.com> > On Wed, Oct 18, 2023 at 8:17 AM Matthew Wilcox <willy@infradead.org> wrote: > > > > Let's start with the purpose. The point of mimmutable/mseal/whatever is > > to fix the mapping of an address range to its underlying object, be it > > a particular file mapping or anonymous memory. After the call succeeds, > > it must not be possible to make any address in that virtual range point > > into any other object. > > > > The secondary purpose is to lock down permissions on that range. > > Possibly to fix them where they are, possibly to allow RW->RO transitions. > > > > With those purposes in mind, you should be able to deduce for any syscall > > or any madvise(), ... whether it should be allowed. > > > I got it. > > IMO: The approaches mimmutable() and mseal() took are different, but > we all want to seal the memory from attackers and make the linux > application safer. I think you are building mseal for chrome, and chrome alone. I do not think this will work out for the rest of the application space because 1) it is too complicated 2) experience with mimmutable() says that applications don't do any of it themselves, it is all in execve(), libc initialization, and ld.so. You don't strike me as an execve, libc, or ld.so developer.

greenavocado 2y ago

From: Matthew Wilcox <willy-AT-infradead.org> To: Jeff Xu <jeffxu-AT-google.com> ... Yes, thank you for demonstrating that you have no idea what you need to block. > It is practical to keep syscall extentable, when the business logic is the same. I concur with Theo & Linus. You don't know what you're doing. I think the underlying idea of mimmutable() is good, but how you've split it up and how you've implemented it is terrible. ...