Re: Mouse not working via KVM switch
On Fri, Aug 18, 2023 at 07:58:03PM +0200, Karel Lucas wrote: > > Dear Nick, > > For more than ten years I have been working with an ATEN brand KVM switch > together with several computers, including linux and openBSD (version 4.1). > In all these years I have had no problems, not with my KVM switch, nor with > any degree of disconnection. The keyboard works flawlessly via the switch, > it's only the mouse that I have a problem with, and only with openBSD. > This is not very clear at all. You have used the same KVM switch for ten years, but haven't considered it having hardware degradation over that time? Capacitors are well known for having limited lifetimes and are *usually* the first item looked at in repairs. Switches also fail due to dirty contacts. Or, are you saying that everything worked fine for OpenBSD 4.1, but not for OpenBSD 7.3? The changes over that time have been enormous. > Op 17-08-2023 om 13:56 schreef Nick Holland: > > > > First of all, does your mouse work directly plugged into the OpenBSD > > computer? > Yes, it does. > > If so, it's your KVM switch. > As I mentioned above I have been working with my KVM switch and openBSD for > over ten years with very good results. > > > Second...if you boot the OpenBSD machine with the KVM pointed at the > > OpenBSD machine, does it work? > No, even then it won't work. Have you swapped ports on the KVM switch to rule out a partial hardware failure on the switch? Have you also disconnected the other hardware and OS inputs to rule out them as the source of the problem? Have you checked that the other machines are producing the correct supply voltages? Power supply failures are a consistent problem with computers. High or low voltages don't mix well. Have you checked with your switch manufacturer to make sure there wasn't a problem with your switches model? It happens a lot. After ten years of service, if you insist that the switch isn't the problem, (Prove it) then you need to also prove that the other hardware is functioning properly. Do not believe what the BIOS or sensors say that the voltage is. A bad voltage will cause those readings to fail. Get a good voltmeter with excellent probes for this kind of work and check *everything*. Please use a great deal of care. You will need to measure voltages on the motherboards in addition to what the power supply puts out. Everything is running and you will need to check in many spots. Also, there are high voltages inside the power supply. Don't get electrocuted. Drain the voltages off the capacitors in there with a suitable tool for that purpose if you go inside there. Yes, even with the power off and power cable disconnected. And it's tricky. I have a power supply cable for two hard drives. Two connectors crimped across the same cable. One of the crimps is bad. Recognizing that saved me a trip to hell after about an hour. Easy to fix, damned hard to locate. Chris Bennett > > 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. > That more than ten years of loyal service proves that my KVM is of good > quality. > > 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). > What I've learned about my KVM switch over the past ten years is that both > the mouse and keyboard are emulated when they are switched to another > computer. Never have I had any problems with my computers when switching > with my KVM switch. > > >
Re: volatility or something like that in the future ?
> >> Furthermore, in my opinion - brace yourself, I might trigger an atomic > >> war with what I'm about to say - Don't worry. OpenBSDs ministry of defence considered dropping atomic bombs over Australia in the past. It's considered an acceptable way of CVS conflict resolution. > 1. Volatility allows the detection of hidden kernel modules in a Linux > environment, including typical LKM rootkits. So, maybe don't use loadable kernel modules at all? Problem gone, nothing to detect here. > 2. There are multiple methods for RAM dumping, some of which cannot be > circumvented and do not require specific software or interfaces. I'm not a dev, but I do trust the devs handling that. Regarding the rest of your reasoning, I think you are way off-track. Linux assumptions do not apply.
Re: Mouse not working via KVM switch
Dear Nick, For more than ten years I have been working with an ATEN brand KVM switch together with several computers, including linux and openBSD (version 4.1). In all these years I have had no problems, not with my KVM switch, nor with any degree of disconnection. The keyboard works flawlessly via the switch, it's only the mouse that I have a problem with, and only with openBSD. Op 17-08-2023 om 13:56 schreef Nick Holland: First of all, does your mouse work directly plugged into the OpenBSD computer? Yes, it does. If so, it's your KVM switch. As I mentioned above I have been working with my KVM switch and openBSD for over ten years with very good results. Second...if you boot the OpenBSD machine with the KVM pointed at the OpenBSD machine, does it work? No, even then it won't work. 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. That more than ten years of loyal service proves that my KVM is of good quality. 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). What I've learned about my KVM switch over the past ten years is that both the mouse and keyboard are emulated when they are switched to another computer. Never have I had any problems with my computers when switching with my KVM switch.
Re: Why does `pkg_info -m` show quirks?
On 2023-08-18, l...@ena.re wrote: > Hey, > > according to pkg_info(1) the -m options "shows the names and one-line > comments for all packages tagged as manually installed". However, > executing `pkg_info -m` shows the quirks package, which is clearly not > "manually installed". According to it's package description: "pkg_add(1) > always installs and updates it automatically". > > Can a package be tagged either as manually installed or as a dependency > and as quirks is not a dependency, it is tagged as manually installed? > If this is so, it seems to make sense that is tagged as manually > installed. quirks isn't installed as a dependency of another port, so by that definition it's not "auto installed". I think it's undesirable for "pkg_delete -a" to remove the quirks package which is probably why it is currently recorded as manual-install. > However, what do you think about not showing quirks when executing > `pkg_info -mz`, as this is intended to "be reused with pkg_add(1) -l to > recreate a package installation"? Similarly to how firmware is not shown. > This would resemble the behaviour I expect from `pkg_info -mz`. might be an idea, though it doesn't really hurt to list it. suggest asking on ports@ and cc espie rather than on misc, though IIRC he's away at the moment. > Also, what is the reason the quirks package does not have a man page? I > believe it should have one, just like any other program. Is this > something that is desired? If so, I would gladly model one after the > package description. not sure what such a manpage would be named. it is already described here though: $ man -k any=quirks packages(7) - overview of the binary package system
Re: volatility or something like that in the future ?
On 2023-08-18, whistlez wrote: > > 2. There are multiple methods for RAM dumping, some of which cannot be > circumvented and do not require specific software or interfaces. For > example: > a. Through a 'cold boot attack,' it's possible to dump RAM from an > uncompromised operating system. (Reference: > https://en.wikipedia.org/wiki/Cold_boot_attack) > b. Through a DMA attack, leveraging FireWire or other hardware > interfaces, it's possible to dump RAM. I believe that, in this case, as > in the previous one, the kernel would be completely unaware. An example > of this kind of attack and dump is "inception" > (https://github.com/carmaa/inception). > c. In a virtualized environment such as VMM, VirtualBox, VMware, > etc. (we know OpenBSD can be virtualized), you can acquire RAM without > the operating system knowing. I think it would be better to concentrate on the above methods. They don't rely on bypassing security measures in the OS (allowing /dev/mem from userland means you turn some possible attacks from "must subvert the kernel" to "must subvert root"), and sidestep the "can you trust the kernel" problem. -- Please keep replies on the mailing list.
Re: volatility or something like that in the future ?
On Fri, Aug 18, 2023 at 01:31:41PM +, whistlez wrote:
> Il 2023-08-18 09:22 Omar Polo ha scritto:
> > On 2023/08/18 02:06:11 +, whistlez wrote:
> >> Il 2023-08-18 02:20 Scott Cheloha ha scritto:
> >> >> On Aug 17, 2023, at 10:28, whistlez wrote:
> >>
> >> 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.
> >
> > Assuming that the kernel was compromised, how can you trust a tool to
> > detect that? The compromised kernel could return normal-looking data
> > through /dev/{k,}mem (ignoring for a moment the perils of allowing
> > random software to access these devices.) You'd be asking a liar if
> > they're telling the truth :)
>
> Yes, I understand exactly what you're saying, and I partly agree, but
> I'd like to share some thoughts. However, first and foremost, I want to
> reiterate that I'm not a developer, and for this reason, my statements
> might be based on entirely erroneous assumptions. But let's get to the
> considerations.
>
> 1. Volatility allows the detection of hidden kernel modules in a Linux
> environment, including typical LKM rootkits.
>
> 2. There are multiple methods for RAM dumping, some of which cannot be
> circumvented and do not require specific software or interfaces. For
> example:
> a. Through a 'cold boot attack,' it's possible to dump RAM from an
> uncompromised operating system. (Reference:
> https://en.wikipedia.org/wiki/Cold_boot_attack)
> b. Through a DMA attack, leveraging FireWire or other hardware
> interfaces, it's possible to dump RAM. I believe that, in this case, as
> in the previous one, the kernel would be completely unaware. An example
> of this kind of attack and dump is "inception"
> (https://github.com/carmaa/inception).
> c. In a virtualized environment such as VMM, VirtualBox, VMware,
> etc. (we know OpenBSD can be virtualized), you can acquire RAM without
> the operating system knowing.
Great, sounds like you've stumbled across 3 solutions for your problem.
Looks like no diff is needed after all.
>
> 3. The third consideration relates to what you said – that it doesn't
> make sense to ask a liar if he is lying. I think, similar to how the
> police operate, you can ask a suspect a series of questions, and all
> answers should exhibit a certain logical consistency. If you want to
> make a neighborhood disappear from a city, you can't just dig a hole.
> Because everyone will understand that it can't be true. Roads will
> terminate at the hole and continue on the other side, and that doesn't
> make sense. Moral of the story: the more you have to hide, the more code
> you have to write to make your façade believable. And so, the more
> questions you ask the suspect, the more they have to invent lies that
> are consistent. The more lies there are, the greater the chances of
> creating a discrepancy in the infrastructure. For instance, library,
> memory, pointers must be reorganized coherently. You can't make a
> pointer point to a memory area that is empty.
>
> 4. Another thing we can't ignore is that we all know there are no
> definitive security solutions, only building bricks that add layers of
> difficulty and complicate matters for an attacker. Keeping hidden code
> within a kernel while simultaneously ensuring that code performs actions
> is an additional layer of difficulty.
>
Re: riscv questions
On Fri, Aug 18, 2023 at 06:44:48AM +0200, Peter J. Philipp wrote: > 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 :-). > arm64 is first but the separation work was done already. There are about two dozen functions that need to be implemented in the kernel, plus a bunch of work in vmd. > 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 It wasn't a workgroup. It was a group of four full time students working on their master's degrees as a final project. It took six months, more or less, and at that time we barely could print hello world from userland. It was another 6-12 months after that before it was stable, thanks to many other developers. > 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'm prioritizing arm64 at this point, there isn't much value in porting vmm to hardware that is way too slow to matter (and I am unsure if such hardware even exists). powerpc64 is another choice, it has virtualization support, as do some octeons. We have real hardware for those, too. That said, if a diff appeared on tech@, I'd certainly take a look at it. > > > > > > > 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.
Re: volatility or something like that in the future ?
Il 2023-08-18 09:22 Omar Polo ha scritto:
> On 2023/08/18 02:06:11 +, whistlez wrote:
>> Il 2023-08-18 02:20 Scott Cheloha ha scritto:
>> >> On Aug 17, 2023, at 10:28, whistlez wrote:
>>
>> 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.
>
> Assuming that the kernel was compromised, how can you trust a tool to
> detect that? The compromised kernel could return normal-looking data
> through /dev/{k,}mem (ignoring for a moment the perils of allowing
> random software to access these devices.) You'd be asking a liar if
> they're telling the truth :)
Yes, I understand exactly what you're saying, and I partly agree, but
I'd like to share some thoughts. However, first and foremost, I want to
reiterate that I'm not a developer, and for this reason, my statements
might be based on entirely erroneous assumptions. But let's get to the
considerations.
1. Volatility allows the detection of hidden kernel modules in a Linux
environment, including typical LKM rootkits.
2. There are multiple methods for RAM dumping, some of which cannot be
circumvented and do not require specific software or interfaces. For
example:
a. Through a 'cold boot attack,' it's possible to dump RAM from an
uncompromised operating system. (Reference:
https://en.wikipedia.org/wiki/Cold_boot_attack)
b. Through a DMA attack, leveraging FireWire or other hardware
interfaces, it's possible to dump RAM. I believe that, in this case, as
in the previous one, the kernel would be completely unaware. An example
of this kind of attack and dump is "inception"
(https://github.com/carmaa/inception).
c. In a virtualized environment such as VMM, VirtualBox, VMware,
etc. (we know OpenBSD can be virtualized), you can acquire RAM without
the operating system knowing.
3. The third consideration relates to what you said – that it doesn't
make sense to ask a liar if he is lying. I think, similar to how the
police operate, you can ask a suspect a series of questions, and all
answers should exhibit a certain logical consistency. If you want to
make a neighborhood disappear from a city, you can't just dig a hole.
Because everyone will understand that it can't be true. Roads will
terminate at the hole and continue on the other side, and that doesn't
make sense. Moral of the story: the more you have to hide, the more code
you have to write to make your façade believable. And so, the more
questions you ask the suspect, the more they have to invent lies that
are consistent. The more lies there are, the greater the chances of
creating a discrepancy in the infrastructure. For instance, library,
memory, pointers must be reorganized coherently. You can't make a
pointer point to a memory area that is empty.
4. Another thing we can't ignore is that we all know there are no
definitive security solutions, only building bricks that add layers of
difficulty and complicate matters for an attacker. Keeping hidden code
within a kernel while simultaneously ensuring that code performs actions
is an additional layer of difficulty.
Why does `pkg_info -m` show quirks?
Hey, according to pkg_info(1) the -m options "shows the names and one-line comments for all packages tagged as manually installed". However, executing `pkg_info -m` shows the quirks package, which is clearly not "manually installed". According to it's package description: "pkg_add(1) always installs and updates it automatically". Can a package be tagged either as manually installed or as a dependency and as quirks is not a dependency, it is tagged as manually installed? If this is so, it seems to make sense that is tagged as manually installed. However, what do you think about not showing quirks when executing `pkg_info -mz`, as this is intended to "be reused with pkg_add(1) -l to recreate a package installation"? Similarly to how firmware is not shown. This would resemble the behaviour I expect from `pkg_info -mz`. Also, what is the reason the quirks package does not have a man page? I believe it should have one, just like any other program. Is this something that is desired? If so, I would gladly model one after the package description. Kind regards, Leo
Re: volatility or something like that in the future ?
On Fri, Aug 18, 2023 at 2:22 AM Scott Cheloha wrote: > > > 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. Agreed. After reading their FAQ I still don't understand - it's most definitely a made-up FAQ of questions no one asked, but things they want to tell. One thing that sticks out to me is that they felt the need to make up their own custom license, the Volatility Software License. Doing something like that in 2019 seems a bit weird.
Re: AR9485 on Lenovo G505 not configured.
On 2023-08-18, m...@emailgroups.net wrote: > 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. It could work, but someone would need to add support, probably to ath(4), and without breaking things for other devices. I doubt things changed since https://marc.info/?l=openbsd-tech=139963461524621=2 If you can't change the card I suggest an 11n USB wifi adapter (*not* 11ac, no driver support for most 11ac USB on OpenBSD, 11n USB are much more likely to work).
Re: volatility or something like that in the future ?
On 2023/08/18 02:06:11 +, whistlez wrote:
> 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.
Assuming that the kernel was compromised, how can you trust a tool to
detect that? The compromised kernel could return normal-looking data
through /dev/{k,}mem (ignoring for a moment the perils of allowing
random software to access these devices.) You'd be asking a liar if
they're telling the truth :)
