Re: riscv questions
On Thu, Aug 17, 2023 at 06:03:42PM +, Mike Larkin wrote: > On Sun, Aug 13, 2023 at 06:27:20PM +0200, Peter J. Philipp wrote: > > Hi, > > > > I was wondering two things currently, both having to do with QEMU on > > OpenBSD. > > > > I noticed in my QEMU that is running OpenBSD that it is supporting the > > H-extension. The H is hypervisor. Does this mean that there is support > > emulated for hypervisor host and guest in QEMU? Also is there any efforts > > to > > implement this where I can be an observer? > > I believe they have some support for that. > > There is no hardware currently available that has it though, from what I know. > There is an FPGA core you can implement on a suitably large dev board though, > but you'd be a 1-off. > > When you say "implement this", what do you mean? Oh I didn't know there was no hardware support for this yet. What I meant for implementing this was if there is anyone porting vmm to riscv64. I guess arm64 needs it too but riscv64 to me is the ultimate :-). I was wondering Mike, do you offer any more workgroups like the one that ported riscv64? I know someone on IRC who lives in the Los Angeles region of California that might be interested in such a workgroup. Though he may not be available until 2024/2025 for something such as this, but the interest would be there. I told him an effort to port vmm to riscv64 would be a worthwhile endeavour, for everyone. Obviously it depends on hardware support and someone to guide the group. > > > > I saw somewhere that newer QEMU support RV128 cpu emulation. While this > > is something for 20 years from now perhaps, I'm still curious if anyone is > > considering a port to the RV128, or is at least turned on by the thought of > > it. > > no > > > Unfortunately I believe the RV128 isn't intended for an 128 bit address > > space > > but has something planned for partitioning it in half so it will be 64 bit > > space. With the other 64 bit for something security related. > > > > Also I'd like to say that I have my first piece of RV64 hardware for a few > > weeks now and it can run linux ubuntu. It's a Mango Pi which is the same > > form factor as a RPI zero. I also donated one to a developer so perhaps > > we'll > > see OpenBSD running on it one day. In half a dozen weeks or so I'm > > considering > > getting my second RV64 computer, which will be somewhat of a visionfive > > 2-like > > SBC for a router. Not sure which yet, though, let's see who can deliver in > > October. > > > > Next year I'd like to invest into a larger RV64 computer for workstation. As > > you can see I'm starting to get a bit serious around Risc-V > > get a milk-v pioneer then, it's the biggest you can currently buy. Interesting. Thanks! Best Regards, -peter -- Over thirty years experience on Unix-like Operating Systems starting with QNX.
AR9485 on Lenovo G505 not configured.
Could AR9485 work on OpenBSD? I can't write a driver, nor does it seem that a simple bios whitelist jailbreak is available for Lenovo G505 with AMD processor. OpenBSD 7.3 (GENERIC.MP) #1125: Sat Mar 25 10:36:29 MDT 2023 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 7979032576 (7609MB) avail mem = 7717797888 (7360MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xbfabc000 (49 entries) bios0: vendor LENOVO version "82CN24WW(V2.04)" date 11/05/2013 bios0: LENOVO 20240 efi0 at bios0: UEFI 2.3.1 efi0: INSYDE Corp. rev 0x1001 acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC UEFI HPET APIC MCFG ASF! BOOT FPDT MSDM SSDT SSDT SSDT SSDT SSDT SSDT SSDT BGRT acpi0: wakeup devices GPP1(S4) OHC1(S4) OHC2(S4) OHC3(S4) EHC1(S4) EHC2(S4) EHC3(S4) XHC0(S4) LID_(S4) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpihpet0 at acpi0: 14318180 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD E1-2100 APU with Radeon(TM) HD Graphics, 998.15 MHz, 16-00-01 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PCTRL3,ITSC,BMI1,XSAVEOPT cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 2-way I-cache, 1MB 64b/line 16-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD E1-2100 APU with Radeon(TM) HD Graphics, 998.14 MHz, 16-00-01 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PCTRL3,ITSC,BMI1,XSAVEOPT cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 2-way I-cache, 1MB 64b/line 16-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 4 pa 0xfec0, version 21, 24 pins, remapped ioapic1 at mainbus0: apid 5 pa 0xfec01000, version 21, 32 pins, remapped acpimcfg0 at acpi0 acpimcfg0: addr 0xf800, bus 0-63 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (GPP0) acpiprt2 at acpi0: bus 1 (GPP1) acpiprt3 at acpi0: bus 2 (GPP2) acpiprt4 at acpi0: bus -1 (GPP3) acpiprt5 at acpi0: bus -1 (GFX_) acpiec0 at acpi0 acpibtn0 at acpi0: PWRB acpipci0 at acpi0 PCI0: 0x0010 0x0011 0x acpicmos0 at acpi0 "SYN2B1F" at acpi0 not configured "VPC2004" at acpi0 not configured acpibat0 at acpi0: BAT1 model "PABAS0241231" serial 41167 type Li-Ion oem "SIMPLO " acpiac0 at acpi0: AC unit online acpibtn1 at acpi0: LID_ "ASD0001" at acpi0 not configured acpicpu0 at acpi0: C2(0@400 io@0x414), C1(@1 halt!), PSS acpicpu1 at acpi0: C2(0@400 io@0x414), C1(@1 halt!), PSS acpivideo0 at acpi0: VGA_ acpivout0 at acpivideo0: LCD_ acpivideo1 at acpi0: VGA_ cpu0: 998 MHz: speeds: 1000 900 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "AMD 16h Host" rev 0x00 radeondrm0 at pci0 dev 1 function 0 "ATI Kabini" rev 0x00 drm0 at radeondrm0 radeondrm0: msi azalia0 at pci0 dev 1 function 1 "ATI Radeon HD Audio" rev 0x00: msi azalia0: no supported codecs pchb1 at pci0 dev 2 function 0 vendor "AMD", unknown product 0x1538 rev 0x00 ppb0 at pci0 dev 2 function 3 "AMD 16h PCIE" rev 0x00: msi pci1 at ppb0 bus 1 alc0 at pci1 dev 0 function 0 "Attansic Technology AR8172" rev 0x10: msi, address 20:1a:06:2c:98:5c atphy0 at alc0 phy 0: AR8035 10/100/1000 PHY, rev. 9 ppb1 at pci0 dev 2 function 4 "AMD 16h PCIE" rev 0x00: msi pci2 at ppb1 bus 2 "Atheros AR9485" rev 0x01 at pci2 dev 0 function 0 not configured xhci0 at pci0 dev 16 function 0 "AMD Bolton xHCI" rev 0x01: msi, xHCI 1.0 usb0 at xhci0: USB revision 3.0 uhub0 at usb0 configuration 1 interface 0 "AMD xHCI root hub" rev 3.00/1.00 addr 1 ahci0 at pci0 dev 17 function 0 "AMD Hudson-2 SATA" rev 0x00: msi, AHCI 1.3 ahci0: port 0: 3.0Gb/s ahci0: port 1: 1.5Gb/s scsibus1 at ahci0: 32 targets sd0 at scsibus1 targ 0 lun 0: naa.5000c5005bb49181 sd0: 476940MB, 512 bytes/sector, 976773168 sectors cd0 at scsibus1 targ 1 lun 0: removable ohci0 at pci0 dev 18 function 0 "AMD Hudson-2 USB" rev 0x39: apic 4 int 18, version 1.0, legacy support ehci0 at pci0 dev 18 function 2 "AMD Hudson-2 USB2" rev 0x39: apic 4 int 17 usb1 at ehci0: USB revision 2.0 uhub1 at usb1 configuration 1 interface 0 "AMD EHCI root hub" rev 2.00/1.00 addr 1 ohci1 at pci0 dev 19 function 0 "AMD Hudson-2 USB" rev 0x39: apic 4 int 18, version 1.0, legacy support ehci1 at pci0 dev 19 function 2 "AMD Hudson-2 USB2" rev 0x39: apic 4 int 17 u
Re: volatility or something like that in the future ?
Il 2023-08-18 02:20 Scott Cheloha ha scritto: >> On Aug 17, 2023, at 10:28, whistlez wrote: >> >> https://github.com/volatilityfoundation/volatility3 > > What is the utility of this software? How > would supporting it benefit the project? > > I read the summary on Github. I am still > more or less completely in the dark on > why I or anyone would want to use it. It seems rather important to me because it's not possible to be certain about the invulnerability of the underlying operating system or the kernel. Alternatively, an attacker might have a zero-day exploit on Firefox or Chrome and inject code into the process, allowing data exfiltration. Even though the attacker would be confined within the jail created by the kernel, it doesn't seem acceptable to have unauthorized code running on one's machine, especially in a critical process like a browser. The same principle could be applied to another process more focused on firewall solutions, such as Snort. Furthermore, in my opinion - brace yourself, I might trigger an atomic war with what I'm about to say - we should consider it certain that the kernel could contain unknown vulnerabilities. Unauthorized code running in the kernel is impossible to detect, clearly. I'm talking about code that might not even reside on the disk but is injected remotely. Thus, the only way is through inspecting the RAM dump, that is, a software that can analyze the dump and determine its integrity. Additionally, due to kernel relinking, we know that its hash changes with every reboot, rendering classic integrity verification tools unusable. To put it simply, without delving into sophisticated attacks, a machine could be physically attacked, and unauthorized code could be introduced into the kernel. Therefore, we might end up with a machine compromised by a compromised kernel, and there might be no way (at least as far as I know) to know about it. This assumes there are unintentional vulnerabilities. But what if deliberate vulnerabilities are introduced? I recall an old piece of news, which I never understood if it was confirmed, that a developer of the OpenBSD kernel might have introduced a backdoor under instruction or through coercion by a security agency. Now, far be it from me to discredit the OpenBSD development team, which has done an enormous and exceptional job. It's clear that Theo has done, and is doing, a wonderful job... nevertheless, one should account for any eventuality. I believe that a forensics memory analysis interface would make persistence and invisibility of unauthorized code much harder to achieve. Even a developer intending to hide something would find themselves a bit more exposed. And all of this without even considering hardware vulnerabilities, such as those in CPUs or other aspects of the machine, like firmware.
Re: volatility or something like that in the future ?
> On Aug 17, 2023, at 10:28, whistlez wrote: > > [...] I believe we need to realize that, while the kernel is very > secure, zero-day vulnerabilities are always a lurking threat. > > For those that don't know what is volatility, this is github page > https://github.com/volatilityfoundation/volatility3 What is the utility of this software? How would supporting it benefit the project? I read the summary on Github. I am still more or less completely in the dark on why I or anyone would want to use it.
Re: Stuck in X start and crash loop
Hey Nick, thank you for taking the time, I appreciate it. I had configured X to automatically log in, as I use FDE and the cost of entering two passwords does not seem worth the security. Single user mode did the trick! Again, thanks a lot! Kind regards, Leo
Re: Stuck in X start and crash loop
On 8/17/23 12:10, l...@ena.re wrote: Hey, I am new to OpenBSD. I run 7.3-stable. My understanding after reading X(7), Xsecurity(7) and xenodm(1) is that one can set the environment variable XAUTHORITY to specify the location of the file, which by default, is located at $HOME/.Xauthority.> In $HOME/.profile I set XAUTHORITY=$HOME/.config/X/Xauthority and moved .Xauthority to $HOME/.config/X/Xauthority. However, now, when I boot and X is started, I see the cursor in the middle of the screen for a moment and then X seems to crash and start again. I am stuck in this loop. Why do I not witness the behaviour I expected? Should I have set the environment variable in $HOME/.xsession? if you want my opinion of what you should do, i'd argue you should leave it alone. More importantly, how do I exit this loop and revert the changes? What isn't clear is when you get the loop. Are you logging in in text mode then starting X as you, and getting this loop? or is X starting on boot, and you are getting that loop? If X is starting on boot and looping, I think you have another problem, because a file in your home directory isn't being referenced until you log in. But, to answer your question about how to fix it...depending on what is going on, I'd start with CTRL-ALT-F1 to get to the command line, log in, undo. You might be able to hit CTRL-ALT-BackSpace to shut down X, but if you are running xenocara, that will just take you back to the login prompt. But NOW you might be able to CTRL-ALT-F1 back to the CLI. WORST CASE, reboot the machine, and boot in single user mode. # mount -a # export TERM=vt220 ...fix it Nick.
Re: volatility or something like that in the future ?
Hi, On Thu, Aug 17, 2023 at 05:12:54PM +0200, whistlez wrote: > Hello community, I would like to ask if it's possible to develop a tool > similar to Volatility in the future or a specific integration for > OpenBSD. Along with a tool that can perform RAM dumping. do you need anything else than mem(4)? I.e. /dev/mem. See the manpage for more details. Yours, M. -- id' Ash = Ash; id' Dust = Dust; id' _ = undefined
Re: riscv questions
On Sun, Aug 13, 2023 at 06:27:20PM +0200, Peter J. Philipp wrote: > Hi, > > I was wondering two things currently, both having to do with QEMU on OpenBSD. > > I noticed in my QEMU that is running OpenBSD that it is supporting the > H-extension. The H is hypervisor. Does this mean that there is support > emulated for hypervisor host and guest in QEMU? Also is there any efforts to > implement this where I can be an observer? I believe they have some support for that. There is no hardware currently available that has it though, from what I know. There is an FPGA core you can implement on a suitably large dev board though, but you'd be a 1-off. When you say "implement this", what do you mean? > > I saw somewhere that newer QEMU support RV128 cpu emulation. While this > is something for 20 years from now perhaps, I'm still curious if anyone is > considering a port to the RV128, or is at least turned on by the thought of > it. no > Unfortunately I believe the RV128 isn't intended for an 128 bit address space > but has something planned for partitioning it in half so it will be 64 bit > space. With the other 64 bit for something security related. > > Also I'd like to say that I have my first piece of RV64 hardware for a few > weeks now and it can run linux ubuntu. It's a Mango Pi which is the same > form factor as a RPI zero. I also donated one to a developer so perhaps we'll > see OpenBSD running on it one day. In half a dozen weeks or so I'm > considering > getting my second RV64 computer, which will be somewhat of a visionfive 2-like > SBC for a router. Not sure which yet, though, let's see who can deliver in > October. > > Next year I'd like to invest into a larger RV64 computer for workstation. As > you can see I'm starting to get a bit serious around Risc-V get a milk-v pioneer then, it's the biggest you can currently buy. > > Best Regards, > -peter > > -- > Over thirty years experience on Unix-like Operating Systems starting with QNX. >
Stuck in X start and crash loop
Hey, I am new to OpenBSD. I run 7.3-stable. My understanding after reading X(7), Xsecurity(7) and xenodm(1) is that one can set the environment variable XAUTHORITY to specify the location of the file, which by default, is located at $HOME/.Xauthority. In $HOME/.profile I set XAUTHORITY=$HOME/.config/X/Xauthority and moved .Xauthority to $HOME/.config/X/Xauthority. However, now, when I boot and X is started, I see the cursor in the middle of the screen for a moment and then X seems to crash and start again. I am stuck in this loop. Why do I not witness the behaviour I expected? Should I have set the environment variable in $HOME/.xsession? More importantly, how do I exit this loop and revert the changes? Kind regards, Leo
volatility or something like that in the future ?
Hello community, I would like to ask if it's possible to develop a tool similar to Volatility in the future or a specific integration for OpenBSD. Along with a tool that can perform RAM dumping. However, could this potentially make the kernel vulnerable? In my opinion, even though I'm not a developer, it would be desirable to have a proper kernel interface for performing the dump. Something that is maintained directly by the development team to prevent the software team from constantly keeping up with changes in every new kernel release. I believe we need to realize that, while the kernel is very secure, zero-day vulnerabilities are always a lurking threat. For those that don't know what is volatility, this is github page https://github.com/volatilityfoundation/volatility3 I hope Theo doesn't get angry, as I'm a very sensitive person, and if someone offends me or makes fun of me, it really upsets me. regards WhistleX
Re: Mouse not working via KVM switch
On 8/14/23 13:37, Karel Lucas wrote: HI all, On a recent install of openBSD I can't get the mouse to work through my KVM switch. I work with various computers via a KVM switch on 1 monitor with a keyboard/mouse combination. Only on the PC with openBSD the mouse does not work, the keyboard on the other hand works fine. Both are connected to the KVM switch via USB, and the switch via USB to the computers. The brand of the mouse is Logitech. Does anyone know why the mouse doesn't work, but the keyboard does? Good thing Logitech only makes one kind of mouse. HA! HAHAHaHahahaha!!! I am so funny. Really, though -- you thought mentioning just the brand name of one of the more diverse makers of mice over 40+ years is all we needed to know? KVM switches are like a lot of other things -- tested with Windows, MAYBE Linux. And there are widely differing qualities and designs, some probably weren't tested at all. I can assure you, OpenBSD has no intrinsic issue with KVM switches. I regularly use a dual HDMI monitor 4-way KVM switch on OpenBSD and Windows machines, works great in spite of being shockingly cheap (until it seems two of the USB input ports died...but fortunately, it had two extras, and I wouldn't be surprised if a complete powerdown fixed it). That one replaced an even cheaper single monitor switch which was almost useful, but had a lot of issues (including keyboard/mouse just dying from time to time). First of all, does your mouse work directly plugged into the OpenBSD computer? If so, it's your KVM switch. Replace it. If not, it is your mouse. Replace it. Second...if you boot the OpenBSD machine with the KVM pointed at the OpenBSD machine, does it work? If so, your KVM switch is cranky. You might be able to improve how OpenBSD deals with KVM switched mice, because yes, it does seem to be a little more touchy than some other OSs, but someone with good programming and HW trouble shooting skills AND a cheap-*** POS KVM switch would have to care. Most people that skilled generally just buy a better KVM switch and move on. What does the dmesg show as you switch the KVM around? That would tell us how the KVM works. Some are equiv. of plugging and unplugging the mouse/keyboard/monitor, some do some kind of "keep alive" so the computer thinks the mouse is still there. Both can cause problems of different types (my "good" one seems to plug/unplug the mouse/keyboard, but has a great keep-alive for the monitor). Nick.
