macppc install56.iso - CD issues
Hi, I must be doing something wrong here and need some hints to figure out what. My attempts to burn macppc install56.iso to a CD seems to produce un-bootable discs. I'm using cdrecord(1) to perform the burns. At the Open Firmware prompt I issue: 0 boot cd:,ofwboot /5.6/macppc/bsd.rd and that results in: DISK-LABEL: read of block0 failed ATAPI-DISK: open of DISK-LABEL failed can't OPEN: cd:,ofwboot Can't open device or file ok 0 I went through four different burn attempts; one with Dec 7th snapshot. And three right now with Dec 8th one. I tested with official 5.6 CD and that CD boots just fine. This is how the image was burned to disc: # cdrecord -v dev=/dev/rcd0c install56.iso cdrecord: No write mode specified. cdrecord: Assuming -sao mode. cdrecord: If your drive does not accept -sao, try -tao. cdrecord: Future versions of cdrecord may have different drive dependent default s. Cdrecord-ProDVD-ProBD-Clone 3.00 (amd64-unknown-openbsd5.6) Copyright (C) 1995-2 [...] BURN-Free is ON. Turning BURN-Free off Performing OPC... Sending CUE sheet... cdrecord: WARNING: Drive returns wrong startsec (0) using -150 Writing pregap for track 1 at -150 Starting new track at sector: 0 Track 01: 218 of 218 MB written (fifo 100%) [buf 99%] 33.1x. Track 01: Total bytes read/written: 228696064/228696064 (111668 sectors). Writing time: 75.670s Average write speed 22.3x. Min drive buffer fill was 97% Fixating... Fixating time:3.591s cdrecord: fifo had 3723 puts and 3723 gets. cdrecord: fifo was 0 times empty and 1843 times full, min fill was 95%. # echo $? 0 Note the WARNING. Also note that burning an amd64 image works just fine (with same WARNING during cdrecord phase). On a related note, how can base tools (cdio(1)?) be used instead of cdrecord(1) (from ports) to burn these images to disc? Thanks in advance, --patrick
Re: macppc install56.iso - CD issues
On Tue, 9 Dec 2014, patrick keshishian wrote: From: patrick keshishian pkesh...@gmail.com To: misc misc@openbsd.org Date: Tue, 9 Dec 2014 08:10:43 Subject: macppc install56.iso - CD issues ... On a related note, how can base tools (cdio(1)?) be used instead of cdrecord(1) (from ports) to burn these images to disc? As described in the FAQ, 4.3.1 - Making a CD-ROM ? -- Dennis Davis dennisda...@fastmail.fm
Re: macppc install56.iso - CD issues
On 12/09/14 08:10, patrick keshishian wrote: Hi, I must be doing something wrong here and need some hints to figure out what. My attempts to burn macppc install56.iso to a CD seems to produce un-bootable discs. I'm using cdrecord(1) to perform the burns. At the Open Firmware prompt I issue: 0 boot cd:,ofwboot /5.6/macppc/bsd.rd and that results in: DISK-LABEL: read of block0 failed ATAPI-DISK: open of DISK-LABEL failed can't OPEN: cd:,ofwboot Can't open device or file ok 0 I went through four different burn attempts; one with Dec 7th snapshot. And three right now with Dec 8th one. I tested with official 5.6 CD and that CD boots just fine. This is how the image was burned to disc: # cdrecord -v dev=/dev/rcd0c install56.iso cdrecord: No write mode specified. cdrecord: Assuming -sao mode. cdrecord: If your drive does not accept -sao, try -tao. cdrecord: Future versions of cdrecord may have different drive dependent default s. Cdrecord-ProDVD-ProBD-Clone 3.00 (amd64-unknown-openbsd5.6) Copyright (C) 1995-2 [...] BURN-Free is ON. Turning BURN-Free off Performing OPC... Sending CUE sheet... cdrecord: WARNING: Drive returns wrong startsec (0) using -150 Writing pregap for track 1 at -150 Starting new track at sector: 0 Track 01: 218 of 218 MB written (fifo 100%) [buf 99%] 33.1x. Track 01: Total bytes read/written: 228696064/228696064 (111668 sectors). Writing time: 75.670s Average write speed 22.3x. Min drive buffer fill was 97% Fixating... Fixating time:3.591s cdrecord: fifo had 3723 puts and 3723 gets. cdrecord: fifo was 0 times empty and 1843 times full, min fill was 95%. # echo $? 0 Note the WARNING. Also note that burning an amd64 image works just fine (with same WARNING during cdrecord phase). On a related note, how can base tools (cdio(1)?) be used instead of cdrecord(1) (from ports) to burn these images to disc? Thanks in advance, --patrick Hi, What happens when you hold the 'c' key during reboot? If you mount the disks under a working system is ofwboot in the / ? hth Fred
Re: macppc install56.iso - CD issues
Check out http://www.openbsd.org/faq/faq4.html#MkCD-ROM and faq13. It reads: # cdio tao cd56.iso Regards
Re: OpenBSD 5.6/current on Soekris 6501-70
On 2014-12-08 05:03, Stuart Henderson wrote: On 2014-12-08, Martin Hanson greencopperm...@yandex.com wrote: I would like to be able to run ~100-120 MB/s from one NIC to the other on this box, if possible? MB/s (megabytes): no. Mb/s (megabits): yes. I second that. Even using no pf rules, can't reach 1Gbps rates. See the manual before buying, its internal buses are thin :) matheus -- We will call you Cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style
simple way to block one word domains?
Curious if anyone knows a simple way to prevent resolution of one word hostnames. Either via resolv.conf or unbound.conf. For example: athens:~ host android android has address 127.0.53.53 android mail is handled by 10 your-dns-needs-immediate-attention.android. I do not like this. athens:~ host bobo Host bobo not found: 3(NXDOMAIN) This is much better. athens:~ host com This isn't great either. I realize this is how DNS works, but I also think it's something I should be able to fix at a local level. The fact that anything and everything can now be a TLD is pretty sneaky. If a DNS lookup has only a single part, I would like to restrict it to the search domain.
Re: simple way to block one word domains?
Does ndots:0 in your resolv.conf not achieve what you want? -- Josh Smith KD8HRX Email/jabber: juice...@gmail.com Phone: 304.237.9369(c) Sent from my iPhone. On Dec 9, 2014, at 11:01 AM, Ted Unangst t...@tedunangst.com wrote: Curious if anyone knows a simple way to prevent resolution of one word hostnames. Either via resolv.conf or unbound.conf. For example: athens:~ host android android has address 127.0.53.53 android mail is handled by 10 your-dns-needs-immediate-attention.android. I do not like this. athens:~ host bobo Host bobo not found: 3(NXDOMAIN) This is much better. athens:~ host com This isn't great either. I realize this is how DNS works, but I also think it's something I should be able to fix at a local level. The fact that anything and everything can now be a TLD is pretty sneaky. If a DNS lookup has only a single part, I would like to restrict it to the search domain.
Re: simple way to block one word domains?
On Tue, 9 Dec 2014, Ted Unangst wrote: Curious if anyone knows a simple way to prevent resolution of one word hostnames. Either via resolv.conf or unbound.conf. For example: athens:~ host android android has address 127.0.53.53 android mail is handled by 10 your-dns-needs-immediate-attention.android. I do not like this. athens:~ host bobo Host bobo not found: 3(NXDOMAIN) This is much better. athens:~ host com This isn't great either. I realize this is how DNS works, but I also think it's something I should be able to fix at a local level. The fact that anything and everything can now be a TLD is pretty sneaky. If a DNS lookup has only a single part, I would like to restrict it to the search domain. I'm by no means a DNS expert but I've been dealing with it for a long time. The only thing I can think of to force one word hostnames to be resolved in the search domain exclusively would be to patch the resolver library. If you find an answer please do pass it along because I might be interested in putting that in place on a few machines. Probably the best solution would be a patch to the resolver library that adds an option to resolv.conf(5) that allows it to easily be turned on/off. The only question is would this break things? Maybe it would require a bypass list of TLDs in a file like /etc/resolv_tlds.conf? -- John Merriam j...@johnmerriam.net
Hide VM data from customer
Hi everyone, We use OpenBSD currently on physical hardware and manage it in our customers location. We want the option to give out VMs to host on customer premises and we'll still manage the VM (but not the VM platform). The problem is not letting the customer access to our proprietary data as they could easily mount the virtual hard drive somewhere else. The obvious answer is disk encryption, but we can't require manual intervention to enter a passphrase or to provide a key. I'm sure I'll have to settle with obfuscation, which I'm OK with, but I'm curious if there is a good/best way to go about that. Is the only option to change things we need to hide into binaries? Compile the kernel with a key to decrypt? I've taken a look at how other vendors do it like Juniper. With their VM I can mount the boot partitions, but they only have boot information and the kernel. I can't mount the extended partitions, they don't even seem to be formatted with a filesystem. My guess is they compile the kernel with a key or something, but its just a guess. Thanks for any advice! Nate
Re: macppc install56.iso - CD issues
Hi Fred, On 12/9/14, Fred open...@crowsons.com wrote: On 12/09/14 08:10, patrick keshishian wrote: Hi, I must be doing something wrong here and need some hints to figure out what. My attempts to burn macppc install56.iso to a CD seems to produce un-bootable discs. I'm using cdrecord(1) to perform the burns. At the Open Firmware prompt I issue: 0 boot cd:,ofwboot /5.6/macppc/bsd.rd and that results in: DISK-LABEL: read of block0 failed ATAPI-DISK: open of DISK-LABEL failed can't OPEN: cd:,ofwboot Can't open device or file ok 0 I went through four different burn attempts; one with Dec 7th snapshot. And three right now with Dec 8th one. I tested with official 5.6 CD and that CD boots just fine. This is how the image was burned to disc: # cdrecord -v dev=/dev/rcd0c install56.iso cdrecord: No write mode specified. cdrecord: Assuming -sao mode. cdrecord: If your drive does not accept -sao, try -tao. cdrecord: Future versions of cdrecord may have different drive dependent default s. Cdrecord-ProDVD-ProBD-Clone 3.00 (amd64-unknown-openbsd5.6) Copyright (C) 1995-2 [...] BURN-Free is ON. Turning BURN-Free off Performing OPC... Sending CUE sheet... cdrecord: WARNING: Drive returns wrong startsec (0) using -150 Writing pregap for track 1 at -150 Starting new track at sector: 0 Track 01: 218 of 218 MB written (fifo 100%) [buf 99%] 33.1x. Track 01: Total bytes read/written: 228696064/228696064 (111668 sectors). Writing time: 75.670s Average write speed 22.3x. Min drive buffer fill was 97% Fixating... Fixating time:3.591s cdrecord: fifo had 3723 puts and 3723 gets. cdrecord: fifo was 0 times empty and 1843 times full, min fill was 95%. # echo $? 0 Note the WARNING. Also note that burning an amd64 image works just fine (with same WARNING during cdrecord phase). On a related note, how can base tools (cdio(1)?) be used instead of cdrecord(1) (from ports) to burn these images to disc? Thanks in advance, --patrick Hi, What happens when you hold the 'c' key during reboot? I get gray screen with folder and flashing ?. If you mount the disks under a working system is ofwboot in the / ? Yes sir. $ sudo mount /dev/cd0a /mnt/cd $ ls /mnt/cd 5.6/ ofwboot --patrick hth Fred
Re: macppc install56.iso - CD issues
On 12/9/14, Maurice McCarthy m...@mythic-beasts.com wrote: Check out http://www.openbsd.org/faq/faq4.html#MkCD-ROM and faq13. It reads: # cdio tao cd56.iso Thanks Maurice and Dennis for point me to the FAQ on cdio(1) usage. Richard Toohey was first to respond in private with the hint as well. I didn't want to muddy the unbootable iso image issue with cdio(1) usage, so I didn't mention that I had tried the following based on reading cdio(1) man-page: $ sudo cdio -v -f /dev/rcd0c tao -d install56.iso Features: 0x Profile List (60 bytes of data) * 0x0009 Write once Compact Disc [Current Profile] 0x0001 Core (8 bytes of data) 0x0002 Morphing (4 bytes of data) 0x0003 Removable Medium (4 bytes of data) 0x0021 Incremental Streaming Writable (8 bytes of data) 0x002d CD Track at Once (TAO) (4 bytes of data) 0x002e CD Mastering (Session at Once) (4 bytes of data) 0x0100 Power Management 0x0105 Timeout (4 bytes of data) 0x0107 Real Time Streaming (4 bytes of data) 0x0108 Drive Serial Number (12 bytes of data) 0x010c Firmware Information (16 bytes of data) cdio: mode select failed: 3 I just assumed I was missing something subtle in its usage or perhaps another needed tool. I should have verified with the FAQ indeed. --patrick Regards
Re: Hide VM data from customer
On Tue, 9 Dec 2014, Nathan Wheeler wrote: Hi everyone, We use OpenBSD currently on physical hardware and manage it in our customers location. We want the option to give out VMs to host on customer premises and we'll still manage the VM (but not the VM platform). The problem is not letting the customer access to our proprietary data as they could easily mount the virtual hard drive somewhere else. The obvious answer is disk encryption, but we can't require manual intervention to enter a passphrase or to provide a key. I'm sure I'll have to settle with obfuscation, which I'm OK with, but I'm curious if there is a good/best way to go about that. Is the only option to change things we need to hide into binaries? Compile the kernel with a key to decrypt? I've taken a look at how other vendors do it like Juniper. With their VM I can mount the boot partitions, but they only have boot information and the kernel. I can't mount the extended partitions, they don't even seem to be formatted with a filesystem. My guess is they compile the kernel with a key or something, but its just a guess. Thanks for any advice! Nate You said that you are already letting your proprietary data out in the wild since you have machines on customer premises with this data in unencrypted form. If it moves from a physical machine to a virtual one it is true that it makes it easier for someone to access it but not that much easier. Anyway, the way I see it, the only way to keep someone from accessing your data is encryption. Obfuscation alone will make it harder but not impossible. To avoid manual intervention when using encryption you need a way to get the key/passphrase to the machine/application. If you were using application/file level encryption, you could compile the key in to a binary application that would then work with the data. That is still obfucation to an extent because they could still decompile the binary and find your key. Another option I just thought of is if you coded your application that accesses the data to download (over an encrypted connection of course...) the key from a server that you control at your location that the application would then use to decrypt the data. If you wanted to use FDE without manual intervention you would need to modify the OS source to find the key somewhere (unallocated sectors at the end of the disk or between partitions?) that it could access before it tries to decrypt the partition. Obfuscation again. But pretty well obfuscated. Another thing you could do is have a separate partition that is not the boot partition (like /data) that is encrypted and have the boot scripts decrypt and mount the partition. You would need to cary around the passphrase/key on the unencrypted boot partition though. Obfuscaction again (but maybe you could combine this with downloading the key/pass from a server of yours?). The only thing I mentioned that doesn't involve obfuscation or manual intervention is coding an/your application that will download the key from a server to decrypt the data that has been encrypted. You would need to use something like HTTPS with username/password or SCP to transfer the key. The server serving the key should have access to it restricted by IP. Oh, but wait, they could still get the key if they decompile the program that downloads the key and do exactly what it does. Hmmm, still obfuscation I guess. Oh, and no matter what you do, they could always dump the RAM from your VM instance and get your data from there after it's been decrypted. So, yeah, no really good answer that I know of. I'm not an expert in areas such as this, but this is the way I see it. Your best bet is probably encryption combined with some good obfuscation as to what the key is/where to get it. Not moving your data to a VM would make some of these attacks harder but not impossible for a determined attacker. -- John Merriam
Re: macppc install56.iso - CD issues
On 12/09/14 19:07, patrick keshishian wrote: Hi Fred, On 12/9/14, Fred open...@crowsons.com wrote: On 12/09/14 08:10, patrick keshishian wrote: Hi, I must be doing something wrong here and need some hints to figure out what. My attempts to burn macppc install56.iso to a CD seems to produce un-bootable discs. I'm using cdrecord(1) to perform the burns. At the Open Firmware prompt I issue: 0 boot cd:,ofwboot /5.6/macppc/bsd.rd and that results in: DISK-LABEL: read of block0 failed ATAPI-DISK: open of DISK-LABEL failed can't OPEN: cd:,ofwboot Can't open device or file ok 0 I went through four different burn attempts; one with Dec 7th snapshot. And three right now with Dec 8th one. I tested with official 5.6 CD and that CD boots just fine. This is how the image was burned to disc: # cdrecord -v dev=/dev/rcd0c install56.iso cdrecord: No write mode specified. cdrecord: Assuming -sao mode. cdrecord: If your drive does not accept -sao, try -tao. cdrecord: Future versions of cdrecord may have different drive dependent default s. Cdrecord-ProDVD-ProBD-Clone 3.00 (amd64-unknown-openbsd5.6) Copyright (C) 1995-2 [...] BURN-Free is ON. Turning BURN-Free off Performing OPC... Sending CUE sheet... cdrecord: WARNING: Drive returns wrong startsec (0) using -150 Writing pregap for track 1 at -150 Starting new track at sector: 0 Track 01: 218 of 218 MB written (fifo 100%) [buf 99%] 33.1x. Track 01: Total bytes read/written: 228696064/228696064 (111668 sectors). Writing time: 75.670s Average write speed 22.3x. Min drive buffer fill was 97% Fixating... Fixating time:3.591s cdrecord: fifo had 3723 puts and 3723 gets. cdrecord: fifo was 0 times empty and 1843 times full, min fill was 95%. # echo $? 0 Note the WARNING. Also note that burning an amd64 image works just fine (with same WARNING during cdrecord phase). On a related note, how can base tools (cdio(1)?) be used instead of cdrecord(1) (from ports) to burn these images to disc? Thanks in advance, --patrick Hi, What happens when you hold the 'c' key during reboot? I get gray screen with folder and flashing ?. I have had that when I messed up an install (I dual boot my iBook) and ended up to use my Mac OS X disks to reformat the drive - with a bigger OpenBSD partition. There used to be apple support article on their NVRAM instructions - but my apple / google foo is not finding it which you can use to boot from other devices. I did find this article in my search - but I'm not sure it links to anything useful... http://support.apple.com/en-us/ts2570 hth Fred
Re: macppc install56.iso - CD issues
On 12/9/14, Fred open...@crowsons.com wrote: On 12/09/14 19:07, patrick keshishian wrote: On 12/9/14, Fred open...@crowsons.com wrote: What happens when you hold the 'c' key during reboot? I get gray screen with folder and flashing ?. I have had that when I messed up an install (I dual boot my iBook) and ended up to use my Mac OS X disks to reformat the drive - with a bigger OpenBSD partition. Not quite the situation with my macppc, as it is not dual booting and it is dealing with CD media not HDD. I believe the issue has to do with the newly burned CD or the source install56.iso image. As I pointed out the official 5.6 CD boots just fine. Later I also don't think it is the CD-R media, as I verified I can burn an amd64 image (install56.iso file) and it boots fine (on an amd64 hw of course). Best, --patrick
Re: Hide VM data from customer
Thank John! Sounds like the best way is to compile a key into a binary and decrypt partitions or files that way. I'm certain obfuscation is my only real option without manual intervention, and I'm OK with that. I know it won't actually be secure. Mostly I just want to stop curious eyes, I don't need to stop someone really determined. I just want to make sure there isn't some standard way to obfuscate partitions/data in VMs used as appliances. On Tue, Dec 9, 2014 at 11:38 AM, John Merriam j...@johnmerriam.net wrote: On Tue, 9 Dec 2014, Nathan Wheeler wrote: Hi everyone, We use OpenBSD currently on physical hardware and manage it in our customers location. We want the option to give out VMs to host on customer premises and we'll still manage the VM (but not the VM platform). The problem is not letting the customer access to our proprietary data as they could easily mount the virtual hard drive somewhere else. The obvious answer is disk encryption, but we can't require manual intervention to enter a passphrase or to provide a key. I'm sure I'll have to settle with obfuscation, which I'm OK with, but I'm curious if there is a good/best way to go about that. Is the only option to change things we need to hide into binaries? Compile the kernel with a key to decrypt? I've taken a look at how other vendors do it like Juniper. With their VM I can mount the boot partitions, but they only have boot information and the kernel. I can't mount the extended partitions, they don't even seem to be formatted with a filesystem. My guess is they compile the kernel with a key or something, but its just a guess. Thanks for any advice! Nate You said that you are already letting your proprietary data out in the wild since you have machines on customer premises with this data in unencrypted form. If it moves from a physical machine to a virtual one it is true that it makes it easier for someone to access it but not that much easier. Anyway, the way I see it, the only way to keep someone from accessing your data is encryption. Obfuscation alone will make it harder but not impossible. To avoid manual intervention when using encryption you need a way to get the key/passphrase to the machine/application. If you were using application/file level encryption, you could compile the key in to a binary application that would then work with the data. That is still obfucation to an extent because they could still decompile the binary and find your key. Another option I just thought of is if you coded your application that accesses the data to download (over an encrypted connection of course...) the key from a server that you control at your location that the application would then use to decrypt the data. If you wanted to use FDE without manual intervention you would need to modify the OS source to find the key somewhere (unallocated sectors at the end of the disk or between partitions?) that it could access before it tries to decrypt the partition. Obfuscation again. But pretty well obfuscated. Another thing you could do is have a separate partition that is not the boot partition (like /data) that is encrypted and have the boot scripts decrypt and mount the partition. You would need to cary around the passphrase/key on the unencrypted boot partition though. Obfuscaction again (but maybe you could combine this with downloading the key/pass from a server of yours?). The only thing I mentioned that doesn't involve obfuscation or manual intervention is coding an/your application that will download the key from a server to decrypt the data that has been encrypted. You would need to use something like HTTPS with username/password or SCP to transfer the key. The server serving the key should have access to it restricted by IP. Oh, but wait, they could still get the key if they decompile the program that downloads the key and do exactly what it does. Hmmm, still obfuscation I guess. Oh, and no matter what you do, they could always dump the RAM from your VM instance and get your data from there after it's been decrypted. So, yeah, no really good answer that I know of. I'm not an expert in areas such as this, but this is the way I see it. Your best bet is probably encryption combined with some good obfuscation as to what the key is/where to get it. Not moving your data to a VM would make some of these attacks harder but not impossible for a determined attacker. -- John Merriam
Re: macppc install56.iso - CD issues
On 12/09/14 20:51, patrick keshishian wrote: On 12/9/14, Fred open...@crowsons.com wrote: On 12/09/14 19:07, patrick keshishian wrote: On 12/9/14, Fred open...@crowsons.com wrote: What happens when you hold the 'c' key during reboot? I get gray screen with folder and flashing ?. I have had that when I messed up an install (I dual boot my iBook) and ended up to use my Mac OS X disks to reformat the drive - with a bigger OpenBSD partition. Not quite the situation with my macppc, as it is not dual booting and it is dealing with CD media not HDD. I believe the issue has to do with the newly burned CD or the source install56.iso image. As I pointed out the official 5.6 CD boots just fine. Later I also don't think it is the CD-R media, as I verified I can burn an amd64 image (install56.iso file) and it boots fine (on an amd64 hw of course). Best, --patrick Using: -rw-r--r--1 ftp ftp 228696064 Dec 09 01:32 install56.iso from mirror.ox.ac.uk - I have successfully upgraded by burning a cdrom: ibook:fred ~ uname -a; dmesg|head OpenBSD ibook.crowsons.com 5.6 GENERIC#344 macppc [ using 551184 bytes of bsd ELF symbol table ] console out [ATY,Via_A]console in [keyboard] , using ADB using parent ATY,ViaParent:: memaddr 9800 size 800, : consaddr 9c008000, : ioaddr 9002, size 2: width 1024 linebytes 1024 height 768 depth 8 Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2014 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 5.6-current (GENERIC) #344: Mon Dec 8 17:57:34 MST 2014 dera...@macppc.openbsd.org:/usr/src/sys/arch/macppc/compile/GENERIC real mem = 536870912 (512MB) Cheers Fred
Re: Hide VM data from customer
On 12/9/2014 2:38 PM, John Merriam wrote: Oh, and no matter what you do, they could always dump the RAM from your VM instance and get your data from there after it's been decrypted. The key is also likely stored in RAM, and it is simpler to get a snapshot of RAM from a VM than it is to get one from a physical machine.
Re: Hide VM data from customer
One of the services provided by a previous employer was to on-premise appliance for customers, rented in a SAAS model. Customers paid for a certain amount of disk space. To ensure they couldn’t just swap disks to add more capacity, each of our disks went through a ‘blessing’ process where we performed various interesting perturbations to the first few megs of every disk, including a checksum that was a function of a machine and customer identifier. We fully understood that these efforts would never get in the way of a dedicated and sophisticated adversary, but the bar was low since most of the customers were end users who were using a managed service provider and never directly interacted with our appliance. You might want to try something like that to make it non-trivial for customers to pull your data. - Eric On Dec 9, 2014, at 4:14 PM, Steve Shockley steve.shock...@shockley.net wrote: On 12/9/2014 2:38 PM, John Merriam wrote: Oh, and no matter what you do, they could always dump the RAM from your VM instance and get your data from there after it's been decrypted. The key is also likely stored in RAM, and it is simpler to get a snapshot of RAM from a VM than it is to get one from a physical machine.
Re: macppc install56.iso - CD issues
On 12/9/14, Fred Crowson f...@crowsons.net wrote: On 12/09/14 20:51, patrick keshishian wrote: On 12/9/14, Fred open...@crowsons.com wrote: On 12/09/14 19:07, patrick keshishian wrote: On 12/9/14, Fred open...@crowsons.com wrote: What happens when you hold the 'c' key during reboot? I get gray screen with folder and flashing ?. I have had that when I messed up an install (I dual boot my iBook) and ended up to use my Mac OS X disks to reformat the drive - with a bigger OpenBSD partition. Not quite the situation with my macppc, as it is not dual booting and it is dealing with CD media not HDD. I believe the issue has to do with the newly burned CD or the source install56.iso image. As I pointed out the official 5.6 CD boots just fine. Later I also don't think it is the CD-R media, as I verified I can burn an amd64 image (install56.iso file) and it boots fine (on an amd64 hw of course). Best, --patrick Hi Fred, Using: -rw-r--r--1 ftp ftp 228696064 Dec 09 01:32 install56.iso from mirror.ox.ac.uk - I have successfully upgraded by burning a cdrom: Thanks for *this* info. I was hoping someone would provide something like this. That's the exact install56.iso I was using yesterday from Colorado (US) mirror (IIRC): $ cksum -a sha256 install56.iso SHA256 (install56.iso) = 586ab0c9d30fba85c19e6c45071fc0dfbe78190bfaf89f244bfbebceeae611ff $ strings 5.6/macppc/bsd* | grep -A1 ^OpenBSD\ 5.6-current OpenBSD 5.6-current (GENERIC) #344: Mon Dec 8 17:57:34 MST 2014 dera...@macppc.openbsd.org:/usr/src/sys/arch/macppc/compile/GENERIC OpenBSD 5.6-current (GENERIC.MP) #396: Mon Dec 8 18:14:39 MST 2014 dera...@macppc.openbsd.org:/usr/src/sys/arch/macppc/compile/GENERIC.MP OpenBSD 5.6-current (RAMDISK) #344: Mon Dec 8 18:30:19 MST 2014 dera...@macppc.openbsd.org:/usr/src/sys/arch/macppc/compile/RAMDISK ibook:fred ~ uname -a; dmesg|head OpenBSD ibook.crowsons.com 5.6 GENERIC#344 macppc [ using 551184 bytes of bsd ELF symbol table ] console out [ATY,Via_A]console in [keyboard] , using ADB using parent ATY,ViaParent:: memaddr 9800 size 800, : consaddr 9c008000, : ioaddr 9002, size 2: width 1024 linebytes 1024 height 768 depth 8 Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2014 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 5.6-current (GENERIC) #344: Mon Dec 8 17:57:34 MST 2014 dera...@macppc.openbsd.org:/usr/src/sys/arch/macppc/compile/GENERIC real mem = 536870912 (512MB) Could the issue be the CD drive in the box? (this is on a Mac mini G4) It is starting to look that way, except the fact it boots with the official 5.6 CD :-) Couple of experiments I just did: Pulled my iBook G4 out and it seems OK with the burned CD image. so... macmini boot off of official 5.6 CD macmini drop down to shell macmini disklabel cd0 # /dev/rcd0c: type: ATAPI disk: OpenBSD5.6 CD 2 label: www.OpenBSD.org duid: flags: bytes/sector: 2048 sectors/track: 100 tracks/cylinder: 1 sectors/cylinder: 100 cylinders: 3255 total sectors: 325488 boundstart:0 boundend: 325488 drivedata: 0 16 partitions: #size offset fstype [fsize bsize cpg] a: 3254880 ISO9660 c: 3254880 ISO9660 macmini eject cd0 - insert burnt CD (that doesn't boot) macmini disklabel cd0 # /dev/rcd0c: type: ATAPI disk: ATAPI CD-ROM label: fictitious duid: flags: bytes/sector: 2048 sectors/track: 100 tracks/cylinder: 1 sectors/cylinder: 100 cylinders: 4001 total sectors: 40 boundstart: 0 boundend: 0 drivedata: 0 0 partitions: #size offset fstype [fsize bsize cpg] macmini eject cd0 - insert it into iBook ibook disklabel cd0 # /dev/rcd0c: type: ATAPI disk: OpenBSD/macppc label: 5.6 install CD duid: flags: bytes/sector: 2048 sectors/track: 100 tracks/cylinder: 1 sectors/cylinder: 100 cylinders: 1117 total sectors: 111664 boundstart: 0 boundend: 111664 drivedata: 0 16 partitions: #size offset fstype [fsize bsize cpg] a: 1116640 ISO9660 c: 1116640 ISO9660 I don't understand this. The Mac mini isn't seeing the burnt media. It has in the past, as I have/had a May 4th 2014 snapshot on it. Thanks for persisting Fred. If anyone has any ideas ... --patrick
Re: Proposed patch to unmute Azalia sound card on Compaq 610
On Tue, Dec 09, 2014 at 07:31:47AM +0100, Alessandro DE LAURENZIS wrote:
Hi Jonathan,
On Tue 09/12 16:03, Jonathan Gray wrote:
I'm curious why you decided to mask the subid here and not just test
subid == 0x308a103c ?
In my understanding (I'm definitely not an expert), the last part of
subid represents the vendor signature (HP in this case); the first 4
digits should be instead specific to the particular chip implementation.
Here I just tried to make the patch more general (guessing that the GPIO
needs to be unmuted for all IDT 92HD75B1/2-type cards sold by HP), and
also to stay close to code style adopted for other (similar?) cases.
If my assumption is wrong, then yes, you're right: the whole subid
should be tested.
Anyhow, thanks for your feedback.
All the best
I've found a few other mentions with different subids that look like
they need the mask.
HP Mini 5102
http://marc.info/?l=openbsd-miscm=130937855423807w=2
HP Mini 1000
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/318942
So I'll commit your original patch, included below as
the original didn't apply cleanly here.
Please send patches to tech@ or bugs@ in future.
Index: azalia_codec.c
===
RCS file: /cvs/src/sys/dev/pci/azalia_codec.c,v
retrieving revision 1.164
diff -u -p -r1.164 azalia_codec.c
--- azalia_codec.c 17 Nov 2014 16:34:51 - 1.164
+++ azalia_codec.c 10 Dec 2014 04:39:42 -
@@ -184,6 +184,9 @@ azalia_codec_init_vtbl(codec_t *this)
break;
case 0x111d7608:
this-name = IDT 92HD75B1/2;
+ if ((this-subid 0x) == 0x103c) { /* HP */
+ this-qrks |= AZ_QRK_GPIO_UNMUTE_0;
+ }
break;
case 0x111d7674:
this-name = IDT 92HD73D1;
