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

[Raul Miller]

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 either is probably better done with specialized
hardware than with introspective software?

But maybe you had some other form of maliciousness in mind?

Thanks,

-- 
Raul

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

[Dragos Ruiu]

>>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 VT inside VT and nest virtualization so efficiently you can
>>virtualize ridiculous numbers of VMs even inside each other, with so
>>little overhead and few virtualization artifacts that they are nearly
>>undetectable when virtualized.
>There are at least two issues here.
>
>First, some of us *want* to run OpenBSD in a virtualised environment, so
there would have to be multiple code paths/sysctl to deal with this. Also,
what you're asking for is very x86 specific.

These days, I would guess more stuff runs virtualized than not.
A kernel compile/build time configuration would be sufficient here. Yes, and
even more specific than that, I am concerned about the latest Skylake
generation x86 and follow ons - earlier processors have readily documented
bugs that can be used to identify hypervisors. (and these can be used
independently of the specific brand of hypervisor)

>
>Second, it is simply not true that virtualisation is nearly undetectable.
This is of course a moving target, but I'd be amazed if close examination of
processor features made a VM undetectable. Mostly VMs go out of their way to
let >the guest OS know they're running in a VM, so paravirtual drivers can be
used.
>

Since we are talking about malicious applications of hypervisors, and
virtualization features, we can assume that a specialized hypervisor backdoor,
will probably try to not be so blatant and may not be as easy to detect as a
garden variety VM. A small hypervisor, that limits its scope to interfering
with only a few specific functions would not leave so many artifacts to
detect, in effect passing through most functionality to the real hardware.
(see example below)

>The virtualised hardware has a passing relation to actual hardware. Taking
the easy way out, insist on any server hardware being based on Nehalem or
later chipsets, and you'd immediately block the use of Xen, KVM, and >probably
most other VMs. Until reasonably recently, a Xen HVM domU features a modern
(post pentium 3) processor attached to a 440BX chipset. This is, of course,
non existent in the real world. There are many, many other >quirks that
identify VMs, they do not make a serious effort to hide their presence.

This is a lot of hand waving ("many") without actual details. Xen, bhyve and
lots of other, ahem, simpler, VM systems have unique documented quirks (how's
that for understatement). I'm concerned mostly about the more complex and less
quirky and fingerprintable HyperV, VMware, or derivatives thereof with the
identification APIs removed or disabled, but primarily the threat lurks in
unknown small, specialized hypervisors which might have a very small footprint
to identify. Ideally I'm looking for something that will work across all
hypervisors, to detect virtualization generically instead of VM implementation
specific quirks or tricks and even better if it works across multiple
chipsets, but as stated above I am primarily concerned with the latest
generation of x86 chips where the principal threat lies, as a long set of VM
and chipset specific checks sounds like an ugly to maintain mess (see tricks
below). I concede this may not be possible but we won't know until looking for
such.

Here is an example of a small, difficult to detect custom hypervisor (though
this one is used for defensive purposes) and a pretty cool research paper
which also discusses things relevant to this topic:
http://www-brs.ub.ruhr-uni-bochum.de/netahtml/HSS/Diss/WillemsCarsten/diss.pd
f

Some approaches:

Timing loops have always been suggested as a first idea, but in practice are
unwieldy and inaccurate. Network packet timing has also been suggested, but
again I don't know if these approaches will work anymore in new high
efficiency virtualization. Other folks have suggested looking for memory
layout anomalies introduced by virtualization. This seems to me to hold the
most promise.

For reference I include below some documented tricks to identify common VMs.
These tricks in the end are crap. They are just signatures for a snapshot of a
moving target and would not really be useful for defense. I am hoping someone
might have some other clever ideas, and that looking at the list below might
stimulate some creativity. Memory layout integrity seems to me to be the only
avenue that may be feasible right now, but maybe someone else has some other
approach that hasn't been considered yet, as there are a lot of smart folks
here.

Cheers,
--dr



