Re: Boot loader uses INT 13h [WAS BIOS call fallback]

What would a "malicious application of hypervisor" look like? How would that be different from a "malicious application of hardware"? Generally speaking, we're talking "grey boxes" here, I imagine. And, I guess, I'd expect either unwanted internet traffic or unwanted radio traffic. Detection of

Re: Boot loader uses INT 13h [WAS BIOS call fallback]

>>Returning back to the discussion where I suggested it would be nice to >>build OS kernels that would fail deliberately when virtualized to close >>off that class of malware, especially on the new Intel Skylake chips >>that have fixed so many virtualization bugs that they can (reportedly) >>run

Re: Boot loader uses INT 13h [WAS BIOS call fallback]

On 24 December 2015 08:00:01 GMT+00:00, Dragos Ruiu wrote: >Returning back to the discussion where I suggested it would be nice to >build >OS kernels that would fail deliberately when virtualized to close off >that >class of malware, especially on the new Intel Skylake chips that

Re: Boot loader uses INT 13h [WAS BIOS call fallback]

gt; Cc: 'Read, James C' <jcr...@essex.ac.uk>; 'Theo de Raadt' <dera...@cvs.openbsd.org>; 'OpenBSD general usage list' <misc@openbsd.org>; owner-m...@openbsd.org Subject: Re: Boot loader uses INT 13h [WAS BIOS call fallback] >On 2015-12-23 10:04, Dragos Ruiu wrote: >>

Re: Boot loader uses INT 13h [WAS BIOS call fallback]

On 2015-12-23 10:04, Dragos Ruiu wrote: Ok let me short circuit this meta discussion by saying that AFAIK now that the new Intel Skylake chips fixed many virtualization bugs Curious, where can I read about this, URL? and it's possible to efficiently nest VMs there might not be a way to

Re: Boot loader uses INT 13h [WAS BIOS call fallback]

On 2015-12-23 18:14, Dragos Ruiu wrote: Sure you could spend the rest of your life checking all the firmware and trying to design separate specialized tools for the myriad of devices in a modern PC - and there is a lot more than your simple list, see the presentation Mickey Shkatov and Jesse

Re: Boot loader uses INT 13h [WAS BIOS call fallback]

