Re: HEADS-UP: PIE enabled by default on main
On Sun, Feb 28, 2021 at 09:40:54AM -0500, Shawn Webb wrote: > ... The point of ASLR is to combine it with W^X. Without W^X, ASLR makes > no sense. FreeBSD recently gained a W^X implementation that requires > opt-in. ... I'm not plugged into the right places to catch some of these things up front. Like PIE, I trip across how to enable them after the fact by finding people talking about it here. My google-fu is getting a lot of bad hits, but I assume this is referring to making writable memory non-executable (above and beyond malloc()'s M_EXEC flag with it's disclaimers). What are the keyword/feature/knobs to get better informed and opt-in? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS-UP: PIE enabled by default on main
On Sat, Feb 27, 2021 at 08:34:11PM -0800, Ihor Antonov wrote: > > > > But isn't it well-known that ASLR/ASR/any-related-buzzwork does not add > > any security, except imaginary? The only purpose of it is to have a > > check-list item ticked green. > > I don't know if I should parse this as sarcasm (or any other form of > "humor") or is a serious statement? But this does leave me with a whole > bunch of questions.. > > If this is really how Konstantin is describing it then is it OK to say > about this to the whole Internet? Why FreeBSD Foundation is paying for > meaningless work then? Why members of the Core team do this work? Does > this mean that FreeBSD is working to satisfy the silly needs of some fat > customer? What about project independence and not being controlled by > big money? What fat customer? Other than that (and tone, of course), you formulate right the core of the issue. ASLR is useless as a stop-gap measure, exploits work around it with full success since XP SP3, but the myth about its importance is so widely circulating that we have to spend a lot of efforts first developing the feature, and then similar amount of efforts to productize it. The later means to make it available to general public without introducing a breakage. We tried to do as you said, not implement but explain, you see the attempts to list research papers below the thread. It does not work. This is the case where security theater wins. In fact, switch to PIE itself is somewhat useful. For instance, - rtld direct execution mode benefits from it - kernel image activator might optimize/compact address space - emulation tools like valgrind have more freedom loading the image as well, - static linkers can do some optimizations only possible for DSO-like and not binary and so on. But I would never call it a 'huge security advance'. > > Where can I read about ASLR and security myths? > Why not spend time and explain why this does not work? Because spending time explaining why it does not work does not work. People read check-lists and not explanations, esp. if check-lists are provided by somebody not interested in explanation, but to pursue a red/green line in the check-list. And I do not even start on the quality of the 'alternative' implementations. > > > > You clearly should mean something useful and much more important than that, > > when stating that FreeBSD made a huge step forward. So I want to be aware > > of the advance. > > Why attack a person who was really happy for the project? > This DOES sound a agressive, even for a sarcastic joke.. > I am saying this someone who shares the same native language with Mr. > Belousov, > it is not a "language/culture" difference thing. I do not see how supposed sharing of native language with me makes it legitimate to express your emotions as mine statements. > > - > just your regular user who reads mailing list ocassionally > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS-UP: PIE enabled by default on main
On Sat, Feb 27, 2021 at 10:29:14PM -0700, Warner Losh wrote: > On Sat, Feb 27, 2021 at 9:34 PM Ihor Antonov wrote: > > > > > > > But isn't it well-known that ASLR/ASR/any-related-buzzwork does not add > > > any security, except imaginary? The only purpose of it is to have a > > > check-list item ticked green. > > > > I don't know if I should parse this as sarcasm (or any other form of > > "humor") or is a serious statement? But this does leave me with a whole > > bunch of questions.. > > > > If this is really how Konstantin is describing it then is it OK to say > > about this to the whole Internet? Why FreeBSD Foundation is paying for > > meaningless work then? Why members of the Core team do this work? Does > > this mean that FreeBSD is working to satisfy the silly needs of some fat > > customer? What about project independence and not being controlled by > > big money? > > > > Where can I read about ASLR and security myths? > > Why not spend time and explain why this does not work? > > > > Not to rise to the baitiness of all these leading questions (they really > are quite contrary to how our community usually comports itself, but for > the sake of civil discourse, I'll ignore) > > I'll bet it has something to do with the many known ASLR attacks. One is > chronicled in https://www.vusec.net/projects/anc/ and elsewhere, which show > how MMU side channels can defeat ASLR. Or maybe he's familiar with the > offset2lib attack against Linux 64-bit ASLR documented in this paper > https://cybersecurity.upv.es/attacks/offset2lib/offset2lib-paper.pdf. > There's many others as well that show the shortcomings of ASLR and disclose > ways to defeat it using various clever means. Problem with these papers is that they put ASLR on a pedestal it doesn't deserve. If you take a look at PaX's original ASLR paper, you'll learn that ASLR was not designed to protect against local attacks. You'll also learn that the infoleak weakness was already postulated, even in its initial design and implementation. Attacks against the MMU require local code execution--for example, javascript in a browser. ASLR was never meant to protect against such a case. We must take the original design into account when discussing ASLR's valid shortcomings. The point of ASLR is to combine it with W^X. Without W^X, ASLR makes no sense. FreeBSD recently gained a W^X implementation that requires opt-in. When combined with W^X, exploit authors must chain together multiple vulnerabilities in order to successfully exploit. The combination of ASLR and W^X have forever changed the very foundation of exploitation. Both, when combined, do their job well--that of raising the economic cost of successful remote exploitation. Now that FreeBSD has both a form of ASLR known as ASR and a W^X implementation, FreeBSD can move on to other exploit mitigations, such as CFI and SafeStack (both of which are already integrated in some form in HardenedBSD.) This is likely to be my only response to this thread as I'm incredibly tired of rehashing the same arguments, especiall with regards to kib@, over the span of many years. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: HEADS-UP: PIE enabled by default on main
> On 28. Feb 2021, at 13:27, dmilith . wrote: > > First of all - ALSR is designed as mitigation for external attacks, > not internal ones (logged in user). > Second - Linux and FreeBSD both have weak implementations in > comparison to PAX-driven ones. Try attacking the system with > Grsecurity or HardenedBSD (both use the strongest ASLR available > AFAIK). > > Saying that security mitigation features that affect no performance > are "meaningless", is just ridiculous or at least just irresponsible. > It's like telling C programmers that stack protection or out of bounds > checks are bad, cause there's nothing wrong with random SEGFAULTS from > time to time… > You seem to forget that those mechanisms are there exactly because programmers are not caring about random faults from time to time:D With correct code, one would not need mechanisms like ALSR. rgds, toomas > > On 28/02/2021, Ihor Antonov wrote: >> On 2021-02-27 22:29, Warner Losh wrote: >>> On Sat, Feb 27, 2021 at 9:34 PM Ihor Antonov >>> wrote: >>> > > But isn't it well-known that ASLR/ASR/any-related-buzzwork does not > add > any security, except imaginary? The only purpose of it is to have a > check-list item ticked green. I don't know if I should parse this as sarcasm (or any other form of "humor") or is a serious statement? But this does leave me with a whole bunch of questions.. If this is really how Konstantin is describing it then is it OK to say about this to the whole Internet? Why FreeBSD Foundation is paying for meaningless work then? Why members of the Core team do this work? Does this mean that FreeBSD is working to satisfy the silly needs of some fat customer? What about project independence and not being controlled by big money? Where can I read about ASLR and security myths? >>> >>> Why not spend time and explain why this does not work? >>> >>> Not to rise to the baitiness of all these leading questions (they really >>> are quite contrary to how our community usually comports itself, but for >>> the sake of civil discourse, I'll ignore) >>> >>> I'll bet it has something to do with the many known ASLR attacks. One is >>> chronicled in https://www.vusec.net/projects/anc/ and elsewhere, which >>> show >>> how MMU side channels can defeat ASLR. Or maybe he's familiar with the >>> offset2lib attack against Linux 64-bit ASLR documented in this paper >>> https://cybersecurity.upv.es/attacks/offset2lib/offset2lib-paper.pdf. >>> There's many others as well that show the shortcomings of ASLR and >>> disclose >>> ways to defeat it using various clever means. >> >> Warner, thanks for the links. They are indeed interesting. >> You clearly should mean something useful and much more important than that, >>> >>> Maybe he'd like to understand how PIE accomplishes better security give >>> the >>> known ASLR weaknesses. And rather than take a sarcastic tone, he asked >>> for >>> more details that back up the earlier claims of improved security so we >>> could all learn something. >> >> The conclusion of the paper in the second link clearly says: >> >>We present a new weakness on the current implementationof the ASLR >>Linux systems which affects PIE compiled ex-ecutables. Applications >>compiled with PIE are consideredto be more robust since it makes >>attacks more difficult. >> >> Which I read as ASLR and PIE work better together. This is the same what >> Gordon was saying. >> >> The whole situation is wrong on 2 different levels. >> >> First: saying that ASLR is not perfect and can be broken is not the same >> thing as saying "The only purpose of it is to have a check-list item ticked >> green" >> >> There are no perfect security measures, and you guys (kernel and OS >> developers) should know that better than us (users). Hackers find new >> exploits, developers find ways to mitigate them and cycle repeats. Just >> the fact that ASLR can be broken is not the reason to not have it. >> >> Second: look at this exchange from a distance >> >> Ed: we are enabling security feature X, please rebuild your worlds.. >> Godron: great progress! go team! >> Konstantin: why do you think this is great progress? (implying it is >> not) >> Gordon: well, I heard feature X works best with feature Y >> Konstantin: feature Y is useless checkbox, next time you speak make sure >> you say something useful! >> >> Considering the fact that Konstantin himself worked on ASLR this is at >> least confusing.. Also does this also mean that feature X (PIE) is also >> useless checkbox? >> >> Konstantin, Ed, Warner - I dunno what is going on in your house (Core) but >> it does not look good form the outside. You are sending mixed signals to >> your auditory. >> >> >> ___ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >>
Re: HEADS-UP: PIE enabled by default on main
First of all - ALSR is designed as mitigation for external attacks, not internal ones (logged in user). Second - Linux and FreeBSD both have weak implementations in comparison to PAX-driven ones. Try attacking the system with Grsecurity or HardenedBSD (both use the strongest ASLR available AFAIK). Saying that security mitigation features that affect no performance are "meaningless", is just ridiculous or at least just irresponsible. It's like telling C programmers that stack protection or out of bounds checks are bad, cause there's nothing wrong with random SEGFAULTS from time to time… On 28/02/2021, Ihor Antonov wrote: > On 2021-02-27 22:29, Warner Losh wrote: >> On Sat, Feb 27, 2021 at 9:34 PM Ihor Antonov >> wrote: >> >> > > >> > > But isn't it well-known that ASLR/ASR/any-related-buzzwork does not >> > > add >> > > any security, except imaginary? The only purpose of it is to have a >> > > check-list item ticked green. >> > >> > I don't know if I should parse this as sarcasm (or any other form of >> > "humor") or is a serious statement? But this does leave me with a whole >> > bunch of questions.. >> > >> > If this is really how Konstantin is describing it then is it OK to say >> > about this to the whole Internet? Why FreeBSD Foundation is paying for >> > meaningless work then? Why members of the Core team do this work? Does >> > this mean that FreeBSD is working to satisfy the silly needs of some >> > fat >> > customer? What about project independence and not being controlled by >> > big money? >> > >> > Where can I read about ASLR and security myths? >> >> Why not spend time and explain why this does not work? >> > >> >> Not to rise to the baitiness of all these leading questions (they really >> are quite contrary to how our community usually comports itself, but for >> the sake of civil discourse, I'll ignore) >> >> I'll bet it has something to do with the many known ASLR attacks. One is >> chronicled in https://www.vusec.net/projects/anc/ and elsewhere, which >> show >> how MMU side channels can defeat ASLR. Or maybe he's familiar with the >> offset2lib attack against Linux 64-bit ASLR documented in this paper >> https://cybersecurity.upv.es/attacks/offset2lib/offset2lib-paper.pdf. >> There's many others as well that show the shortcomings of ASLR and >> disclose >> ways to defeat it using various clever means. > > Warner, thanks for the links. They are indeed interesting. > >> > You clearly should mean something useful and much more important than >> > that, >> >> Maybe he'd like to understand how PIE accomplishes better security give >> the >> known ASLR weaknesses. And rather than take a sarcastic tone, he asked >> for >> more details that back up the earlier claims of improved security so we >> could all learn something. > > The conclusion of the paper in the second link clearly says: > > We present a new weakness on the current implementationof the ASLR > Linux systems which affects PIE compiled ex-ecutables. Applications > compiled with PIE are consideredto be more robust since it makes > attacks more difficult. > > Which I read as ASLR and PIE work better together. This is the same what > Gordon was saying. > > The whole situation is wrong on 2 different levels. > > First: saying that ASLR is not perfect and can be broken is not the same > thing as saying "The only purpose of it is to have a check-list item ticked > green" > > There are no perfect security measures, and you guys (kernel and OS > developers) should know that better than us (users). Hackers find new > exploits, developers find ways to mitigate them and cycle repeats. Just > the fact that ASLR can be broken is not the reason to not have it. > > Second: look at this exchange from a distance > > Ed: we are enabling security feature X, please rebuild your worlds.. > Godron: great progress! go team! > Konstantin: why do you think this is great progress? (implying it is > not) > Gordon: well, I heard feature X works best with feature Y > Konstantin: feature Y is useless checkbox, next time you speak make sure > you say something useful! > > Considering the fact that Konstantin himself worked on ASLR this is at > least confusing.. Also does this also mean that feature X (PIE) is also > useless checkbox? > > Konstantin, Ed, Warner - I dunno what is going on in your house (Core) but > it does not look good form the outside. You are sending mixed signals to > your auditory. > > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > -- -- Daniel Dettlaff Versatile Knowledge Systems verknowsys.com ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS-UP: PIE enabled by default on main
On 2021-02-27 22:29, Warner Losh wrote: > On Sat, Feb 27, 2021 at 9:34 PM Ihor Antonov wrote: > > > > > > > But isn't it well-known that ASLR/ASR/any-related-buzzwork does not add > > > any security, except imaginary? The only purpose of it is to have a > > > check-list item ticked green. > > > > I don't know if I should parse this as sarcasm (or any other form of > > "humor") or is a serious statement? But this does leave me with a whole > > bunch of questions.. > > > > If this is really how Konstantin is describing it then is it OK to say > > about this to the whole Internet? Why FreeBSD Foundation is paying for > > meaningless work then? Why members of the Core team do this work? Does > > this mean that FreeBSD is working to satisfy the silly needs of some fat > > customer? What about project independence and not being controlled by > > big money? > > > > Where can I read about ASLR and security myths? > > Why not spend time and explain why this does not work? > > > > Not to rise to the baitiness of all these leading questions (they really > are quite contrary to how our community usually comports itself, but for > the sake of civil discourse, I'll ignore) > > I'll bet it has something to do with the many known ASLR attacks. One is > chronicled in https://www.vusec.net/projects/anc/ and elsewhere, which show > how MMU side channels can defeat ASLR. Or maybe he's familiar with the > offset2lib attack against Linux 64-bit ASLR documented in this paper > https://cybersecurity.upv.es/attacks/offset2lib/offset2lib-paper.pdf. > There's many others as well that show the shortcomings of ASLR and disclose > ways to defeat it using various clever means. Warner, thanks for the links. They are indeed interesting. > > You clearly should mean something useful and much more important than > > that, > > Maybe he'd like to understand how PIE accomplishes better security give the > known ASLR weaknesses. And rather than take a sarcastic tone, he asked for > more details that back up the earlier claims of improved security so we > could all learn something. The conclusion of the paper in the second link clearly says: We present a new weakness on the current implementationof the ASLR Linux systems which affects PIE compiled ex-ecutables. Applications compiled with PIE are consideredto be more robust since it makes attacks more difficult. Which I read as ASLR and PIE work better together. This is the same what Gordon was saying. The whole situation is wrong on 2 different levels. First: saying that ASLR is not perfect and can be broken is not the same thing as saying "The only purpose of it is to have a check-list item ticked green" There are no perfect security measures, and you guys (kernel and OS developers) should know that better than us (users). Hackers find new exploits, developers find ways to mitigate them and cycle repeats. Just the fact that ASLR can be broken is not the reason to not have it. Second: look at this exchange from a distance Ed: we are enabling security feature X, please rebuild your worlds.. Godron: great progress! go team! Konstantin: why do you think this is great progress? (implying it is not) Gordon: well, I heard feature X works best with feature Y Konstantin: feature Y is useless checkbox, next time you speak make sure you say something useful! Considering the fact that Konstantin himself worked on ASLR this is at least confusing.. Also does this also mean that feature X (PIE) is also useless checkbox? Konstantin, Ed, Warner - I dunno what is going on in your house (Core) but it does not look good form the outside. You are sending mixed signals to your auditory. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS-UP: PIE enabled by default on main
On Sat, Feb 27, 2021 at 9:34 PM Ihor Antonov wrote: > > > > But isn't it well-known that ASLR/ASR/any-related-buzzwork does not add > > any security, except imaginary? The only purpose of it is to have a > > check-list item ticked green. > > I don't know if I should parse this as sarcasm (or any other form of > "humor") or is a serious statement? But this does leave me with a whole > bunch of questions.. > > If this is really how Konstantin is describing it then is it OK to say > about this to the whole Internet? Why FreeBSD Foundation is paying for > meaningless work then? Why members of the Core team do this work? Does > this mean that FreeBSD is working to satisfy the silly needs of some fat > customer? What about project independence and not being controlled by > big money? > > Where can I read about ASLR and security myths? Why not spend time and explain why this does not work? > Not to rise to the baitiness of all these leading questions (they really are quite contrary to how our community usually comports itself, but for the sake of civil discourse, I'll ignore) I'll bet it has something to do with the many known ASLR attacks. One is chronicled in https://www.vusec.net/projects/anc/ and elsewhere, which show how MMU side channels can defeat ASLR. Or maybe he's familiar with the offset2lib attack against Linux 64-bit ASLR documented in this paper https://cybersecurity.upv.es/attacks/offset2lib/offset2lib-paper.pdf. There's many others as well that show the shortcomings of ASLR and disclose ways to defeat it using various clever means. > You clearly should mean something useful and much more important than > that, > > when stating that FreeBSD made a huge step forward. So I want to be > aware > > of the advance. > > Why attack a person who was really happy for the project? > This DOES sound a agressive, even for a sarcastic joke.. > I am saying this someone who shares the same native language with Mr. > Belousov, > it is not a "language/culture" difference thing. > just your regular user who reads mailing list ocassionally > Maybe he'd like to understand how PIE accomplishes better security give the known ASLR weaknesses. And rather than take a sarcastic tone, he asked for more details that back up the earlier claims of improved security so we could all learn something. Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS-UP: PIE enabled by default on main
> > But isn't it well-known that ASLR/ASR/any-related-buzzwork does not add > any security, except imaginary? The only purpose of it is to have a > check-list item ticked green. I don't know if I should parse this as sarcasm (or any other form of "humor") or is a serious statement? But this does leave me with a whole bunch of questions.. If this is really how Konstantin is describing it then is it OK to say about this to the whole Internet? Why FreeBSD Foundation is paying for meaningless work then? Why members of the Core team do this work? Does this mean that FreeBSD is working to satisfy the silly needs of some fat customer? What about project independence and not being controlled by big money? Where can I read about ASLR and security myths? Why not spend time and explain why this does not work? > You clearly should mean something useful and much more important than that, > when stating that FreeBSD made a huge step forward. So I want to be aware > of the advance. Why attack a person who was really happy for the project? This DOES sound a agressive, even for a sarcastic joke.. I am saying this someone who shares the same native language with Mr. Belousov, it is not a "language/culture" difference thing. - just your regular user who reads mailing list ocassionally ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS-UP: PIE enabled by default on main
On Fri, Feb 26, 2021 at 08:32:26PM +0100, Gordon Bergling wrote: > On Fri, Feb 26, 2021 at 08:57:55PM +0200, Konstantin Belousov wrote: > > On Fri, Feb 26, 2021 at 07:34:03PM +0100, Gordon Bergling wrote: > > > On Thu, Feb 25, 2021 at 03:58:07PM -0500, Ed Maste wrote: > > > > As of 9a227a2fd642 (main-n245052) base system binaries are now built > > > > as position-independent executable (PIE) by default, for 64-bit > > > > architectures. PIE executables are used in conjunction with address > > > > randomization as a mitigation for certain types of security > > > > vulnerabilities. > > > > > > > > If you track -CURRENT and normally build WITHOUT_CLEAN you'll need to > > > > do one initial clean build -- either run `make cleanworld` or set > > > > WITH_CLEAN=yes. > > > > > > > > No significant user-facing changes are expected from this change, but > > > > there are some minor ones. For example, `file` will indicate that > > > > binaries are PIE by reporting something like `ELF 64-bit LSB pie > > > > executable` rather than `ELF 64-bit LSB executable`. Also, for most > > > > workloads no notable performance impact is expected. > > > > > > > > For almost all ports this should result in no change. There are a > > > > small number of ports that use base system /usr/share/mk > > > > infrastructure and thus inherit the base system default, and some of > > > > those initially failed to build. Those found during an exp-run in > > > > PR253275 have been addressed or have patches waiting. > > > > > > > > Please watch out for any new issues after you next update the base > > > > system and/or ports, and report issues via a Bugzilla PR or in reply > > > > here. > > > > > > Thats a huge step forward in terms on security. > > Can you explain why? > > > > Thanks. > > I can try. Enabling PIE for every 64bit architecture is in that matter a step > forward in security as it enables ASLR for further adoption. But isn't it well-known that ASLR/ASR/any-related-buzzwork does not add any security, except imaginary? The only purpose of it is to have a check-list item ticked green. You clearly should mean something useful and much more important than that, when stating that FreeBSD made a huge step forward. So I want to be aware of the advance. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS-UP: PIE enabled by default on main
On Fri, Feb 26, 2021 at 08:57:55PM +0200, Konstantin Belousov wrote: > On Fri, Feb 26, 2021 at 07:34:03PM +0100, Gordon Bergling wrote: > > On Thu, Feb 25, 2021 at 03:58:07PM -0500, Ed Maste wrote: > > > As of 9a227a2fd642 (main-n245052) base system binaries are now built > > > as position-independent executable (PIE) by default, for 64-bit > > > architectures. PIE executables are used in conjunction with address > > > randomization as a mitigation for certain types of security > > > vulnerabilities. > > > > > > If you track -CURRENT and normally build WITHOUT_CLEAN you'll need to > > > do one initial clean build -- either run `make cleanworld` or set > > > WITH_CLEAN=yes. > > > > > > No significant user-facing changes are expected from this change, but > > > there are some minor ones. For example, `file` will indicate that > > > binaries are PIE by reporting something like `ELF 64-bit LSB pie > > > executable` rather than `ELF 64-bit LSB executable`. Also, for most > > > workloads no notable performance impact is expected. > > > > > > For almost all ports this should result in no change. There are a > > > small number of ports that use base system /usr/share/mk > > > infrastructure and thus inherit the base system default, and some of > > > those initially failed to build. Those found during an exp-run in > > > PR253275 have been addressed or have patches waiting. > > > > > > Please watch out for any new issues after you next update the base > > > system and/or ports, and report issues via a Bugzilla PR or in reply > > > here. > > > > Thats a huge step forward in terms on security. > Can you explain why? > > Thanks. I can try. Enabling PIE for every 64bit architecture is in that matter a step forward in security as it enables ASLR for further adoption. Thank You, again. --Gordon > > Thanks for the efforts and anyone involved. signature.asc Description: PGP signature
Re: HEADS-UP: PIE enabled by default on main
On Fri, Feb 26, 2021 at 07:34:03PM +0100, Gordon Bergling wrote: > On Thu, Feb 25, 2021 at 03:58:07PM -0500, Ed Maste wrote: > > As of 9a227a2fd642 (main-n245052) base system binaries are now built > > as position-independent executable (PIE) by default, for 64-bit > > architectures. PIE executables are used in conjunction with address > > randomization as a mitigation for certain types of security > > vulnerabilities. > > > > If you track -CURRENT and normally build WITHOUT_CLEAN you'll need to > > do one initial clean build -- either run `make cleanworld` or set > > WITH_CLEAN=yes. > > > > No significant user-facing changes are expected from this change, but > > there are some minor ones. For example, `file` will indicate that > > binaries are PIE by reporting something like `ELF 64-bit LSB pie > > executable` rather than `ELF 64-bit LSB executable`. Also, for most > > workloads no notable performance impact is expected. > > > > For almost all ports this should result in no change. There are a > > small number of ports that use base system /usr/share/mk > > infrastructure and thus inherit the base system default, and some of > > those initially failed to build. Those found during an exp-run in > > PR253275 have been addressed or have patches waiting. > > > > Please watch out for any new issues after you next update the base > > system and/or ports, and report issues via a Bugzilla PR or in reply > > here. > > Thats a huge step forward in terms on security. Can you explain why? Thanks. > Thanks for the efforts and anyone involved. > > --Gordon ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS-UP: PIE enabled by default on main
On Thu, Feb 25, 2021 at 03:58:07PM -0500, Ed Maste wrote: > As of 9a227a2fd642 (main-n245052) base system binaries are now built > as position-independent executable (PIE) by default, for 64-bit > architectures. PIE executables are used in conjunction with address > randomization as a mitigation for certain types of security > vulnerabilities. > > If you track -CURRENT and normally build WITHOUT_CLEAN you'll need to > do one initial clean build -- either run `make cleanworld` or set > WITH_CLEAN=yes. > > No significant user-facing changes are expected from this change, but > there are some minor ones. For example, `file` will indicate that > binaries are PIE by reporting something like `ELF 64-bit LSB pie > executable` rather than `ELF 64-bit LSB executable`. Also, for most > workloads no notable performance impact is expected. > > For almost all ports this should result in no change. There are a > small number of ports that use base system /usr/share/mk > infrastructure and thus inherit the base system default, and some of > those initially failed to build. Those found during an exp-run in > PR253275 have been addressed or have patches waiting. > > Please watch out for any new issues after you next update the base > system and/or ports, and report issues via a Bugzilla PR or in reply > here. Thats a huge step forward in terms on security. Thanks for the efforts and anyone involved. --Gordon signature.asc Description: PGP signature
Re: HEADS-UP: PIE enabled by default on main
On Thu, Feb 25, 2021 at 09:22:43PM -0500, Ed Maste wrote: > On Thu, 25 Feb 2021 at 19:23, John Kennedy wrote: > > > > Not sure if Ed Maste just wants to make sure that all the executables > > are rebuilt as PIE (vs hit-and-miss) or there is a sneaker corner-case that > > he knows about. > > The issue is that without a clean build you may have some .o files > left around that are built without PIE enabled (i.e., compiled without > -fPIE), and attempting to link them into a PIE executable will fail > with an error like: > > ld: error: can't create dynamic relocation R_X86_64_32 against local > symbol in readonly segment; recompile object files with -fPIC or pass > '-Wl,-z,notext' to allow text relocations in the output > FWIW, my source update from: FreeBSD freebeast.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #1194 main-n245061-c861373bdff9: Thu Feb 25 04:09:17 PST 2021 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC amd64 145 145 to: FreeBSD freebeast.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #1195 main-n245107-172f2fc11cc5: Fri Feb 26 04:01:22 PST 2021 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC amd64 145 145 this morning was quite uneventful. I did nothing special -- just the normal META_MODE build I always do. Rebooted; started X11 (built under stable/12, as with all of the ports save x11/nvidia-driver)... things Just Worked. :-) (Above was from one machine; I actually updated 3 machines in parallel.) Peace, david -- David H. Wolfskill da...@catwhisker.org It is supremely disingenuous to claim a lack of jurisdiction, then proceed to participate in a decision on the same matter. See https://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: HEADS-UP: PIE enabled by default on main
On 26 Feb 2021, at 03:22, Ed Maste wrote: > > On Thu, 25 Feb 2021 at 19:23, John Kennedy wrote: >> >> Not sure if Ed Maste just wants to make sure that all the executables >> are rebuilt as PIE (vs hit-and-miss) or there is a sneaker corner-case that >> he knows about. > > The issue is that without a clean build you may have some .o files > left around that are built without PIE enabled (i.e., compiled without > -fPIE), and attempting to link them into a PIE executable will fail Hmm, maybe it is time for a ".pieo" extension? (I disliked .pico at first, but now I see the sense in it; might as well make clear that plain ".o" is meant for 'static' object files.) -Dimitry signature.asc Description: Message signed with OpenPGP
Re: HEADS-UP: PIE enabled by default on main
On Thursday, 25 February 2021 at 21:22:43 -0500, Ed Maste wrote: > On Thu, 25 Feb 2021 at 19:23, John Kennedy wrote: >> >> Not sure if Ed Maste just wants to make sure that all the executables >> are rebuilt as PIE (vs hit-and-miss) or there is a sneaker corner-case that >> he knows about. > > The issue is that without a clean build you may have some .o files > left around that are built without PIE enabled (i.e., compiled without > -fPIE), and attempting to link them into a PIE executable will fail > with an error like: > > ld: error: can't create dynamic relocation R_X86_64_32 against local symbol > in readonly segment; recompile object files with -fPIC or pass > '-Wl,-z,notext' to allow text relocations in the output Ah, thanks. That makes more sense. Greg -- Sent from my desktop computer. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA signature.asc Description: PGP signature
Re: HEADS-UP: PIE enabled by default on main
On Thu, 25 Feb 2021 at 19:23, John Kennedy wrote: > > Not sure if Ed Maste just wants to make sure that all the executables > are rebuilt as PIE (vs hit-and-miss) or there is a sneaker corner-case that > he knows about. The issue is that without a clean build you may have some .o files left around that are built without PIE enabled (i.e., compiled without -fPIE), and attempting to link them into a PIE executable will fail with an error like: ld: error: can't create dynamic relocation R_X86_64_32 against local symbol in readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output I am not aware of any configuration that would link successfully, but then have some run-time failure. If it builds it should work. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS-UP: PIE enabled by default on main
On Thu, 25 Feb 2021 at 18:10, Greg 'groggy' Lehey wrote: > > This details worries me. How compatible are PIE executables with > non-PIE executables? Can I run PIE executables on older systems? Can > I run older executables on a PIE system? There is no issue mixing PIE and non-PIE binaries, and they introduce no additional constraints on running on older kernels. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS-UP: PIE enabled by default on main
On Fri, Feb 26, 2021 at 10:10:28AM +1100, Greg 'groggy' Lehey wrote: > On Thursday, 25 February 2021 at 15:58:07 -0500, Ed Maste wrote: > > As of 9a227a2fd642 (main-n245052) base system binaries are now built > > as position-independent executable (PIE) by default, for 64-bit > > architectures. ... > > > > If you track -CURRENT and normally build WITHOUT_CLEAN you'll need to > > do one initial clean build -- either run `make cleanworld` or set > > WITH_CLEAN=yes. > > This details worries me. How compatible are PIE executables with > non-PIE executables? Can I run PIE executables on older systems? Can > I run older executables on a PIE system? Assuming we're basically talking about WITH_PIE=YES in /etc/src.conf, I've been doing this since 2020/08/04 (12.1 -> 12.2 -> 13/14). I don't think I've associated any problems with PIE. I've certainly got lots of non-PIE ports linked against base libraries (but ELF 64-bit LSB shared object, vs ELF 64-bit LSB pie executable). The E in PIE is executable. Not sure if Ed Maste just wants to make sure that all the executables are rebuilt as PIE (vs hit-and-miss) or there is a sneaker corner-case that he knows about. I can't say that I've had an opportunity to try the scenario I think you're looking at. My "older" crossovers are +/- a __FreeBSD_version bump. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS-UP: PIE enabled by default on main
On Thursday, 25 February 2021 at 15:58:07 -0500, Ed Maste wrote: > As of 9a227a2fd642 (main-n245052) base system binaries are now built > as position-independent executable (PIE) by default, for 64-bit > architectures. PIE executables are used in conjunction with address > randomization as a mitigation for certain types of security > vulnerabilities. > > If you track -CURRENT and normally build WITHOUT_CLEAN you'll need to > do one initial clean build -- either run `make cleanworld` or set > WITH_CLEAN=yes. This details worries me. How compatible are PIE executables with non-PIE executables? Can I run PIE executables on older systems? Can I run older executables on a PIE system? Greg -- Sent from my desktop computer. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft mail program reports problems, please read http://lemis.com/broken-MUA signature.asc Description: PGP signature
HEADS-UP: PIE enabled by default on main
As of 9a227a2fd642 (main-n245052) base system binaries are now built as position-independent executable (PIE) by default, for 64-bit architectures. PIE executables are used in conjunction with address randomization as a mitigation for certain types of security vulnerabilities. If you track -CURRENT and normally build WITHOUT_CLEAN you'll need to do one initial clean build -- either run `make cleanworld` or set WITH_CLEAN=yes. No significant user-facing changes are expected from this change, but there are some minor ones. For example, `file` will indicate that binaries are PIE by reporting something like `ELF 64-bit LSB pie executable` rather than `ELF 64-bit LSB executable`. Also, for most workloads no notable performance impact is expected. For almost all ports this should result in no change. There are a small number of ports that use base system /usr/share/mk infrastructure and thus inherit the base system default, and some of those initially failed to build. Those found during an exp-run in PR253275 have been addressed or have patches waiting. Please watch out for any new issues after you next update the base system and/or ports, and report issues via a Bugzilla PR or in reply here. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