Tricks (but not much treats)


Ed Skoudis and Tom Liston enumerated many VM detection tools and some
anti-anti-VM techniques in their now quite dated 2006 paper:

http://handlers.sans.org/tliston/ThwartingVMDetection_Liston_Skoudis.pdf

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

[Peter Kay]

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 have
>fixed
>so many virtualization bugs that they can (reportedly) run VT inside VT
>and
>nest virtualization so efficiently you can virtualize ridiculous
>numbers of
>VMs even inside each other, with so little overhead and few
>virtualization
>artifacts that they are nearly undetectable when virtualized. 
There are at least two issues here.

First, some of us *want* to run OpenBSD in a virtualised environment, so there 
would have to be multiple code paths/sysctl to deal with this. Also, what 
you're asking for is very x86 specific.

Second, it is simply not true that virtualisation is nearly undetectable. This 
is of course a moving target, but I'd be amazed if close examination of 
processor features made a VM undetectable. Mostly VMs go out of their way to 
let the guest OS know they're running in a VM, so paravirtual drivers can be 
used.

The virtualised hardware has a passing relation to actual hardware. Taking the 
easy way out, insist on any server hardware being based on Nehalem or later 
chipsets, and you'd immediately block the use of Xen, KVM, and probably most 
other VMs. Until reasonably recently, a Xen HVM domU features a modern (post 
pentium 3) processor attached to a 440BX chipset. This is, of course, non 
existent in the real world. There are many, many other quirks that identify 
VMs, they do not make a serious effort to hide their presence.

PK
-

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

[Dragos Ruiu]

The right link to PacSec slides (sorry): 


Mickey's and Jesse's slides from PacSec: http://goo.gl/Rgcwud


-Original Message-
From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of
Dragos Ruiu
Sent: December 23, 2015 8:24 PM
To: 'Tinker' <ti...@openmailbox.org>
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:
>> 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 but none
are found):

http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32
-architectures-optimization-manual.pdf

http://goo.gl/Aq59Lm

Its dense with info and tough to pull relevants bits out, but some clues are
in there.

My comments are based on verbal discussions with other non OBSD OS kernel
developer, Intel folks who have boasted about running hundreds of VMs
efficiently on a single (albeit Xeon) chip, and multiple folks who are doing
security audits of different vendor's Virtualization Cores, that have all
corroborated this not very well documented info, commenting especially that
Intel had pulled back some not so ready for the real world features
originally promised but eventually deprecating them in Broadwell (haven't
checked the processor errata for details yet), which were now finally
working in Skylake.

Coincidentally tonight, this seemingly related and interesting new paper by
Joanna Rutkowska (@rootkovska) "Intel x86 Considered Harmful" was released
which proposes an intriguing security solution that sounds appealing at
first, getting rid of all state in laptops - until you realize that doing
this is almost impossible. For a counter example we had a great paper at
PacSec this year from Intel's Mickey Shkatov and Jesse Michael discussing
and enumerating many of the hidden state / firmware / processors in modern
architectures that can be attacked and used as springboards including
examples of pwnage using this soft, delicate, and unprotected underbelly of
our computers. Modern architectures have so many mutable bits and embedded
CPUs/PICs/FPGAs etc... that removing (or even locking them) is a task I
daresay is beyond our reach at the moment - at least without making the
computers nearly useless bricks. For another example, consider things like
your keyboard controller, which is probably a National Semiconductor chip
with yet another embedded 8051 core, and then some more of those in your
mice and keyboards, and USB and other controllers, and so on. As a matter of
fact just counting only the 8051 cores alone in a modern PC is so hard you
are nearly guaranteed to miss a few on your first cut.

