This question already has an answer here:

MVVM in WPF - How to alert ViewModel of changes in Model… or should I? 11 answers

Based on the picture from MSDN

It seems like all the data and business logic should be inside Model where View Model should have a duplicated set of properties of the Model for display purposes. And View should bind to the duplicated property inside the ViewModel instead of binding to the properties inside Models directly.

ViewModel should implements INotifyPropertyChanged interface to let View know if certain property is changed.

But how should Model notify ViewModel about changes? Should it implement INotifyPropertyChanged as well? If so then we could just have the View bind to the Model's property directly. Whats the real benefit of having an extra layer in between and we have to manually handle all the data changed notifications?

example based on my understanding:
View:

<Grid>
    <TextBlock Text="{Binding foo}"/>
    <Label Content="{Binding bar}"/>
</Grid>

View Model:

class ViewModel : INotifyPropertyChanged
{
    Model _m;
    public ViewModel(Model m)
    {
        _m = m;
    }

    public string foo
    {
        get
        {
            return _m.foo;
        }
        set
        {
            _m.UpdateFoo(value);
            //This one works fine. xaml will call getter to get the dead beef version
            PropertyChanged?.Invoke(this, new PropertyChangedEventArgs("foo"));             
        }
    }

    public string bar
    {
        get
        {
            return _m.bar;
        }
    }

    public event PropertyChangedEventHandler PropertyChanged;
}

Model:

class Model
{
    public string foo { get; private set; }
    public string bar { get; private set; }
    public void UpdateFoo(string newVal)
    {
        foo = newVal + "dead beef";
        bar = newVal; //how do i tell ViewModel that i have changed?
    }
}

Notifications can come from the model via INotifyPropertyChanged; but realistically that interface is horrible to consume manually. Having to base your logic based off the name of the changed property is not fun.

A model layer with notifications could be something like a message bus client, as messages come in it parses it and sends relevant (and strongly typed) events to the view model. The view model then updates properties on its data objects that raise PropertyChanged.

To your bigger question: Do you have to have separate ViewModel and Model data objects?

NO

If you want to be a purist, sure; duplicate your objects. If you want a rational approach, only have special view model objects if you need to add properties that wouldn't be appropriate (or just cant exist on) a model object.

The model is much more about separation of concerns than a useless set of duplicate objects. In the previous example, the ViewModel should not care that the objects or events came from a message bus, it just knows how to set up the objects for the view. The Model handles the implementation detail of being a message bus client.