Panic on reboot fresh install 14-current
Hi all Today I installed the 14-current on my new machine. On install process, when i changed my keyboard layout and it was not working fine, the installer show this menssage: kbdcontrol: setting keymap: Inappropriate ioctl for device but it continue to use the default keyboard map, after reboot the keyboard map was working fine. Comming back to subjet of message, when I finish the install process and reboot I get a panic before wmt module was loaded. I reboot twice to see if there were some bogus info or residual trash after install process, but get the same panic error (trap 9) I reboot and selected single user to verify if i did something wrong. I always set my NIC with dhcp in install process, it's easier. I changed in /etc/rc.cont to static IP my NIC, and make others setup. I rebooted the machine and it was working fine. Is it very strange, ok? I undo all config, one by one, and found the problem. When I boot with my NIC in DHCP mode the panic on boot occur. My box is a Ryzen 5 2600 with motherboard ASUS B450 Gamming BR, ASUS GTX 1050ti and 16GB RAM I formated my SSD with zfs and I'm running 14-current 20210222 main-n245056-bf667f282a7 TIA Nilton J. Rizzo ___ 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: uchcom update
On 28/02/2021 11:03, KOT MATPOCKuH wrote: > Hello! > > I'm using FreeBSD 12.2-STABLE r368656 and got usb-to-rs232 with this > controller. > I see /dev/cuaU0 after plugging in adapter, I can attach to serial line > using cu, but after sending any symbol to device I have device reconnection: > uchcom0 on uhub0 > uchcom0: on usbus0 > uchcom0: CH340 detected > uchcom0: at uhub0, port 9, addr 17 (disconnected) > uchcom0: detached > uchcom0 on uhub0 > uchcom0: on usbus0 > uchcom0: CH340 detected I have this in my loader.conf: # Ignore result of "clear stall" (clearing halt on endpoints) # CH340 USB<->RS232 requires this # and it seems that Linux and Windows do this by default hw.usb.no_cs_fail=1 I recall that without that tuning I had a similar problem. > вт, 5 июн. 2018 г. в 15:05, Ian FREISLICH : > >> On 05/22/2018 09:44 AM, Andriy Gapon wrote: >>> Yesterday I committed some changes to uchcom (so far, only in CURRENT). >>> Commits are r333997 - r334002. >>> >>> If you have a CH340/341 based USB<->RS232 adapter and it works for you, >> could >>> you please test that it still does? >>> If you tried your adapter in the past and it did not work, there is a >> chance it >>> might start working now. Could you please test that as well? >> >> ugen5.4: at usbus5, cfg=0 md=HOST spd=FULL >> (12Mbps) pwr=ON (96mA) >> ugen5.4.0: uchcom0: >> >> It's not made it any worse. I'm not using this adapter by choice - it's >> a USB to Maxim (Dallas) one-wire bus adapter. The manual used to state >> that these are possibly the worst chips ever. Is that still the >> prevailing opinion? -- Andriy Gapon ___ 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: uchcom update
Hello! I'm using FreeBSD 12.2-STABLE r368656 and got usb-to-rs232 with this controller. I see /dev/cuaU0 after plugging in adapter, I can attach to serial line using cu, but after sending any symbol to device I have device reconnection: uchcom0 on uhub0 uchcom0: on usbus0 uchcom0: CH340 detected uchcom0: at uhub0, port 9, addr 17 (disconnected) uchcom0: detached uchcom0 on uhub0 uchcom0: on usbus0 uchcom0: CH340 detected вт, 5 июн. 2018 г. в 15:05, Ian FREISLICH : > On 05/22/2018 09:44 AM, Andriy Gapon wrote: > > Yesterday I committed some changes to uchcom (so far, only in CURRENT). > > Commits are r333997 - r334002. > > > > If you have a CH340/341 based USB<->RS232 adapter and it works for you, > could > > you please test that it still does? > > If you tried your adapter in the past and it did not work, there is a > chance it > > might start working now. Could you please test that as well? > > ugen5.4: at usbus5, cfg=0 md=HOST spd=FULL > (12Mbps) pwr=ON (96mA) > ugen5.4.0: uchcom0: > > It's not made it any worse. I'm not using this adapter by choice - it's > a USB to Maxim (Dallas) one-wire bus adapter. The manual used to state > that these are possibly the worst chips ever. Is that still the > prevailing opinion? > > Ian > > -- > > ___ > 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" > -- MATPOCKuH ___ 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"