Joanna's paper: http://goo.gl/8xhMo8
Mickey's and Jesse's slides from PacSec: http://goo.gl/8xhMo8

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 VT inside VT and
nest virtualization so efficiently you can virtualize ridiculous numbers of
VMs even inside each other, with so little overhead and few virtualization
artifacts that they are nearly undetectable when virtualized. The prevailing
attitude that this isn't in scope to worry about - to which I counter that
if you don't worry about the overall platform security and just put blinders
on to the hard problems, avoiding defensive mitigations for the weak
architecture areas then you have already lost the security and integrity of
your computers, and you are at the mercy of the sophisticated attackers.
They aren't your computers anymore, you are just using them under the graces
of what attack teams more advanced than you allow you to do.

(bracing) This is an area where Win10 is clearly leading the pack based on
the effort I see they are putting into repeatedly auditing all their
codebase with smart outside experts and adding interesting new mitigations
like wrappering and shimming vulnerable unchecked AMD microcode updates, and
other weak hardware parts like USB etc... - and who would have guessed I
would be saying that a few years ago! Yes, I put on my Nomex flame retardant
suit before typing that sentence suggesting that OpenBSD development might
actually take some cues from Windows, heresy I know, on an OpenBSD list. But
this is just one person's opinion based on what I've seen, and the people
I've talked to. I'll certainly continue to seek this kind of functionality
and try to add it to my OpenBSD kernels myself if no-one else has anything
use

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

[Tinker]

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 discover if you are
running on bare metal. I too would find it useful to be able to lock a
kernel so it only runs on bare metal not a VM, but according to folks 
who
know more about this than I do it is now very hard to do this given you 
can

run VT inside VT, and very efficiently on Xeons.

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.

Cheers,
--dr

P.s. Also interested in code that can detect emulated UEFI.

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

[Tinker]

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 Michael from Intel did which 
enumerated

some of the attack vectors


URL?


. The list is much longer than your short list - and
some of it is impossible to verify on today's hardware. Or you could 
build a
diagnostic into your kernel and identify problems as a heuristic and 
aid.


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. However at the end of the day, 
it is

a user issue, and a system security problem.
If you aren't paranoid enough to worry about it, then you've already 
lost.


Cheers,
--dr

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

[Theo de Raadt]

> 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 consistant to
the previous generation, we don't have any insight into what changes in
subsequent generations).

If the hardware platforms don't have easily accessible, complete,
primitives available to serve that need, we cannot construct the
efects you desire -- late, at a higher level.

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

[Dragos Ruiu]

>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 but none
are found):

http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32
-architectures-optimization-manual.pdf

http://goo.gl/Aq59Lm

Its dense with info and tough to pull relevants bits out, but some clues are
in there.

My comments are based on verbal discussions with other non OBSD OS kernel
developer, Intel folks who have boasted about running hundreds of VMs
efficiently on a single (albeit Xeon) chip, and multiple folks who are doing
security audits of different vendor's Virtualization Cores, that have all
corroborated this not very well documented info, commenting especially that
Intel had pulled back some not so ready for the real world features
originally promised but eventually deprecating them in Broadwell (haven't
checked the processor errata for details yet), which were now finally
working in Skylake.

Coincidentally tonight, this seemingly related and interesting new paper by
Joanna Rutkowska (@rootkovska) "Intel x86 Considered Harmful" was released
which proposes an intriguing security solution that sounds appealing at
first, getting rid of all state in laptops - until you realize that doing
this is almost impossible. For a counter example we had a great paper at
PacSec this year from Intel's Mickey Shkatov and Jesse Michael discussing
and enumerating many of the hidden state / firmware / processors in modern
architectures that can be attacked and used as springboards including
examples of pwnage using this soft, delicate, and unprotected underbelly of
our computers. Modern architectures have so many mutable bits and embedded
CPUs/PICs/FPGAs etc... that removing (or even locking them) is a task I
daresay is beyond our reach at the moment - at least without making the
computers nearly useless bricks. For another example, consider things like
your keyboard controller, which is probably a National Semiconductor chip
with yet another embedded 8051 core, and then some more of those in your
mice and keyboards, and USB and other controllers, and so on. As a matter of
fact just counting only the 8051 cores alone in a modern PC is so hard you
are nearly guaranteed to miss a few on your first cut.