> But I get it, it's hard, so you can throw up your hands and give up by > saying that's not our problem, not an OS issue. As coders, it is very much not our problem. We just happen to run on some vendor hardware, often poorly documented and inconsistant generation to generation (even when it is

Re: Boot loader uses INT 13h [WAS BIOS call fallback]

>On 2015-12-23 10:04, Dragos Ruiu wrote: >> Ok let me short circuit this meta discussion by saying that AFAIK now >> that the new Intel Skylake chips fixed many virtualization bugs > >Curious, where can I read about this, URL? The canonical reference is still (and I looked for better summaries

Re: Boot loader uses INT 13h [WAS BIOS call fallback]

On Wed, Dec 23, 2015 at 5:14 AM, Dragos Ruiu wrote: > If you aren't paranoid enough to worry about it, then you've already lost. What did you lose? -- Raul

Re: Boot loader uses INT 13h [WAS BIOS call fallback]

...@cvs.openbsd.org> Cc: 'OpenBSD general usage list' <misc@openbsd.org>; 'OpenBSD general usage list' <misc@openbsd.org> Subject: Re: Boot loader uses INT 13h [WAS BIOS call fallback] On 23 December 2015 02:04:01 GMT+00:00, Dragos Ruiu <d...@kyx.net> wrote: >I would be in

Re: Boot loader uses INT 13h [WAS BIOS call fallback]

On 23 December 2015 02:04:01 GMT+00:00, Dragos Ruiu wrote: >I would be interested in any code that can knowingly break inside a VM >to >verify unvirtualized status, esp. on Skylake. Older processors can >probably >use the virtualization bugs in the hardware for this function. Who

Re: BIOS call fallback

>The OpenBSD process is quite well understood. Use the best methods, >doubt what you do, refractor. Simple in concept, but it takes a lot >of time. >Therefore I am looking forward to seeing what you and James can do. >How long do you think it will take you? Can we expect to see working >code

Re: BIOS call fallback

> >The OpenBSD process is quite well understood. Use the best methods, > >doubt what you do, refractor. Simple in concept, but it takes a lot > >of time. > > >Therefore I am looking forward to seeing what you and James can do. > > >How long do you think it will take you? Can we expect to see

Re: Boot loader uses INT 13h [WAS BIOS call fallback]

Sent: December 22, 2015 9:51 AM To: Theo de Raadt <dera...@cvs.openbsd.org> Cc: OpenBSD general usage list <misc@openbsd.org> Subject: Re: Boot loader uses INT 13h [WAS BIOS call fallback] >> a security consideration, as far as I can see the bootloader loads >> using I

Re: Boot loader uses INT 13h [WAS BIOS call fallback]

>> a security consideration, as far as I can see the bootloader loads using INT >> 13h calls. How can the kernel be sure it is really operating in ring 0 and not >> in some VM given that this is the case? >Hey, it looks like you are just trying to be a dick. On the assumption that you are not

Re: Boot loader uses INT 13h [WAS BIOS call fallback]

> >> a security consideration, as far as I can see the bootloader loads using= > INT > >> 13h calls. How can the kernel be sure it is really operating in ring 0 a= > nd not > >> in some VM given that this is the case? > > >Hey, it looks like you are just trying to be a dick. > > On the

Re: BIOS call fallback

Oh, don't get me wrong - that was just an idle thinking out loud "what if?" Rather than a serious proposal. On 22 Dec 2015 2:05 am, "Theo de Raadt" wrote: > > > To be fair, i'd love to see the OpenBSD approach to software development > > applied to BIOS/EFI firmware. > >

Re: BIOS call fallback

>I guess in the absence of a seriously thought out wish list such a project could be open ended. >The more care spent in hardware design choices I guess the more likely we could avoid the mess >that various legacies have caused. Here's a suggestion for a community that is base around the claim of

Re: BIOS call fallback

On Tue, Dec 22, 2015 at 11:19:01AM +, Read, James C wrote: I guess in the absence of a seriously thought out wish list such a project could be open ended. >The more care spent in hardware design choices I guess the more likely we could avoid the mess >that various legacies have caused.

Re: BIOS call fallback

On Tue, Dec 22, 2015 at 11:19:01AM +, Read, James C wrote: I guess in the absence of a seriously thought out wish list such a project could be open ended. >The more care spent in hardware design choices I guess the more likely we could avoid the mess >that various legacies have caused.

Re: Boot loader uses INT 13h [WAS BIOS call fallback]

> a security consideration, as far as I can see the bootloader loads using INT > 13h calls. How can the kernel be sure it is really operating in ring 0 and not > in some VM given that this is the case? Hey, it looks like you are just trying to be a dick. Does your mother know?

Boot loader uses INT 13h [WAS BIOS call fallback]

Hi, a security consideration, as far as I can see the bootloader loads using INT 13h calls. How can the kernel be sure it is really operating in ring 0 and not in some VM given that this is the case?

Re: BIOS call fallback

Read, James C wrote: > >Also, BIOS functions are traditionally coded only powerful enough bootup > style operation. > > I'm not sure what you mean by 'powerful enough'. Somebody who installs OpenBSD > and cannot access the internet now has a double problem 1) he can't access the > internet 2) he

Re: BIOS call fallback

> Well there you go. Get to it. See you in 10 years. Seriously, though. The thought must have crossed your mind at least once during all these years of mopping up the mess that MS/Intel seem to have concocted over the years. I wonder what a hardware system designed by BSD bootloader, kernel

Re: BIOS call fallback

> Seriously, though. The thought must have crossed your mind at least once > during all these years of mopping up the mess that MS/Intel seem to have > concocted over the years. > > I wonder what a hardware system designed by BSD bootloader, kernel and driver > hackers would look like. I should

Re: BIOS call fallback

To be fair, i'd love to see the OpenBSD approach to software development applied to BIOS/EFI firmware. For a start, it wouldn't have the nightmare that is Intel AMT sitting below the OS and offering a massive security hole. On Tue, Dec 22, 2015 at 1:36 AM, Theo de Raadt

Re: BIOS call fallback

On Mon, 21 Dec 2015 23:41:18 + "Read, James C" wrote: > > Well there you go. Get to it. See you in 10 years. > > Seriously, though. The thought must have crossed your mind at least > once during all these years of mopping up the mess that MS/Intel seem > to have

Re: BIOS call fallback

> To be fair, i'd love to see the OpenBSD approach to software development > applied to BIOS/EFI firmware. > > For a start, it wouldn't have the nightmare that is Intel AMT sitting below > the OS and offering a massive security hole. Gareth, The OpenBSD process is quite well understood. Use

Re: BIOS call fallback

>Because the kernel cannot know what memory it should leave untouched, >to use such BIOS functions. Why not? I understand that there is some degree of variance amongst BIOS usage of memory but the upper bounds seem to be clearly defined (if I am not misinformed). And surely it would be possible

Re: BIOS call fallback

> >Because the kernel cannot know what memory it should leave untouched, > >to use such BIOS functions. > > Why not? I understand that there is some degree of variance amongst BIOS > uaage of memory but the upper bounds seem to be clearly defined (if I am not > misinformed). And surely it would

Re: BIOS call fallback

On Mon, Dec 21, 2015 at 11:19 AM, Read, James C wrote: > I'm not sure what you mean by 'powerful enough'. Somebody who installs OpenBSD > and cannot access the internet now has a double problem 1) he can't access the > internet 2) he therefore can't search online for

Re: BIOS call fallback

On Mon, Dec 21, 2015 at 04:19:38PM +, Read, James C wrote: The more I look into this the more I start to think that I wasn't being extreme enough when I decided it would be easier to build my OS than play around with everyone else's. It now seems what I should have decided was to build my

Re: BIOS call fallback

> Somebody who installs OpenBSD and cannot access the internet now has a > double problem 1) he can't access the internet 2) he therefore can't > search online for information about how to fix the problem. IF you're installing a new and unknown OS on your only Internet-capable device - you are

BIOS call fallback

Hi, forgive my ignorance and lack of knowledge on OS fundamentals. As my signature suggests I am a complete beginner with 0x00 knowledge of the subject. Regardless of that fact here comes my rather naive question: Given that most OS mailing lists/forums seem to be dominated with hardware

Re: BIOS call fallback

> Given that most OS mailing lists/forums seem to be dominated with hardware > problems my basic question is does OpenBSD have a fallback option to just use > BIOS routines to get hardware working if even slower than feasible but at > least working? No. > And if not why not? Because the kernel