Joanna's paper: http://goo.gl/8xhMo8 
Mickey's and Jesse's slides from PacSec: http://goo.gl/8xhMo8

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 VT inside VT and
nest virtualization so efficiently you can virtualize ridiculous numbers of
VMs even inside each other, with so little overhead and few virtualization
artifacts that they are nearly undetectable when virtualized. The prevailing
attitude that this isn't in scope to worry about - to which I counter that
if you don't worry about the overall platform security and just put blinders
on to the hard problems, avoiding defensive mitigations for the weak
architecture areas then you have already lost the security and integrity of
your computers, and you are at the mercy of the sophisticated attackers.
They aren't your computers anymore, you are just using them under the graces
of what attack teams more advanced than you allow you to do.

(bracing) This is an area where Win10 is clearly leading the pack based on
the effort I see they are putting into repeatedly auditing all their
codebase with smart outside experts and adding interesting new mitigations
like wrappering and shimming vulnerable unchecked AMD microcode updates, and
other weak hardware parts like USB etc... - and who would have guessed I
would be saying that a few years ago! Yes, I put on my Nomex flame retardant
suit before typing that sentence suggesting that OpenBSD development might
actually take some cues from Windows, heresy I know, on an OpenBSD list. But
this is just one person's opinion based on what I've seen, and the people
I've talked to. I'll certainly continue to seek this kind of functionality
and try to add it to my OpenBSD kernels myself if no-one else has anything
useful to add.

Bottom line: Sigh. 

Cheers,
--dr

P.S. Go ahead and tell me why I'm such an idiot now. But you have the data
too, come to your own decisions, those are my current conclusions and plans.

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

[Raul Miller]

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]

[Dragos Ruiu]

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 Michael from Intel did which enumerated
some of the attack vectors. The list is much longer than your short list - and
some of it is impossible to verify on today's hardware. Or you could build a
diagnostic into your kernel and identify problems as a heuristic and aid.

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. However at the end of the day, it is
a user issue, and a system security problem.
If you aren't paranoid enough to worry about it, then you've already lost.

Cheers,
--dr

-Original Message-
From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of
Peter Kay
Sent: December 23, 2015 12:37 AM
To: Dragos Ruiu <d...@kyx.net>; 'Read, James C' <jcr...@essex.ac.uk>; 'Theo de
Raadt' <dera...@cvs.openbsd.org>; Dragos Ruiu <d...@kyx.net>; 'Read, James C'
<jcr...@essex.ac.uk>; 'Theo de Raadt' <dera...@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 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 cares? Yes, there will be processor quirks that can be used, and often
hypercalls to verify you're running under a hypervisor. Beyond that, a VM has
a large degree of difference from a physical PC - I would not be confident of
hiding this from the OS.

It's not OpenBSD's problem, though. If you don't know if you're running in a
VM the most probable causes are trojaned install media (to the point it
verifies the hash) or a hacked BIOS. If it's a BIOS you need to verify the
BIOS, the NIC boot ROM, the graphics card ROM, the disk controller ROM, the
disk drive itself, and any remote access/baseboard management controller that
exists.

If you're that paranoid, you need a specific tool to find the source of the
issue, not OpenBSD

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

[Peter Kay]

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 cares? Yes, there will be processor quirks that can be used, and often 
hypercalls to verify you're running under a hypervisor. Beyond that, a VM has a 
large degree of difference from a physical PC - I would not be confident of 
hiding this from the OS.

It's not OpenBSD's problem, though. If you don't know if you're running in a VM 
the most probable causes are trojaned install media (to the point it verifies 
the hash) or a hacked BIOS. If it's a BIOS you need to verify the BIOS, the NIC 
boot ROM, the graphics card ROM, the disk controller ROM, the disk drive 
itself, and any remote access/baseboard management controller that exists.

If you're that paranoid, you need a specific tool to find the source of the 
issue, not OpenBSD

Re: BIOS call fallback

[Read, James C]

>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 in a year... maybe two?

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.

And my name is...

0x00

Re: BIOS call fallback

[Theo de Raadt]

> >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 in a year... maybe two?
> 
> 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.

Wow, another email from you without a diff!  You are wasting valuable
time writing code to demonstrate you know better than we.

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

[Dragos Ruiu]

Ok let me short circuit this meta discussion by saying that AFAIK now that
the new Intel Skylake chips fixed many virtualization bugs and it's possible
to efficiently nest VMs there might not be a way to discover if you are
running on bare metal. I too would find it useful to be able to lock a
kernel so it only runs on bare metal not a VM, but according to folks who
know more about this than I do it is now very hard to do this given you can
run VT inside VT, and very efficiently on Xeons.

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.

Cheers,
--dr

P.s. Also interested in code that can detect emulated UEFI.

-Original Message-
From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of
Read, James C
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
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 suggesting I would like to change my name
to Richard I can only reply that I have never tried to stick my head into a
warm and wet but very smelly hole for pleasure and/or to attempt to
reproduce with it.

>Does your mother know?

Given that she is deceased I find that highly unlikely.

However, insults reminiscent of primary school days aside, you may or may
not be surprised to find that actually that was a genuine question.

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

[Read, James C]

>> 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 suggesting I would like to change my name
to Richard I can only reply that I have never tried to stick my head into a
warm and wet but very smelly hole for pleasure and/or to attempt to reproduce
with it.

>Does your mother know?

Given that she is deceased I find that highly unlikely.

However, insults reminiscent of primary school days aside, you may or may not
be surprised to find that actually that was a genuine question.

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

[Theo de Raadt]

> >> 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 assumption that you are not suggesting I would like to change my nam=
> e to Richard I can only reply that I have never tried to stick my head into=
>  a warm and wet but very smelly hole for pleasure and/or to attempt to repr=
> oduce with it.
> 
> >Does your mother know?
> 
> Given that she is deceased I find that highly unlikely.=20
> 
> However, insults reminiscent of primary school days aside, you may or may n=
> ot be surprised to find that actually that was a genuine question.

Wow, yet another email with code in it!  I read that you are PHD
student.  Don't they teach you how to write code?

To achieve merit, you must do the homework you assigned yourself.

Re: BIOS call fallback

[Gareth Nelson]

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.
> >
> > 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 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 in a year... maybe two?

Re: BIOS call fallback

[Read, James C]

>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 a
'secure' OS.

Isn't an OS resident in RAM unsecure by default? The very fact that it is
physically possible for an OS to be modified merely by software it runs or
interacts with makes any claims of being 'secure' more than a little shaky.

I guess we could start with a design choice that our 'secure' OS is resident
in ROM only and cannot easily be modified by a user with a few software
commands.

0x00

Re: BIOS call fallback

[Tati Chevron]

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.

Here's a suggestion for a community that is base around the claim of a
'secure' OS.


I don't think many people on this mailing list appreciate random 'suggestions',
because we already have enough ideas of our own to keep us busy.


Isn't an OS resident in RAM unsecure by default? The very fact that it is
physically possible for an OS to be modified merely by software it runs or
interacts with makes any claims of being 'secure' more than a little shaky.

I guess we could start with a design choice that our 'secure' OS is resident
in ROM only and cannot easily be modified by a user with a few software
commands.


I think you have a massive lack of knowledge of very basic computing principles.

Putting the OS in ROM would only defend against a specific class of
vulnerabilities, specifically the OS itself being overwritten.  Modern hardware
has MMUs and other ways to control read/write/execute permissions on sections
of RAM.  This is one reason why the Amiga was a vulnerable platform in it's
day, because the hardware lacked decent memory protection.

In any case, as long as there is any writable memory in the system, there exists
the possibility of somehow making the processor jump to it and execute code.
You can, for example, fill the memory of a smartcard with a nop slide, and place
executable code at the end.  Hold the reading device over a source of heat until
it flips enough bits and it begins executing somewhere in your RAM, and
eventually gets to your exploit code.

Besides, you don't even need writable memory to explot a system.  With a large
enough OS in ROM, somewhere there is bound to be a sequence of bytes that you
can use as an exploit.  That may well be a byte sequence which isn't even 
intended
to be executable code, or even jumping into the middle of a multi-byte
instruction, hoping that the rest that follow it would be interpreted as 
something
exploitable.

For example, on a Z80, the following sequence of bytes, starting at address 0:

11 CD 00 01 00 00

Would disassemble as:

LD DE, 
LD BC, &

I.E. you are storing one value in the DE register pair and then another value in
the BC register pair.

However, since LD DE is a multi-byte instruction, if you disassemble from
address 1, it becomes:

CALL &0001
NOP
NOP

Which would make the processor spin an endless loop, which depending on the
hardware would cause a denial of service, (lock-up, crash), and in the case of
marginal hardware, possibly cause the thing to draw more power, and overheat,
eventually jumping to another random address.

So it's quite possible to mess around and find exploits, even with software in
ROM.


0x00


Is this the first part of your new BIOS project, or something???

--
Tati Chevron
Perl and FORTRAN specialist.
SWABSIT development and migration department.
http://www.swabsit.com

Re: BIOS call fallback

[Tati Chevron]

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.

Here's a suggestion for a community that is base around the claim of a
'secure' OS.


I don't think many people on this mailing list appreciate random 'suggestions',
because we already have enough ideas of our own to keep us busy.


Isn't an OS resident in RAM unsecure by default? The very fact that it is
physically possible for an OS to be modified merely by software it runs or
interacts with makes any claims of being 'secure' more than a little shaky.

I guess we could start with a design choice that our 'secure' OS is resident
in ROM only and cannot easily be modified by a user with a few software
commands.


I think you have a massive lack of knowledge of very basic computing principles.

Putting the OS in ROM would only defend against a specific class of
vulnerabilities, specifically the OS itself being overwritten.  Modern hardware
has MMUs and other ways to control read/write/execute permissions on sections
of RAM.  This is one reason why the Amiga was a vulnerable platform in it's
day, because the hardware lacked decent memory protection.

In any case, as long as there is any writable memory in the system, there exists
the possibility of somehow making the processor jump to it and execute code.
You can, for example, fill the memory of a smartcard with a nop slide, and place
executable code at the end.  Hold the reading device over a source of heat until
it flips enough bits and it begins executing somewhere in your RAM, and
eventually gets to your exploit code.

Besides, you don't even need writable memory to explot a system.  With a large
enough OS in ROM, somewhere there is bound to be a sequence of bytes that you
can use as an exploit.  That may well be a byte sequence which isn't even 
intended
to be executable code, or even jumping into the middle of a multi-byte
instruction, hoping that the rest that follow it would be interpreted as 
something
exploitable.

For example, on a Z80, the following sequence of bytes, starting at address 0:

11 CD 00 01 00 00

Would disassemble as:

LD DE, 
LD BC, &

I.E. you are storing one value in the DE register pair and then another value in
the BC register pair.

However, since LD DE is a multi-byte instruction, if you disassemble from
address 1, it becomes:

CALL &0001
NOP
NOP

Which would make the processor spin an endless loop, which depending on the
hardware would cause a denial of service, (lock-up, crash), and in the case of
marginal hardware, possibly cause the thing to draw more power, and overheat,
eventually jumping to another random address.

So it's quite possible to mess around and find exploits, even with software in
ROM.


0x00


Is this the first part of your new BIOS project, or something???

--
Tati Chevron
Perl and FORTRAN specialist.
SWABSIT development and migration department.
http://www.swabsit.com

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

[Theo de Raadt]

> 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]

[Read, James C]

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

[Ted Unangst]

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 therefore can't search online for information about how to fix
> the problem.
> 
> He must now reinstall his old OS (or use a live bootable USB/CD) to look
> things up. Power off. Boot OpenBSD. Try it out. Power down. Repeat. Surely,
> having the option to have a cut down system while he gets things working
> properly is going to be a useful feature.

And, uh, how does using the BIOS help here?

Do you actually have a problem that you are trying very hard to avoid
revealing or is this just idle curiosity?

Re: BIOS call fallback

[Read, James C]

> 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 and driver
hackers would look like. I should expect that careful design choices in the
hardware could reduce the bloat considerably. Not to mention the complexity.

I do wonder if the best and most experienced BSD hackers got together and made
wish list for the new line of hardware that would run a next generation system
with no legacy baggage what would that wish list look like.

0x00

Re: BIOS call fallback

[Theo de Raadt]

> 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 expect that careful design choices in the
> hardware could reduce the bloat considerably. Not to mention the complexity.

Rather than writing the rich ecosystem OpenBSD turned into, we should have
tried to write BIOS's.

That's just such an awesome idea.  

I think I know a perfect candidate to take this further:

You.

> I do wonder if the best and most experienced BSD hackers got together and made
> wish list for the new line of hardware that would run a next generation system
> with no legacy baggage what would that wish list look like.

Seriously?  That's what you think changes the world?

You are obviously a young academic with lots of time.  Go for it.

Re: BIOS call fallback

[Gareth Nelson]

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 
wrote:

> > 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 expect that careful design choices in
> the
> > hardware could reduce the bloat considerably. Not to mention the
> complexity.
>
> Rather than writing the rich ecosystem OpenBSD turned into, we should have
> tried to write BIOS's.
>
> That's just such an awesome idea.
>
> I think I know a perfect candidate to take this further:
>
> You.
>
> > I do wonder if the best and most experienced BSD hackers got together
> and made
> > wish list for the new line of hardware that would run a next generation
> system
> > with no legacy baggage what would that wish list look like.
>
> Seriously?  That's what you think changes the world?
>
> You are obviously a young academic with lots of time.  Go for it.

Re: BIOS call fallback

[Steve Litt]

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 concocted over the years.
> 
> I wonder what a hardware system designed by BSD bootloader, kernel
> and driver hackers would look like. I should expect that careful
> design choices in the hardware could reduce the bloat considerably.
> Not to mention the complexity.
> 
> I do wonder if the best and most experienced BSD hackers got together
> and made wish list for the new line of hardware that would run a next
> generation system with no legacy baggage what would that wish list
> look like.

IMHO "no legacy baggage" is another way of saying "screw you, we're
changing it yet again, get with the program." In Linux, most
distributions are now making sure there's "no legacy baggage" in their
new, systemd equipped monoliths.

SteveT

Steve Litt 
November 2015 featured book: Troubleshooting Techniques
 of the Successful Technologist
http://www.troubleshooters.com/techniques

Re: BIOS call fallback

[Theo de Raadt]

> 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 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 in a year... maybe two?

Re: BIOS call fallback

[Read, James C]

>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 to make decisions based on the
BIOS detected.

>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 therefore can't search online for information about how to fix
the problem.

He must now reinstall his old OS (or use a live bootable USB/CD) to look
things up. Power off. Boot OpenBSD. Try it out. Power down. Repeat. Surely,
having the option to have a cut down system while he gets things working
properly is going to be a useful feature.

>Their primitives simply
>are not powerful enough to match the concurrency, locking, memory mapping,
>etc needs of the kernel.  Especially the concurrency - most use poll-style
>operations.  Nothing else would happen at the same time.

OK. I think I see what you are saying here. I certainly agree that the end
goal is get things up and running properly. That's why I asked if this feature
was available. To provide the user who has just installed with a stepping
stone to achieve that goal.

>Finally, because BIOS on all platforms are full of history and BUGS.

Yes, I've been looking into it and it certainly does seem messy. It's a wonder
computers actually work nowadays given that the history seems to dictate such
a terrible mess of architecture. I wonder what a brand new PC developed in
hind sight that doesn't have to worry about backward compatibility would like
look.

>We'd rather jump off a cliff.

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 own hardware and then after that the OS design would be a far simpler
affair.

0x00

Re: BIOS call fallback

[Theo de Raadt]

> >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 be possible to make decisions based on the
> BIOS detected.

Good luck with that.  Looking forward to you providing code which solves
the problem.


> >Also, BIOS functions are traditionally coded only powerful enough bootup
> style operation.
> 
> I'm not sure what you mean by 'powerful enough'.

I continued on to explain it in more detail.

> >Their primitives simply
> >are not powerful enough to match the concurrency, locking, memory mapping,
> >etc needs of the kernel.  Especially the concurrency - most use poll-style
> >operations.  Nothing else would happen at the same time.
> 
> OK. I think I see what you are saying here. I certainly agree that the end
> goal is get things up and running properly. That's why I asked if this
> feature was available. To provide the user who has just installed with a
> stepping stone to achieve that goal.

I explained it is not possible.

> 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 own hardware and then after that the OS design would be a far
> simpler affair.

Well there you go.  Get to it.  See you in 10 years.

Re: BIOS call fallback

[Raul Miller]

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 information about how to fix
> the problem.
>
> He must now reinstall his old OS (or use a live bootable USB/CD) to look
> things up. Power off. Boot OpenBSD. Try it out. Power down. Repeat. Surely,
> having the option to have a cut down system while he gets things working
> properly is going to be a useful feature.

Or, he must use a different computer to access the documentation.

Or, he must talk to a friend.

Or, if he has no friends and cannot find a suitable relic, he must
prepare by somehow putting the documentation on paper. This can be
achieved using a printer, or - if such things are outside the budget
of our friendless hero - a pen.

Or, possibly, he should consider taking up some other, less demanding
profession? Perhaps medicine?

-- 
Raul

Re: BIOS call fallback

[Tati Chevron]

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 own hardware and then after that the OS design would be a far simpler
affair.


Just to give you an idea: I started a project along those lines about 15 years 
ago, I.E. building a computer and writing the OS to go with it.

The first two hardware designs had to be scrapped, because they became 
obviously obsolete before I even got them finished.

What little of the OS I actually wrote, (in assembler), ended up being 
converted to X86 assembler, and used as the basis for an OS on commodity 
hardware.  That project has now been shelved and parts of the code re-used in a 
completely different project that is just designed to run as a user process on 
OpenBSD, which I'm still working on.

I've realised that any home-brew computer that I could reasonably design and 
build from non-custom parts wouldn't be powerful enough to do any useful work.  
Really, don't bother going down this road, 15 years to get to this point is not 
very encouraging.

--
Tati Chevron
Perl and FORTRAN specialist.
SWABSIT development and migration department.
http://www.swabsit.com

Re: BIOS call fallback

[Kamil Cholewiński]

> 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 *asking* for trouble. No level of hardware support can
help you if you're acting irresponsibly.

> I wonder what a brand new PC developed in hind sight that doesn't have
> to worry about backward compatibility would like look.

Read on Raspberry Pi's boot horror stories. It's a "brand new" toy PC
built with no legacy platform support.

BIOS call fallback

[Read, James C]

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
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?


And if not why not?


0x00

Re: BIOS call fallback

[Theo de Raadt]

> 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 cannot know what memory it should leave untouched,
to use such BIOS functions.  Also, BIOS functions are traditionally coded
only powerful enough bootup style operation.  Their primitives simply
are not powerful enough to match the concurrency, locking, memory mapping,
etc needs of the kernel.  Especially the concurrency - most use poll-style
operations.  Nothing else would happen at the same time.


Finally, because BIOS on all platforms are full of history and BUGS.
We'd rather jump off a cliff.